On Wed, Aug 09, 2023 at 05:30:04PM +0000, Benjamin Drung wrote: > > The benefits to this are that the firmware and base initrds only need be > > generated once regardless of number of kernels installed. And their > > generation is decoupled from kernel upgrades/installs and each other. > > So the firmware initrd only needs to be regenerated when the firmware > > package is upgraded, and that need not trigger the base initrd to be > > regenerated. Likewise, upgrading cryptsetup (or any other dependency of > > the base initrd) need not cause the firmware initrd to be regenerated. > > This approach could also be used with the early init microcode parts of > > the initrd.
> This is an interesting idea. It raises some questions. > The list of firmware files to include in the initramfs is derived from > the kernel modules. Different kernel versions can require different > firmware files. How should that be handled with this approach? While it might be nice to further reduce the space requirements for /boot (especially in the face of ever-growing kernels+firmware), this question is precisely why I don't consider this viable. One of the properties of the current system is that installing new versions of packages that trigger regeneration of the initramfs for the most recent kernel should by default leave the initramfs for other kernels unmodified; this way, in the event of a regression, the last-known-good kernel can still be booted for recovery. If all of the kernels installed would be pointed at a common firmware initramfs that's pulled in by GRUB, then even in the case that the updated firmware package is *supposed* to be compatible with all the kernels on the system, it nevertheless loses this property that we haven't tampered with the last-known-good kernel and makes the system less resilient. We should prioritize resilience of boot recovery over reducing the size of /boot contents. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
