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... Cheers, Jonas
Attachment:
signature.asc
Description: OpenPGP digital signature
