<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 13 Jul 2023, 22:37 Benjamin Drung, <<a href="mailto:bdrung@ubuntu.com">bdrung@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2023-07-13 at 08:32 +0100, TJ wrote:<br>
> Is there a specific reason why the focus is on trying to shoe-horn <br>
> everything possible into the initrd.img and then compress rather than <br>
> winnow out the files an installed system will never need to find the <br>
> root file-system?<br>
<br>
These are two orthogonal targets. MODULES=most is the default, because<br>
you can change the hardware and the system will still boot. Advanced<br>
users can use MODULES=dep to only include the needed bits, but then they<br>
have to be aware of it when changing the hardware. Improving the way we<br>
compress the initramfs could help in both configurations.<br>
<br>
> I tackled the issue of ever-expanding host-generated initrd.img file <br>
> sizes when they began hitting 80MB+ back in 2018 and since then have <br>
> carried my own patches that reduce sizes by not including files the host <br>
> will not need.<br>
> <br>
> One small change that brings major benefits is only including the <br>
> firmware files required, not every file declared by a kernel module. The <br>
> GPU drivers are the main culprit there with amdgpu declaring over 500 of <br>
> which, for any individual GPU, only a handful are relevant, but <br>
> Plymouth's pulling in multiple GPU drivers doesn't help that.<br>
> <br>
> Statistics (initrd.img with kernel v6.2.4):<br>
> MODULES= FIRMWARE_LOADED size MOST DEP firmwares build-time<br>
> most false 77117694 634 14.49<br>
> most true 60302859 -22% 8 11.99<br>
> dep false 42489938 -45% 606 6.84<br>
> dep true 25704125 -66% -40% 8 6.35<br>
> <br>
> FIMWARE_LOADED=true relies on a simple kernel patch which I've been <br>
> meaning to upstream that writes "Firmware loaded: <file>" for each.<br>
> <br>
> $ journalctl --dmesg | grep 'Firmware loaded' | head -n 15<br>
> Jul 02 11:42:21 sunny kernel: firmware_class: Firmware loaded: reporting<br>
> Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded: <br>
> radeon/verde_pfp.bin<br>
> Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded: <br>
> radeon/verde_me.bin<br>
> Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded: <br>
> radeon/verde_ce.bin<br>
> Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded: <br>
> radeon/verde_rlc.bin<br>
> Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded: <br>
> radeon/verde_mc.bin<br>
> Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded: <br>
> radeon/verde_smc.bin<br>
> Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded: <br>
> radeon/TAHITI_uvd.bin<br>
> Jul 02 11:42:21 sunny kernel: radeon 0000:0a:00.0: Firmware loaded: <br>
> radeon/TAHITI_vce.bin<br>
> Jul 02 11:42:22 sunny kernel: r8152 2-8.3:1.0: Firmware loaded: <br>
> rtl_nic/rtl8153a-4.fw<br>
> Jul 02 11:42:28 sunny kernel: platform regulatory.0: Firmware loaded: <br>
> regulatory.db<br>
> Jul 02 11:42:28 sunny kernel: platform regulatory.0: Firmware loaded: <br>
> regulatory.db.p7s<br>
> <br>
> My experiments and patches are documented at<br>
> <br>
> <a href="https://iam.tj/projects/ubuntu/initramfs-tools/" rel="noreferrer noreferrer" target="_blank">https://iam.tj/projects/ubuntu/initramfs-tools/</a><br>
<br>
That is a really good idea. After looking at the patches, the options 1<br>
and 2 (sysfs or procfs interface) are the more robust ones (but need<br>
more work implementing them in the kernel). Option 3 (kernel logging)<br>
seem to be too fragile for using it programmatically. What happens if a<br>
user boot with quiet option and clears the kernel log buffer?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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:</div><div dir="auto">1) on desktop installs hwe-22.04 rolls major versions.</div><div dir="auto">2) each Nvidia SRU update needs a new firmware file name</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is introducing FIRMWARE_LOADED really needed? Isn't it enough to only<br>
include the loaded firmware for MODULES=dep and all firmware otherwise?<br>
<br>
> The main take is the question:<br>
> <br>
> Is MODULES=most really the best default for installed-on-host images (it <br>
> obviously is for installer and portable images). If it can be nuanced <br>
> then =DEP plus winnowing the firmware files gives great gains with <br>
> minimal effort.<br>
<br>
MODULES=most is the best default since it allows changing the underlying<br>
hardware.<br>
<br>
-- <br>
Benjamin Drung<br>
Debian & Ubuntu Developer<br>
<br>
-- <br>
ubuntu-devel mailing list<br>
<a href="mailto:ubuntu-devel@lists.ubuntu.com" target="_blank" rel="noreferrer">ubuntu-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel" rel="noreferrer noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a><br>
</blockquote></div></div></div>