Reducing initramfs size and speed up the generation

[Benjamin Drung]

Hi,

On Wed, 2023-08-09 at 01:22 -0500, Glenn Washburn wrote:
> Hi,
> 
> I recently came across the thread last month of the same name as the
> subject and would like to bring up for discussion some ideas orthagonal
> to all the ones presented there.
> 
> Some observations:
>  1. I have observed that /lib/firmware in a sample initrd extracted on
>     my system is about 25% of the uncompressed archive.
>  2. In that same archive, 13% of the archive was occupied by files not
>     in /lib/firmware nor /lib/modules
>  3. I have currently many kernels installed on my system (really more
>     than I reasonably need), which means many initrds with duplicate
>     firmware files.
>  4. GRUB supports concatenating initrds at boot time.
>  5. GRUB can generate initrds from file paths (only regular files with
>     0777 permissions).
> 
> So the first idea is that the data from (1) and (2) is replicated
> across initrds and can ideally be shared amongst all initrds. This
> could be implemented by having initramfs-tools generate a common
> /boot/initrd-firmware and /boot/initrd-common files which will contain
> the firmware files and base initrd system files to be shared amongst all
> kernel specific initrds. Then GRUB will at boot time combine the
> initrds together with a command like:
> 
>   initrd /boot/initrd.img-kver-generic /boot/initrd-firmware \
>          /boot/initrd-common
> 
> This behavior, while until recently undocumented, has been available
> for at least a decade, which might be a concern for older GRUB builds
> using a config generated in this way.
> 
> 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?

As you mentioned, GRUB might not be the only consumer of the initramfs.
How should the non-GRUB use case be supported?


-- 
Benjamin Drung
Debian & Ubuntu Developer