























I only figured this out after 4 hours of needless debugging a failed install of ArchLinux on ZFS and trying to figure out why the boot process was stopping at sysroot and leaving me without a recovery console.
Traditionally, the mkinitcpio has used BusyBox which loads beforehand and then passes the system off to systemd after loading the kernel and drivers, unlocking the file systems, and other things before the main init system begins the remainder of the boot process.
Recently, someone changed the BusyBox hooks to systemd hooks without warning users and system administrators alike of the change, which resulted in broken boot cycles, and hours of needless debugging of processes to discover this oversight.
This change needs to be made public on the news section so system administrators understand why a sysroot lockout has occurred since systemd doesn't allow for a recovery console if the mkinitcpio fails to initialize like BusyBox does.
I understand systemd is the default init system of ArchLinux, but this is the initramfs where if something goes wrong, system administrators need tools to start the recovery of a boot process, and if a tool is not allowing a system administrator to do their job, then that tool should not be the default.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。