On 13/07/2023 22:36, Benjamin Drung wrote:
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?

Thanks for looking at it. I agree about the most bullet-proof approach but I was looking for a simple proof-of-concept at the time and then found it so reliable I stuck with it since it is the least invasive and probably has more chance of being accepted upstream.

As Dimitri mentions in a later response the logs from journald don't rely on the kernel ring buffer, but as I work with both Debian and Ubuntu I wanted to at least give a nod to non-systemd init systems hence the fallback to dmesg.

Another idea I tested would address this; to generate and save the currently loaded firmware list on each boot as:

/var/lib/firmware/${DMI_HASH}/${KERNEL_VERSION}.firmware

where $DMI_HASH is generated with:

cat /sys/class/dmi/id/board_{vendor,name} /sys/class/dmi/id/bios_version | shasum

with the intention being to match identical baseboard.

The purpose behind these static files was to avoid needing to search the kernel log every time mkinitramfs is used - when FIRMWARE_LOADED=true this file - if it exists - would be used instead.

Remember this is a PoC that has been remarkably stable for 4 years, but there are obvious additions to armour it against other workflows, unusual, and corner-cases.

> Is introducing FIRMWARE_LOADED really needed? Isn't it enough to only
> include the loaded firmware for MODULES=dep and all firmware otherwise?

I'd argue it is needed. With MODULES=most there is a 22% decrease in initrd.img size and 17% decrease in mkinitramfs time.

On systems I control there is a small separate LUKS-protected /boot/ so any reduction in size is welcome.

$ df -h /boot
Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/LUKS2_BOOT  461M  268M  165M  62% /boot

$ stat -c '%s %n' /boot/initrd.img-*
29404897 /boot/initrd.img-6.1.0-10-amd64
24851792 /boot/initrd.img-6.2.11-tj+
30102501 /boot/initrd.img-6.3.12+debian+tj+
28428121 /boot/initrd.img-6.3.4-debian+tj+
30179222 /boot/initrd.img-6.4.0+debian+tj+
30174161 /boot/initrd.img-6.4.2+debian+tj+

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Reply via email to