Reducing initramfs size and speed up the generation

TJ ubuntu at iam.tj
Fri Jul 14 10:47:45 UTC 2023


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+



More information about the ubuntu-devel mailing list