On 2019-05-22 18:41, Eli Schwartz via arch-general wrote:
True, but on the other hand bootctl sucks and you can implement a 2MB efi partition that works everywhere and supports a single unified kernel/microcode/initramfs setup stored on an ext4/btrfs/whatever /boot subdirectory inside your rootfs, full disk encryption optional and supported, no worries about your booted kernel image getting into a mismatch with your /lib/modules directory because you have multiple copies of your kernel flying around and most of them are just staged data that is never used, and so on.
systemd-boot was just one example where such a setup might be helpful, of course you don't have to use it: something like
dracut --uefi $ESP/EFI/Arch/arch-linux.efi efibootmgr --create --disk ... --label "Arch Linux" --loader "EFI\Arch\arch-linux.efi" --verbose
works equally well.
I would rather avoid such bundles at all costs, it sounds like someone saw a problem named bootctl and decided to create even more problems in the name of a solution.
IMHO such bundles are more or less the only way to go if you want to have an encrypted system in combination with Secure Boot: you can bundle everything in a single application, sign it with your keys and put it on the EFI system partition. Currently I use sbupdate-git for this purpose, if we switch to dracut anyway, I could remove sbupdate and replace it by a simple hook that signs the EFI executable generated by dracut.
The only alternative I am aware of for such a configuration is using GRUB for its encrypted /boot support, but that has some drawbacks as well (is LUKS2 supported by now?) and is much harder to customise: for example, I store the disk encryption key in a Trusted Platform Module (TPM). Retrieving it from the TPM is easy using a custom script run as a mkinitcpio hook/dracut module, writing a GRUB module is much less fun...