Arch Linux User Repository

Hello everyone, dracut-uefi-hook is now in maintenance mode and won't get feature updates anymore. Please take a look to dracut-ukify, which uses systemd's ukify tool and provides similar experience.

Some notes for upgrading path:
1. cmdline must be specified in /etc/dracut-ukify.conf, dracut's own config cannot be used for that purposes
2. UEFI secure boot keys (if any) - the same as cmdline
3. It already supports custom image variants (like fallback image of mkinitcpio)! Also see in the config file for samples.

@Hanabishi my project isn't dead, I just moved from dracut --uefi to dracut -> ukify path, for that I decided to create separate package instead of rewriting this one to a different stack of technologies behind it.

What I'd said in the pinned comment it - this package won't get "variants" feature, as I implemented it in dracut-ukify and maintaining it also here will be pain for me. But this is still usable and working perfectly fine, just don't expect new features.

There is also dracut-hook-uefi which does essentially the same thing as this package.

Hello everyone, dracut-uefi-hook is now in maintenance mode and won't get feature updates anymore. Please take a look to dracut-ukify, which uses systemd's ukify tool and provides similar experience.

Some notes for upgrading path:
1. cmdline must be specified in /etc/dracut-ukify.conf, dracut's own config cannot be used for that purposes
2. UEFI secure boot keys (if any) - the same as cmdline
3. It already supports custom image variants (like fallback image of mkinitcpio)! Also see in the config file for samples.

So, dracut's alternative to fallback images is hostonly=no I think.

I just started using Dracut so I looked into this a bit. The Arch mkinitpcio fallback image and the dracut default mode (hostonly=no) are basically the same. So without any other changes this package already builds the equivalent of a fallback image (i.e. hostonly=no).

dracut's hostonly=yes mode is similar to the mkinitcpio "default" image.

Just now I added a dracut-uefi-hook.conf option to built both a "default" and a "fallback" UKI variant in these hooks(i.e. --hostonly and --no-hostonly). I was planning to tidy it up and submit a patch.

However, after testing I think it's actually a footgun to use both methods at the same time with Dracut. The "source of truth" for many items is different[*], so it's possible to end up with a "default" image that boots and a "fallback" image which doesn't boot (and probably vice versa). Unless you're booting both images each time it's regenerated, it's probably more of a risk than a benefit. Better to pick one and use it always, I concluded.

Thanks for this hook package BTW, the scripts are clean and simple and they do the job!

[*] Some examples from my recent experience: LVM active LVs for LVM-on-LUKS, /etc/crypttab entries, probably /etc/fstab entries. Are all used from the running system in --hostonly but need to be passed on the kernel command line for --nohostonly. This is different to mkinitcpio.

Like

for i in *.conf; do [ -f "$i" ] || break ... done

Cool. Ask me, if you need help testing.

@Moo-Crumpus thanks for your feedback!

So, dracut's alternative to fallback images is hostonly=no I think.

Actually i have some concept in mind to add additional "variants" for each kernel. Then fallback-like (in general, any flags can be passed for each variant) images can be easily achieved via config file, but it need some time to prototype and test such feature.

I love this hook. Any chance to add fallback options to it? Like create an uefi image for a fallback kernel with it's own kernel cmd line.

@Hanabishi nice catch, thank you!

Maybe the package should have strict binutils dependency? Because it's optional for dracut, but required to run --uefi.