Reducing initramfs size and speed up the generation

Thu Jul 13 22:30:29 UTC 2023

On Thu, 13 Jul 2023, 22:37 Benjamin Drung, <bdrung at ubuntu.com> wrote:

> On Thu, 2023-07-13 at 08:32 +0100, TJ wrote:
> > Is there a specific reason why the focus is on trying to shoe-horn
> > everything possible into the initrd.img and then compress rather than
> > winnow out the files an installed system will never need to find the
> > root file-system?
>
> These are two orthogonal targets. MODULES=most is the default, because
> you can change the hardware and the system will still boot. Advanced
> users can use MODULES=dep to only include the needed bits, but then they
> have to be aware of it when changing the hardware. Improving the way we
> compress the initramfs could help in both configurations.
>
> > I tackled the issue of ever-expanding host-generated initrd.img file
> > sizes when they began hitting 80MB+ back in 2018 and since then have
> > carried my own patches that reduce sizes by not including files the host
> > will not need.
> >
> > One small change that brings major benefits is only including the
> > firmware files required, not every file declared by a kernel module. The
> > GPU drivers are the main culprit there with amdgpu declaring over 500 of
> > which, for any individual GPU, only a handful are relevant, but
> > Plymouth's pulling in multiple GPU drivers doesn't help that.
> >
> > Statistics (initrd.img with kernel v6.2.4):
> > MODULES=  FIRMWARE_LOADED size      MOST DEP firmwares build-time
> > most      false           77117694           634       14.49
> > most      true            60302859 -22%        8       11.99
> > dep       false           42489938 -45%      606       6.84
> > dep       true            25704125 -66% -40%   8       6.35
> >
> > FIMWARE_LOADED=true relies on a simple kernel patch which I've been
> > meaning to upstream that writes "Firmware loaded: <file>" for each.
> >
> > $ journalctl --dmesg | grep 'Firmware loaded' | head -n 15
> > Jul 02 11:42:21 sunny kernel: firmware_class: Firmware loaded: reporting
> > Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded:
> > radeon/verde_pfp.bin
> > Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded:
> > radeon/verde_me.bin
> > Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded:
> > radeon/verde_ce.bin
> > Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded:
> > radeon/verde_rlc.bin
> > Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded:
> > radeon/verde_mc.bin
> > Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded:
> > radeon/verde_smc.bin
> > Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded:
> > radeon/TAHITI_uvd.bin
> > Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded:
> > radeon/TAHITI_vce.bin
> > Jul 02 11:42:22 sunny kernel: r8152 2-8.3:1.0: Firmware loaded:
> > rtl_nic/rtl8153a-4.fw
> > Jul 02 11:42:28 sunny kernel: platform regulatory.0: Firmware loaded:
> > regulatory.db
> > Jul 02 11:42:28 sunny kernel: platform regulatory.0: Firmware loaded:
> > regulatory.db.p7s
> >
> > My experiments and patches are documented at
> >
> > https://iam.tj/projects/ubuntu/initramfs-tools/
>
> That is a really good idea. After looking at the patches, the options 1
> and 2 (sysfs or procfs interface) are the more robust ones (but need
> more work implementing them in the kernel). Option 3 (kernel logging)
> seem to be too fragile for using it programmatically. What happens if a
> user boot with quiet option and clears the kernel log buffer?
>

journald stores a copy of dmesg subject to its own retention and rotation
policy, even when dmesg is cleared. Thus it should be reliable to have
journal output for dmesg for multiple boots.

The issue however is that drivers and kernels can change on disk, and the
next kernel ABI may need different or more firmware files. examples:
1) on desktop installs hwe-22.04 rolls major versions.
2) each Nvidia SRU update needs a new firmware file name

> Is introducing FIRMWARE_LOADED really needed? Isn't it enough to only
> include the loaded firmware for MODULES=dep and all firmware otherwise?
>
> > The main take is the question:
> >
> > Is MODULES=most really the best default for installed-on-host images (it
> > obviously is for installer and portable images). If it can be nuanced
> > then =DEP plus winnowing the firmware files gives great gains with
> > minimal effort.
>
> MODULES=most is the best default since it allows changing the underlying
> hardware.
>
> --
> Benjamin Drung
> Debian & Ubuntu Developer
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20230713/360ee489/attachment.html>