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-image... [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