On Mon, Jul 04, 2022 at 10:13:23AM +0200, Lennart Poettering wrote: > On Fr, 01.07.22 08:30, Gerd Hoffmann (kraxel@xxxxxxxxxx) wrote: > > > > I do wonder if it's possible to use multiple initrds, and maybe have > > > the firmware in a separate initrd shared between all installed kernels > > > if we go down this route. > > > > grub supports multiple initrds just fine. According to > > https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub > > supports multiple initrd files also with bls. That seems to be a > > derivation from the original boot loader spec though, so not sure this > > works with systemd-boot too. > > > > When going for multiple initrds the best approach is probably to simply > > split out the kernel modules into a version-specific initrd and store > > everything else in another, shared initrd. > > In the approach Zbginiew and I are working on we intend to build a > basic initrd into the kernel itself (i.e. in a unified kernel logic) > and then optionally load additional initrd images that can be > placed next to the kernel image and are picked up by the EFI stub > (i.e. by the EFI code that runs as part of the kernel when it runs in > EFI mode still, before we transition to Linux mode, i.e. where all the > EFI file systems are still accessible), and are passed to kernel, > measured and then very early on overlayed on top of the basic initrd > image (i.e. in an immutable overlayfs stack). > > In such an approach the basic initrd would be able to just boot 90% of > the systems, and for the other 10% we'd just add a couple of extension > images next to the kernel image, and that's it. That sounds good. Given their pretty homogeneous hardware I would hope that 90% figure ought to be able to reach near 100% for virtual machines on the common hypervisors/clouds (KVM, Hyper-V, VMWare, AWS) With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
