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/
slangasek@ubuntu.com vorlon@debian.org
