Re: initrd sizes mushroomed several months ago
David Wright composed on 2023-02-01 22:39 (UTC-0600):
> On Wed 01 Feb 2023 at 00:50:07 (-0500), Felix Miata wrote:
>> I think 6.0's is smaller because that upgrade cycle is when I installed zstd
>> before the newer kernel. It's specified by default in initramfs.conf, but the
>> upgrades from 11 to 12 here have only been including libzstd1, which apparently
>> is not used for initrd construction.
> That's relatively easy to confirm with something like:
> $ dd if=/boot/initrd.img-6.0.0-6-amd64 skip=NNNN | file -
> where NNNN is given by the last line from:
> $ cpio -t < /boot/initrd.img-6.0.0-6-amd64
Is that a typo? I copied & pasted that and the screen loaded binary gibberish.
> I haven't seen any response from you to The Wanderer's post about
> the initramfs-tools upgrade. (Note that there are two packages,
> including the -core.) That's why, having replied to that post and
> yours, I didn't post any of my further researches, including
> those I've repeated and reported here.
At that time, I found no apparent reason to reply to that post.
> You could check your /var/log/apt/history* files on both your
> systems and see if the initramfs-tools were upgraded between
> 12 Sep and 2 Nov (amd64) and 8 May and 2 Aug (686).
All I know is all 19 installations are currently on 0.142. That old history
is history.
> Leaving aside the modules themselves, the size of the firmware is:
>
> $ du -sh lib/firmware/ # initrd
> 3.0M lib/firmware/
> $ du -sh /lib/firmware/ # OS
> 205M /lib/firmware/
> $
> Again, no relationship.
#
# du -sh /usr/lib/firmware/amdgpu
64M /usr/lib/firmware/amdgpu
# du -sh /usr/lib/firmware/radeon
7.1M /usr/lib/firmware/radeon
# ls -1 /usr/lib/firmware/amdgpu | wc -l
490
# ls -1 /usr/lib/firmware/radeon | wc -l
247
> FTR, I reinstalled 5.10.0-21-amd64 on another machine with MODULES=dep
> and for comparison (initrd only):
> $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/unpacked10-21
> cpio: etc/console-setup/null: Cannot mknod: Operation not permitted
> $ du -sh /tmp/unpacked10-21/main/lib/modules/5.10.0-21-amd64/kernel/ # modules
> 5.6M /tmp/unpacked10-21/main/lib/modules/5.10.0-21-amd64/kernel/
> $ du -sh /tmp/unpacked10-21/main/lib/firmware
> du: cannot access '/tmp/unpacked10-21/main/lib/firmware': No such file or directory
> $
> … so zero firmware is required to boot this machine (and the
> same is true for my production machine).
That's how it is here on PCs with Intel or NVidia graphics, but apparently
not so AMD/ATI, going by what's now being packed into initrds.
> If you find more modules being included in the newer /initrd/ file
> along with the 654 extra firmware files, then my suspicion would
> fall on the "Support network boot via USB Ethernet adapters" line
> in the new version's changelog, rather than changes in compression.
> What sort of modules are involved would obviously lend support to
> or dispel that suspicion.
# lsinitramfs -l /boot/initrd.img-5.17.0-1-amd64 | grep net
2 root root 0 May 15 2022 usr/lib/systemd/network
1 root root 44 Mar 14 2022 usr/lib/systemd/network/73-usb-net-by-mac.link
1 root root 499 Mar 11 2022 usr/lib/systemd/network/99-default.link
1 root root 796 May 7 2018 usr/lib/udev/rules.d/70-persistent-net.rules
1 root root 969 Mar 14 2022 usr/lib/udev/rules.d/73-special-net-names.rules
1 root root 452 Mar 11 2022 usr/lib/udev/rules.d/75-net-description.rules
1 root root 295 Mar 11 2022 usr/lib/udev/rules.d/80-net-setup-link.rules
247 root root 0 May 1 2022 usr/bin/telnet
247 root root 0 May 1 2022 usr/bin/netstat
# lsinitramfs -l /boot/initrd.img-5.18.0-1-amd64 | grep net
2 root root 0 Jun 20 2022 usr/lib/systemd/network
1 root root 44 Jun 10 2022 usr/lib/systemd/network/73-usb-net-by-mac.link
1 root root 789 Jun 2 2022 usr/lib/systemd/network/99-default.link
1 root root 796 May 7 2018 usr/lib/udev/rules.d/70-persistent-net.rules
1 root root 969 Jun 10 2022 usr/lib/udev/rules.d/73-special-net-names.rules
1 root root 452 Jun 2 2022 usr/lib/udev/rules.d/75-net-description.rules
1 root root 295 Jun 2 2022 usr/lib/udev/rules.d/80-net-setup-link.rules
253 root root 0 Jun 6 2022 usr/bin/telnet
253 root root 0 Jun 6 2022 usr/bin/netstat
I collected some data on all 19 64 bit Bookworms here:
https://paste.debian.net/hidden/16afc442/
https://paste.debian.net/plainh/16afc442
It consists of three groups, each sorted by either PC, date or size. From it
jumped out the main increase is limited to AMD/ATI graphics installations,
sometime between 14 May and 21 June:
Size Date Version Host LinesModsz Graphics/extras
# ls -Gg initrd*4 # gx78b PCIe aHD6450 0-nvme-ssd 1-ata-ssd
7649297 May 15 2022 initrd.img-5.17.0-1-amd64 gx78b 445 434M Gati
34289103 Jun 20 2022 initrd.img-5.18.0-1-amd64 gx78b 1132 459M Gati
# lsinitramfs -l /boot/initrd.img-5.17.0-1-amd64 | grep busy
-rwxr-xr-x 247 root root 0 May 1 2022 usr/bin/busybox
# lsinitramfs -l /boot/initrd.img-5.18.0-1-amd64 | grep busy
-rwxr-xr-x 253 root root 0 Jun 6 2022 usr/bin/busybox
Neither initrd contains the string radeon, nor string dgpu.
5.18 contains 1132 lines of lsinitramfs output vs 445 in 5.17: +687. There's
nothing older than October in /var/log/ on that installation, except in
installer's 2018. 5.17 has one firmware line:
usr/lib/udev/rules.d/50-firmware.rules
# dpkg-query -S /usr/lib/udev/rules.d/50-firmware.rules
dpkg-query: no path found matching pattern /usr/lib/udev/rules.d/50-firmware.rules
# cat /usr/lib/udev/rules.d/50-firmware.rules
# stub for immediately telling the kernel that userspace firmware loading
# failed; necessary to avoid long timeouts with CONFIG_FW_LOADER_USER_HELPER=y
SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1"
I have no idea what the rule above does, or if it's something that changed or
was new last spring. I don't really understand any of udev for that matter.
5.18 has 655, so 33-34 that are not firmware. I messed up somehow accounting
for most of the others:
# diff -u1 ini517-0fw-0mods.txt ini518-0fw-0mods.txt
--- ini517-0fw-0mods.txt 2023-02-02 22:54:09.000000000 -0500
+++ ini518-0fw-0mods.txt 2023-02-02 22:54:17.000000000 -0500
@@ -165,2 +165,3 @@
usr/sbin/mkdosfs
+usr/sbin/mim
usr/sbin/mdev
@@ -179,2 +180,3 @@
usr/sbin/ifconfig
+usr/sbin/i2ctransfer
usr/sbin/i2cset
@@ -229,2 +231,3 @@
usr/bin/tty
+usr/bin/ts
usr/bin/truncate
@@ -364,2 +367,3 @@
usr/bin/cttyhack
+usr/bin/crc32
usr/bin/cpio
@@ -381,4 +385,6 @@
usr/bin/basename
+usr/bin/base64
usr/bin/awk
usr/bin/ash
+usr/bin/ascii
usr/bin/arch
@@ -388,2 +394,2 @@
usr/sbin/watchdog
-1
+655
Main thing now is, why put 100% of amd graphics firmware in existence
in the initrd (beginning last spring)? Or any? And why only for AMD/ATI?
The only mwar string in Intel graphics initrds is that very same
/usr/lib/udev/rules.d/50-firmware.rules.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
Reply to: