[arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut

[Eli Schwartz]

On 5/22/19 12:22 PM, Jonas Witschel wrote:
> On 2019-05-22 17:25, Giancarlo Razzolini via arch-general wrote:
>>> Unfortunately this process currently only works for AMD, but not for
>>> Intel, since Arch Linux doesn't package the necessary files standalone:
>>> they are downloaded by intel-ucode and used to produce a CPIO image, but
>>> not added to /usr/lib/firmware/intel-ucode/ separately. If dracut
>>> becomes the default initramfs generator, this should be changed so that
>>> microcode updates work out of the box with dracut.
>>>
>>
>> This is not a huge issue, if the microcode is passed alongside the
>> initramfs
>> on the cmdline, like we have been doing.
>>
>> We might also change the intel-ucode package, but it is not a
>> requirement and
>> will not prevent the move to dracut.
> 
> This is certainly not a blocker, no, but would be very nice to have:
> dracut can bundle kernel, kernel command line, microcode updates and
> initramfs in a single EFI executable using the "--uefi" parameter. This
> means setting up booting becomes as simple as
> 
> dracut --uefi
> bootctl install
> 
> No further configuration is needed at all because dracut and bootctl
> implement the Boot Loader Specification [1] (slight caveat: there is
> currently a small bug if the EFI system partition is mounted to /efi [2]).
> 
> Regards,
> Jonas
> 
> [1]
> https://systemd.io/BOOT_LOADER_SPECIFICATION#type-2-efi-unified-kernel-images
> [2] https://github.com/dracutdevs/dracut/pull/574

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.

All those benefits just because you did the *simple* thing and didn't
use byzantine fstab layouts which uefi+bootctl makes mandatory. :)

(Yes, I am bitter that supporting systemd-boot as a target bootloader
means we cannot trust /boot to be a sane filesystem.)

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.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20190522/54215f83/attachment.sig>