Specific commit breaks kernel-install with ukify under specific circumstances
This commit breaks systemd ukify if systemd-ukify
is NOT installed, and mkinitcpio isn't explicitly set to be the uki_generator
. Prior to this commit being released in mkinitcpio
, mkinitcpio would build the UKI, irrespective of whether systemd-ukify
is installed, or whether uki_generator
is set in /etc/kernel/install.conf.
There are two workarounds, but only one of them is necessary:
- install
systemd-ukify
- set
uki_generator=mkinitcpio
in /etc/kernel/install.conf
Without either of these, those depending on the ukify functionality by default being used (i.e., without uki_generator
being set at all), were in for a rude awakening when kernel-install failed to build and install the UKI. As with most Arch upgrades, in my case there were a lot of other packages installed/upgraded at the time, and kernel-install failing is not fatal to the pacman run. The failure message scrolled off the screen, and I rebooted thus running into the issue.
Part of the problem is ukify is quite new (only coming out of experimental status with systemd 255, the current major version of systemd in Arch). The Arch Wiki was severely lacking here; I and others have corrected that today. I was unaware that I was relying on implicit mkinitcpio functionality, and the commit linked at the top of this issue removed this implicit functionality.
All I ask is that the mkinitcpio maintainers be very careful when removing functionality; for a few days it was difficult to figure out what happened, and no one on the forums or IRC seemed to immediately know what the problem was. My laptop was essentially useless until I figured it out, and then I spent the better part of 24 hours trying to figure out why systemd-ukify
was necessary in this case. I credit Erus_Iluvatar with finding the actual culprit. I kept digging into systemd
thinking that ukify was somehow removed once systemd-ukify
was mature enough. But it was this mkinitcpio
commit that was the real reason why.