Re: initrd sizes mushroomed several months ago
On Wed 01 Feb 2023 at 00:50:07 (-0500), Felix Miata wrote:
> David Wright composed on 2023-01-31 22:56 (UTC-0600):
> > On Tue 31 Jan 2023 at 18:31:15 (-0500), Felix Miata wrote:
> >> David Wright composed on 2023-01-28 09:10 (UTC-0600):
> >>> On Sat 28 Jan 2023 at 03:15:11 (-0500), Felix Miata wrote:
>
> >>>> I thought only Windows was like that, but apparently not always. I keep my
> >>>> initramfs configuration set to =dep.
>
> >>> And is that the reason behind, and cure for, your mushrooming initrd
> >>> size complaint in https://lists.debian.org/debian-user/2022/11/msg00331.html
>
> >> More detail follows:
>
> >> # inxi -S --vs
> >> inxi 3.3.24-00 (2022-12-10)
> >> System:
> >> Host: big31 Kernel: 6.0.0-6-amd64 arch: x86_64 bits: 64 Desktop: Trinity
> >> Distro: Debian GNU/Linux bookworm/sid
> >> # ls -Gg /etc/initramfs-tools/initramfs.conf
> >> -rw-r--r-- 1 1582 Sep 12 04:21 /etc/initramfs-tools/initramfs.conf
> >> # diff -u1 /etc/initramfs-tools/.initramfs.conf.07dpkg-dist /etc/initramfs-tools/initramfs.conf
> >> --- /etc/initramfs-tools/.initramfs.conf.07dpkg-dist 2022-06-20 16:54:17.000000000 -0400
> >> +++ /etc/initramfs-tools/initramfs.conf 2022-09-12 04:21:09.000000000 -0400
> >> @@ -19,3 +19,3 @@
>
> >> -MODULES=most
> >> +MODULES=dep
> >> # ls -Gg /boot/initrd.img-5.16.0-6* /boot/initrd.img-5.19* /boot/initrd.img-6*
> >> -rw-r--r-- 1 7554203 Apr 22 2022 /boot/initrd.img-5.16.0-6-amd64
> >> -rw-r--r-- 1 8324160 Sep 12 04:26 /boot/initrd.img-5.19.0-1-amd64
> >> -rw-r--r-- 1 34597945 Nov 2 17:57 /boot/initrd.img-5.19.0-2-amd64
> >> -rw-r--r-- 1 23955561 Jan 31 17:58 /boot/initrd.img-6.0.0-6-amd64
>
> 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
> > I was under the impression that mushrooming occurred after 17, yet
> > your 19…1 is small again.
>
> > It's a simple matter to
>
> > $ ls[]initramfs -l /boot/initrd.img-5.19.0-2-amd64 [corrected typo]
>
> > for 19…1 and 19…2, and compare their contents. Are there more modules
> > included in the second one, or has each module expanded in size?
> > Or is something included in the initrd that's unexpected? Has someone
> > replaced busybox by ~250 different binaries? These are the obvious
> > things to investigate.
>
> Unexpected: giant firmware increase. :(
>
> # lsinitramfs initrd.img-5.19.0-1-amd64 | grep mwar | wc -l
> 1
> # lsinitramfs initrd.img-5.19.0-2-amd64 | grep mwar | wc -l
> 655
> # lsinitramfs initrd.img-6.0.0-6-amd64 | grep mwar | wc -l
> 655
> #
>
> I'm not aware of whatever controls whether mountains of firmware
> are stuffed into initrds or not. I can't make enough sense of what
> /usr/share/initramfs-tools/ contains to know if there's something
> in it that controls.
Well, it's certainly odd that you require 654 extra firmware files
to boot 5.19.0-2-amd64 as opposed to 5.19.0-1-amd64, so if there
are no stray files in /etc/initramfs/conf.d/, then something else
in the initrd is most likely the cause.
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.
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).
If that's so, it might be productive to compare the contents of
the older and newer versions of initramfs-tools* to see what's
changed. I think they're both full of entirely non-binary
scripts etc.
> Grepping busy in all three produces same result.
$ lsinitramfs initrd.img-6.0.0-6-amd64 | grep busy | wc -l
is futile, and will yield "1".
$ lsinitramfs initrd.img-6.0.0-6-amd64 | grep busy
is just as futile, and will yield "usr/bin/busybox".
You need to run:
$ lsinitramfs -l initrd.img-6.0.0-6-amd64 | grep busy
and check the first number given in the output, here "247":
$ lsinitramfs -l /boot/initrd.img-5.10.0-21-amd64 | grep busy
-rwxr-xr-x 247 root root 0 Jul 25 2021 usr/bin/busybox
$
IOW most of the functionality of 247 individual binaries has been built
into the single binary, busybox, which has 247 hard links.
> Installed sizes in /lib/modules vary nominally, 0.1MiB between the
> two 5.19s, 468.9MiB & 468.8MiB, 452.4MiB for 6.0, 426.8 for 5.16, so it
> doesn't look like installed firmware would have changed significantly.
I don't understand. Firmware is not installed in /lib/modules,
but in /lib/firmware. And what do you mean by "installed" sizes?
The installed size of /lib/modules/<current-kernel-version>
on a system bears no relationship to the size of
/usr/lib/modules/<current-kernel-version> in its initrd,
because most of the kernel modules aren't required to boot
the machine. 4xxMiB looks reasonable for the running system's
kernel, but several times too big for an initrd.
Here are the figures for my production ("most") bullseye kernel:
$ cpio -t < /boot/initrd.img-5.10.0-21-amd64 | grep blocks
9794 blocks
$ dd if=/boot/initrd.img-5.10.0-21-amd64 skip=9794 | zcat¹ | cpio -i
cpio: etc/console-setup/null: Cannot mknod: Operation not permitted
62421+1 records in
62421+1 records out
31959569 bytes (32 MB, 30 MiB) copied, 0.763828 s, 41.8 MB/s
221762 blocks
$ du -sh lib/modules/5.10.0-21-amd64/kernel/ # initrd
93M lib/modules/5.10.0-21-amd64/kernel/
$ du -sh /lib/modules/5.10.0-21-amd64/kernel/ # OS
304M /lib/modules/5.10.0-21-amd64/kernel/
$
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.
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).
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.
¹ unmkinitramfs unpacks the initrd more easily, as in the following
example, but I'd be curious to see what you have to put in place of
my zcat if they're using a different compression method with 6.0.
Cheers,
David.
Reply to: