Re: initrd sizes mushroomed several months ago

[Anssi Saari]

David Wright  writes:

> You presumably aren't running 686 and amd64 kernels, then,
> unlike Felix.

It depends on the system too. My amd64 based router doesn't have
microcode in the initramfs but that's OK since microcode is handled by
the BIOS (Coreboot). Also I think the microcode's not free to
distribute, the CPU on the router is fairly old AMD-for-embedded sort of
thing and unfortunately AMD doesn't much care about those. Or cares just
enough that some updates have come out for the various security issues
of recent years but not enough to make it clear it's free to distribute.

Re: initrd sizes mushroomed several months ago

[Felix Miata]

David Wright composed on 2023-02-04 22:43 (UTC-0600):

> The other problem for your initrds is that both the amdgpu and radeon
> directories are being included, presumably because, according to your
> dracut post, both the amdgpu.ko and radeon.ko modules are included
> (and I think you implied they're not even necessary). Can you figure
> out what the dracut initrd is replacing them with, if anything.
 
The .kos are only needed when early drm is desired. When BIOS video is adequate
to task, I can wait for KMS graphics to engage after switchroot, and keep 
initrds
smaller and thus faster loading.

# lspci -nnk | grep -A2 VGA
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Oland [Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520 OEM] 
[1002:6611]
Subsystem: Dell Radeon R5 240 OEM [1028:210b]
Kernel driver in use: amdgpu
# cat /proc/cmdline
ro noresume mitigations=auto consoleblank=0 plymouth.enable=0 
radeon.si_support=0 amdgpu.si_support=1 vga=791 video=1440x900@60
# ls -gG .initrd.img-6.0*
-rw-r--r-- 1 27584982 Dec 27 04:54 .initrd.img-6.0.0-6-amd641   # made with 
update-initramfs
-rw-r--r-- 1 14805618 Feb  4 00:20 .initrd.img-6.0.0-6-amd642   # made with 
dracut
# lsinitramfs -l .initrd.img-6.0.0-6-amd641 | grep drm
drwxr-xr-x   7 root root0 Dec 27 04:52 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm
drwxr-xr-x   3 root root0 Dec 27 04:52 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/amd
drwxr-xr-x   2 root root0 Dec 27 04:52 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/amd/amdgpu
-rw-r--r--   1 root root 18860427 Dec  9 00:54 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
drwxr-xr-x   2 root root0 Dec 27 04:52 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/display
-rw-r--r--   1 root root   395731 Dec  9 00:54 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/display/drm_display_helper.ko
-rw-r--r--   1 root root  1210187 Dec  9 00:54 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/drm.ko
-rw-r--r--   1 root root26115 Dec  9 00:54 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/drm_buddy.ko
-rw-r--r--   1 root root   446123 Dec  9 00:54 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/drm_kms_helper.ko
-rw-r--r--   1 root root22643 Dec  9 00:54 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/drm_ttm_helper.ko
drwxr-xr-x   2 root root0 Dec 27 04:52 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/radeon
-rw-r--r--   1 root root  3431419 Dec  9 00:54 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/radeon/radeon.ko
drwxr-xr-x   2 root root0 Dec 27 04:52 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/scheduler
-rw-r--r--   1 root root99603 Dec  9 00:54 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/scheduler/gpu-sched.ko
drwxr-xr-x   2 root root0 Dec 27 04:52 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/ttm
-rw-r--r--   1 root root   192283 Dec  9 00:54 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/ttm/ttm.ko
# lsinitramfs -l .initrd.img-6.0.0-6-amd642 | grep drm
drwxr-xr-x   2 root root0 Feb  4 00:19 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm
-rw-r--r--   1 root root  1210187 Dec  9 00:54 
usr/lib/modules/6.0.0-6-amd64/kernel/drivers/gpu/drm/drm.ko
#
-- 
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

Re: initrd sizes mushroomed several months ago

[David Wright]

On Sat 04 Feb 2023 at 18:04:21 (-0500), Felix Miata wrote:
> David Wright composed on 2023-02-04 10:59 (UTC-0600):
> 
> > I don't yet know which directories are being included in yours.
> 
> 6 instances of lsinitramfs, with and without -l for 3 kernels:
> 
> # initrd.img-5.17.0-1-amd64; gzip bytes:7,649,297; lines:445:
> https://termbin.com/2o3z https://paste.debian.net/1269679/
> https://termbin.com/alsd # verbose (-l) https://paste.debian.net/1269680/
> 
> # initrd.img-5.18.0-1-amd64; gzip bytes:34,289,103; lines:1132:
> https://termbin.com/7xzk https://paste.debian.net/1269681/
> https://termbin.com/nrp2 # verbose (-l) https://paste.debian.net/1269682/
> 
> # initrd.img-6.0.0-6-amd64; zstd bytes:26,414,992; lines:1196:
> https://paste.debian.net/1269676/
> https://paste.debian.net/1269677/ # verbose (-l)
> 
> Paste.debian.net wasn't working when I started.

So I noticed. When I looked for the files you pasted yesterday,
whois claimed that it didn't exist.

Summarising the above, I see:

  mymy
systemsystem initrdinitrdinitrd
buster   bullseye 5.17  5.18  6.0

amdgpu   2773810419   479
radeon   2472470232   232

The reduction in firmware for radeon from the system to the firmware
consists of 15 items that have identical copies in amdgpu, which
suggests they might have been placed in radeon by mistake. (Items
with identical filenames under both directories are not necessarily
identical.)

OTOH new firmware is being included in the amdgpu directory, both
piecemeal (like adding picasso_ta.bin to bullseye) and in 'groups'
(like green_sardine_{asd,ce,dmcub,me,mec,mec2,pfp,rlc,sdma,ta,vcn}.bin),
so there's 72% more firmware in 6.0 than buster.

AFAICT inclusion in the initrd is by directory, so if one item from
amdgpu is required, then all 479 items in the directory are included
in a 6.0 initrd. This level of granularity, while adequate for most
devices, does seem to be an aspect that could do with improvement
as far as amdgpu and radeon are concerned.

The other problem for your initrds is that both the amdgpu and radeon
directories are being included, presumably because, according to your
dracut post, both the amdgpu.ko and radeon.ko modules are included
(and I think you implied they're not even necessary). Can you figure
out what the dracut initrd is replacing them with, if anything.

Cheers,
David.

Re: initrd sizes mushroomed several months ago

[Felix Miata]

David Wright composed on 2023-02-04 10:59 (UTC-0600):

> I don't yet know which directories are being included in yours.

6 instances of lsinitramfs, with and without -l for 3 kernels:

# initrd.img-5.17.0-1-amd64; gzip bytes:7,649,297; lines:445:
https://termbin.com/2o3z https://paste.debian.net/1269679/
https://termbin.com/alsd # verbose (-l) https://paste.debian.net/1269680/

# initrd.img-5.18.0-1-amd64; gzip bytes:34,289,103; lines:1132:
https://termbin.com/7xzk https://paste.debian.net/1269681/
https://termbin.com/nrp2 # verbose (-l) https://paste.debian.net/1269682/

# initrd.img-6.0.0-6-amd64; zstd bytes:26,414,992; lines:1196:
https://paste.debian.net/1269676/
https://paste.debian.net/1269677/ # verbose (-l)

Paste.debian.net wasn't working when I started.
-- 
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

Re: initrd sizes mushroomed several months ago

[David Wright]

On Sat 04 Feb 2023 at 11:53:36 (-0500), Stefan Monnier wrote:
> > I'm guessing his machine has no microcode installed, since that's what
> > my first archive contains.  Whether that's because his machine is so
> > old that it doesn't *need* any, or because he just lives dangerously,
> > I cannot say. :-)
> 
> None of my ARM machines have a microcode update in their initrd.
> Are they really "so old" or am I living dangerously (or both)?

You presumably aren't running 686 and amd64 kernels, then,
unlike Felix.

Cheers,
David.

Re: initrd sizes mushroomed several months ago

[David Wright]

On Fri 03 Feb 2023 at 01:45:33 (-0500), Felix Miata wrote:
> 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= | file -
>  
> > where  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 just didn't allow for there to be no 'early' cpio archive containing
microcode corrections for the processor, which most people seem to have.

> > 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.

OK, I had thought that comparing the output from lsinitramfs from
older and newer initrds would have shown up what is now revealed
as all this extra firmware.

> > 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.

Yes, sorry. I've made a habit of setting   rotate -1   for the
log rotation of apt. Together with /var/log/installer/, those
logs for a valuable archive of the machine's history without
expending any effort. Others might not.

> #
> # 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
> 

I don't know what these sizes are to do with the initrd. They just
look like files installed into the rootfs for the OS. On bullseye,
I get 41M, 7.4M, 381, 247, but nothing in my initrds.

> > 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.

I don't disagree, but haven't seen the evidence here.

> > 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
> 

Re: initrd sizes mushroomed several months ago

[Stefan Monnier]

> I'm guessing his machine has no microcode installed, since that's what
> my first archive contains.  Whether that's because his machine is so
> old that it doesn't *need* any, or because he just lives dangerously,
> I cannot say. :-)

None of my ARM machines have a microcode update in their initrd.
Are they really "so old" or am I living dangerously (or both)?


Stefan

Re: initrd sizes mushroomed several months ago

[Greg Wooledge]

On Sat, Feb 04, 2023 at 10:38:12AM -0600, David Wright wrote:
> Sure, I knew that. The problem was that AFAICT, Felix's
> initrd had no first, uncompressed cpio, archive, so
> $ cpio -t < /boot/initrd.img-6.0.0-6-amd64
> immediately ran into the compressed, main archive. That
> took me by surprise because it's some years since I saw
> an initrd lacking one.

I'm guessing his machine has no microcode installed, since that's what
my first archive contains.  Whether that's because his machine is so
old that it doesn't *need* any, or because he just lives dangerously,
I cannot say. :-)

Re: initrd sizes mushroomed several months ago

[David Wright]

On Fri 03 Feb 2023 at 20:34:55 (-0500), Greg Wooledge wrote:
> On Fri, Feb 03, 2023 at 06:45:14PM -0600, David Wright wrote:
> > It's useful, as seen in my post, to skip past the early archive in
> > order to see how the main archive has been compressed.
>
> If you want to see the contents of the *second* archive in the initrd,
> you have to call cpio a second time.

Yes. Of course, it helps to ascertain what the second archive
actually /is/ before running zcat on it, because zcat only
deals with bzip2, gzip, lzip, and xz, not zstd.

> unicorn:~$ { cpio -it ; echo == ; zcat | cpio -it | head; } < 
> /boot/initrd.img-5.10.0-21-amd64 

> As it turns out, the second archive in that initrd file is compressed.
> Omitting the "zcat |" causes a *massive* slew of error messages containing
> binary data.

Sure, I knew that. The problem was that AFAICT, Felix's
initrd had no first, uncompressed cpio, archive, so
$ cpio -t < /boot/initrd.img-6.0.0-6-amd64
immediately ran into the compressed, main archive. That
took me by surprise because it's some years since I saw
an initrd lacking one.

Cheers,
David.

Re: initrd sizes mushroomed several months ago

[Felix Miata]

Felix Miata composed on 2022-11-12 01:57 (UTC-0500):

> # grep MODULES= /etc/initramfs-tools/initramfs.conf
> MODULES=dep
> # ls -Ggh /boot/initrd.img-[5,6]*
> -rw-r--r-- 1 6.8M May  8  2022 /boot/initrd.img-5.17.0-1-686
> -rw-r--r-- 1  31M Aug  2 03:06 /boot/initrd.img-5.18.0-3-686
> -rw-r--r-- 1  31M Sep 30 15:43 /boot/initrd.img-5.19.0-2-686
> -rw-r--r-- 1  36M Nov 12 01:36 /boot/initrd.img-6.0.0-3-686

> Does anyone here have an explanation for the mega-change in size of initrds 
> after
> kernel 5.17? My initramfs.conf has had MODULES=dep since before 
> testing/bullseye
> became testing/bookworm.

That was on host 32bit host gx28b with ATI RV516 [Radeon X1300/X1550 Series], 
and
the rest of the follow-up in the past few days was with host gx78b with AMD 
HD6450
(Caicos; Terascale 2). On host fi965 with AMD HD8570 (Oland; GCN1), where all 
was
roughly similar other than specific GPU to gx78b I just did:

1-Installed dracut, and copied /etc/dracut.conf.d/* from TW to Bullseye's
/etc/dracut.conf.d/, which installation left empty:
# ls -gG /etc/dracut.conf.d/
total 3
-rw-r--r-- 1 894 Jan 26 08:01 10-persistent_policy.conf
-rw-r--r-- 1  29 Nov 10 01:35 13-persistent-local.conf
-rw-rw-r-- 1 200 Feb  4 00:25 dmodules.conf
# cat /etc/dracut.conf.d/*f | grep -v ^#
persistent_policy="by-uuid"
persistent_policy="by-label"
compress="zstd"
hostonly="yes"
omit_drivers+=" btrfs dmraid encryptfs i18n iscsi lvm lvm2 plymouth resume
sata_sil uefi-lib usb_storage "
--no-kernel
--no-early-microcode

The installation tried to rebuild all existing initrds, but failed on 
account of
my symlinks in /boot/ that it wasn't prepared to deal with.

2-prepended . to all symlink names in /boot/.

3-apt update

4-time apt-get upgrade
This did not add a new kernel. Dracut rebuilt all existing initrds. I 
noticed no
activity from update-initramfs.

5-rebooted successfully using 6.0x's new initrd.

6-apt-get full-upgrade
... 34 upgraded, 21 newly installed, 0 to remove and 0 not upgraded, 
including
6.1x kernel.

7-rebooted successfully using 6.1x's new initrd.

This is the current state of all initrds. Newest of each exists without leading 
.
or last digit:
# ls -gGh /boot/.ini*
-rw-r--r-- 1 7.3M Apr 20  2022 /boot/.initrd.img-5.16.0-6-amd641
-rw-r--r-- 1  14M Feb  4 00:17 /boot/.initrd.img-5.16.0-6-amd642 # dracut
-rw-r--r-- 1 8.3M Aug  4  2022 /boot/.initrd.img-5.18.0-3-amd641
-rw-r--r-- 1  15M Feb  4 00:18 /boot/.initrd.img-5.18.0-3-amd642 # dracut
-rw-r--r-- 1  33M Sep 13 01:26 /boot/.initrd.img-5.19.0-1-amd641
-rw-r--r-- 1  15M Feb  4 00:18 /boot/.initrd.img-5.19.0-1-amd642 # dracut
-rw-r--r-- 1  33M Oct 20 02:29 /boot/.initrd.img-5.19.0-2-amd641
-rw-r--r-- 1  15M Feb  4 00:19 /boot/.initrd.img-5.19.0-2-amd642 # dracut
-rw-r--r-- 1  27M Dec 27 04:54 /boot/.initrd.img-6.0.0-6-amd641
-rw-r--r-- 1  15M Feb  4 00:20 /boot/.initrd.img-6.0.0-6-amd642 # dracut
-rw--- 1  15M Feb  4 00:46 /boot/.initrd.img-6.1.0-2-amd641 # dracut
# lsinitramfs .initrd.img-6.0.0-6-amd641 | wc -l
1208
# lsinitramfs .initrd.img-6.0.0-6-amd642 | wc -l
881
# lsinitramfs .initrd.img-6.0.0-6-amd641 | grep mwar | wc -l
728
# lsinitramfs .initrd.img-6.0.0-6-amd642 | grep mwar | wc -l
1
# lsinitramfs .initrd.img-6.1.0-2-amd641 | grep box
# lsinitramfs .initrd.img-6.1.0-2-amd641 | wc -l
882
#

So, dracut is building considerably smaller by leaving out firmware, and leaving
out radeon.ko and amdgpu.ko, but adding other things TBD once I have ideas what 
to
look for. I suspect it could be a lot of individual tools instead of (absent) 
busybox.
-- 
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

Re: initrd sizes mushroomed several months ago

[Greg Wooledge]

On Fri, Feb 03, 2023 at 06:45:14PM -0600, David Wright wrote:
> It's useful, as seen in my post, to skip past the early archive in
> order to see how the main archive has been compressed.

If you want to see the contents of the *second* archive in the initrd,
you have to call cpio a second time.


unicorn:~$ { cpio -it ; echo == ; zcat | cpio -it | head; } < 
/boot/initrd.img-5.10.0-21-amd64 
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/.enuineIntel.align.0123456789abc
kernel/x86/microcode/GenuineIntel.bin
9794 blocks
==
.
bin
conf
conf/arch.conf
conf/conf.d
conf/conf.d/resume
conf/initramfs.conf
etc
etc/fstab
etc/ld.so.cache


As it turns out, the second archive in that initrd file is compressed.
Omitting the "zcat |" causes a *massive* slew of error messages containing
binary data.

Or, of course, you could use lsinitramfs which is actually designed to
read these things.

Re: initrd sizes mushroomed several months ago

[David Wright]

On Fri 03 Feb 2023 at 07:49:39 (-0500), Greg Wooledge wrote:
> On Fri, Feb 03, 2023 at 01:45:33AM -0500, Felix Miata wrote:
> > David Wright composed on 2023-02-01 22:39 (UTC-0600):
> > >   $ cpio -t < /boot/initrd.img-6.0.0-6-amd64
> > 
> > Is that a typo? I copied & pasted that and the screen loaded binary 
> > gibberish.
> 
> GNU cpio(1) says that -t implies -i, so it should work on Debian.
> 
> unicorn:~$ cpio -t < /boot/initrd.img-5.10.0-21-amd64 
> kernel
> kernel/x86
> kernel/x86/microcode
> kernel/x86/microcode/.enuineIntel.align.0123456789abc
> kernel/x86/microcode/GenuineIntel.bin
> 9794 blocks
> 
> Not sure how *useful* it is, since it only lists the TOC from the first
> cpio archive in the initrd image, and there may be multiple.  But it
> should give a human-readable table of contents.  If it doesn't, then
> either you're not using GNU cpio (try cpio -it for portability), or
> your archive may be corrupt.

It's useful, as seen in my post, to skip past the early archive in
order to see how the main archive has been compressed.

I would assume that Felix's initrd lacks any early archive, and my
command has run up against the compressed main archive itself.

unmkinitramfs, of course, takes account of all this, but tells you
nothing about how the contents on the initrd are arranged. I've read
that binwalk can do this, but installing that is a 43 package waste
for me (with Recommends).

So I was posting a widely used method of hand-dismantling the initrd,
which naturally relies on interactively responding to what's observed.

Cheers,
David.

Re: initrd sizes mushroomed several months ago

[The Wanderer]

On 2023-02-03 at 09:57, Felix Miata wrote:

> The Wanderer composed on 2023-02-03 07:16 (UTC-0500):
>  
>> FTLIW, my own primary desktop has an AMD graphics card (and has since
>> before the initial Debian install), and doesn't have these large
>> initrds:
> 
> Oh, but it does
> 
>> $ lh /boot/initrd.img-*
>> -rw-r--r-- 1 root root 36M Sep  2 08:27 /boot/initrd.img-5.18.0-4-amd64
>> -rw-r--r-- 1 root root 36M Dec  9 07:53 /boot/initrd.img-6.0.0-4-amd64

...Huh. I must have lost the context of the sizes we were looking at,
for this conversation.

> Maybe you're used to seeing super-mega-bloated 88Ms on Ubuntu or
> Mint? :p

I think it more likely that I'm used to considering the sizes of initrd
etc. for a live-environment ISO, which needs to be able to work on
almost any hardware and so has basically all potentially-driver-ish
modules and all firmware that any of those drivers might need. (It's a
workplace thing.)

Sorry for the false angle, but then at least this seems to confirm the
*opposite* of what I thought it confirmed, although again I still
haven't dug all the way in to see what the actual contents of the initrd
are.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: initrd sizes mushroomed several months ago

[Felix Miata]

The Wanderer composed on 2023-02-03 07:16 (UTC-0500):
 
> FTLIW, my own primary desktop has an AMD graphics card (and has since
> before the initial Debian install), and doesn't have these large
> initrds:

Oh, but it does

> $ lh /boot/initrd.img-*
> -rw-r--r-- 1 root root 36M Sep  2 08:27 /boot/initrd.img-5.18.0-4-amd64
> -rw-r--r-- 1 root root 36M Dec  9 07:53 /boot/initrd.img-6.0.0-4-amd64

Maybe you're used to seeing super-mega-bloated 88Ms on Ubuntu or Mint? :p

# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated 
Graphics Controller
# ls -Gg /disks/deb09/boot/ini*4
-rw-r--r-- 1 18276933 Jan 10  2018 /disks/deb09/boot/initrd.img-4.9.0-5-amd64
-rw-r--r-- 1 18408183 Jun 28  2018 /disks/deb09/boot/initrd.img-4.9.0-6-amd64
-rw-r--r-- 1 18433876 Apr 16  2019 /disks/deb09/boot/initrd.img-4.9.0-8-amd64
-rw-r--r-- 1 18440856 Jul 11  2019 /disks/deb09/boot/initrd.img-4.9.0-9-amd64
-rw-r--r-- 1 18441992 Aug 13  2020 /disks/deb09/boot/initrd.img-4.9.0-11-amd64
-rw-r--r-- 1 18466332 Aug 13  2020 /disks/deb09/boot/initrd.img-4.9.0-13-amd64
# ls -Gg /disks/deb10/boot/ini*4
-rw-r--r-- 1 25922058 Apr 16  2019 /disks/deb10/boot/initrd.img-4.19.0-4-amd64
-rw-r--r-- 1 25949741 Oct 25  2019 /disks/deb10/boot/initrd.img-4.19.0-5-amd64
-rw-r--r-- 1 26082559 Mar  1  2020 /disks/deb10/boot/initrd.img-4.19.0-6-amd64
-rw-r--r-- 1 26113578 Aug 13  2020 /disks/deb10/boot/initrd.img-4.19.0-8-amd64
-rw-r--r-- 1 26129895 Aug 13  2020 /disks/deb10/boot/initrd.img-4.19.0-10-amd64
-rw-r--r-- 1 26151861 Nov 16  2020 /disks/deb10/boot/initrd.img-4.19.0-12-amd64
-rw-r--r-- 1 26256167 Mar  4  2021 /disks/deb10/boot/initrd.img-4.19.0-14-amd64
-rw-r--r-- 1  7562145 Dec  2 22:52 /disks/deb10/boot/initrd.img-4.19.0-17-amd64
-rw-r--r-- 1  7563646 Dec  2 23:07 /disks/deb10/boot/initrd.img-4.19.0-22-amd64
# ls -Gg /disks/deb11/boot/ini*4
-rw-r--r-- 1 28466736 Jul  3  2021 /disks/deb11/boot/initrd.img-5.10.0-7-amd64
-rw-r--r-- 1  7202005 Jan  6  2022 /disks/deb11/boot/initrd.img-5.10.0-8-amd64
-rw-r--r-- 1  7204312 Jan  6  2022 /disks/deb11/boot/initrd.img-5.10.0-10-amd64
-rw-r--r-- 1  7206932 Jun 28  2022 /disks/deb11/boot/initrd.img-5.10.0-15-amd64
-rw-r--r-- 1  7229728 Dec  2 23:33 /disks/deb11/boot/initrd.img-5.10.0-16-amd64
-rw-r--r-- 1  7268292 Dec  2 23:34 /disks/deb11/boot/initrd.img-5.10.0-19-amd64
# ls -Gg /boot/ini*4
-rw-r--r-- 1  7206932 Jun 28  2022 /boot/initrd.img-5.10.0-15-amd64
-rw-r--r-- 1  8298606 Jun 28  2022 /boot/initrd.img-5.18.0-2-amd64
-rw-r--r-- 1 10839185 Dec  3 00:26 /boot/initrd.img-5.19.0-2-amd64
-rw-r--r-- 1  9761664 Dec  3 02:29 /boot/initrd.img-6.0.0-5-amd64

# lspci | grep VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland 
[Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520 OEM]
# ls -Gg /disks/deb08/boot/ini*4
-rw-r--r-- 1 15412555 Sep  9  2015 
/disks/deb08/boot/initrd.img-3.16.0-4-amd640804
-rw-r--r-- 1 18063287 Jul  7  2018 
/disks/deb08/boot/initrd.img-4.9.0-0.bpo.3-amd64
-rw-r--r-- 1 18306518 Aug 31  2018 
/disks/deb08/boot/initrd.img-4.9.0-0.bpo.6-amd64
# ls -Gg /disks/deb09/boot/ini*4
-rw-r--r-- 1 27733865 Jun 19  2021 
/disks/deb09/boot/initrd.img-4.19.0-0.bpo.6-amd64
-rw-r--r-- 1 27691107 Jun 19  2021 
/disks/deb09/boot/initrd.img-4.19.0-0.bpo.16-amd64
# ls -Gg /disks/deb10/boot/ini*4
-rw-r--r-- 1 23241848 Dec 14  2018 /disks/deb10/boot/initrd.img-4.18.0-3-amd64
-rw-r--r-- 1 23674941 Jan 16  2019 /disks/deb10/boot/initrd.img-4.19.0-1-amd64
-rw-r--r-- 1 25353945 Mar 21  2019 /disks/deb10/boot/initrd.img-4.19.0-2-amd64
-rw-r--r-- 1 25867391 Jul 24  2019 /disks/deb10/boot/initrd.img-4.19.0-5-amd64
-rw-r--r-- 1  7557702 Dec 27 02:55 /disks/deb10/boot/initrd.img-4.19.0-6-amd64
-rw-r--r-- 1  7559906 Dec 27 02:54 /disks/deb10/boot/initrd.img-4.19.0-8-amd64
-rw-r--r-- 1 26131451 Aug  1  2020 /disks/deb10/boot/initrd.img-4.19.0-10-amd64
-rw-r--r-- 1 26143689 Nov 19  2020 /disks/deb10/boot/initrd.img-4.19.0-11-amd64
-rw-r--r-- 1  7549154 Jun 19  2021 /disks/deb10/boot/initrd.img-4.19.0-16-amd64
-rw-r--r-- 1  7558701 Jan  8  2022 /disks/deb10/boot/initrd.img-4.19.0-18-amd64
-rw-r--r-- 1  7563600 Nov  5 19:12 /disks/deb10/boot/initrd.img-4.19.0-21-amd64
-rw-r--r-- 1  7563946 Dec 27 03:02 /disks/deb10/boot/initrd.img-4.19.0-23-amd64
# ls -Gg /disks/deb11/boot/ini*4
-rw-r--r-- 1 7198759 Jun 19  2021 /disks/deb11/boot/initrd.img-5.10.0-7-amd64
-rw-r--r-- 1 7201221 Jan  9  2022 /disks/deb11/boot/initrd.img-5.10.0-8-amd64
-rw-r--r-- 1 7204241 Jan  9  2022 /disks/deb11/boot/initrd.img-5.10.0-10-amd64
-rw-r--r-- 1 7204191 Mar 11  2022 /disks/deb11/boot/initrd.img-5.10.0-12-amd64
-rw-r--r-- 1 7267715 Nov  5 23:35 /disks/deb11/boot/initrd.img-5.10.0-18-amd64
-rw-r--r-- 1 7267709 Dec 27 03:25 /disks/deb11/boot/initrd.img-5.10.0-20-amd64
# ls -Gg /boot/ini*4
-rw-r--r-- 1  7555717 Apr 20  2022 /boot/initrd.img-5.16.0-6-amd64
-rw-r--r-- 1  8669504 Aug  4  2022 /boot/initrd.img-5.18.0-3-amd64
-rw-r--r-- 1 34590685 Sep 13 01:26 

Re: initrd sizes mushroomed several months ago

[Thomas Schmitt]

Hi,

David Wright wrote:
> > >   $ cpio -t < /boot/initrd.img-6.0.0-6-amd64

Felix Miata wrote:
> > Is that a typo? I copied & pasted that and the screen loaded binary
> > gibberish.

Greg Wooledge wrote:
> GNU cpio(1) says that -t implies -i, so it should work on Debian.

Probably the initrd is compressed and the binary stuff was the error
messages of cpio, which are not terminal-safe.

If

  file /boot/initrd.img-6.0.0-6-amd64

says

  ... gzip compressed data ...

then the command to list the file tree would be

  gunzip 

Re: initrd sizes mushroomed several months ago

[Greg Wooledge]

On Fri, Feb 03, 2023 at 01:45:33AM -0500, Felix Miata wrote:
> David Wright composed on 2023-02-01 22:39 (UTC-0600):
> >   $ cpio -t < /boot/initrd.img-6.0.0-6-amd64
> 
> Is that a typo? I copied & pasted that and the screen loaded binary gibberish.

GNU cpio(1) says that -t implies -i, so it should work on Debian.

unicorn:~$ cpio -t < /boot/initrd.img-5.10.0-21-amd64 
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/.enuineIntel.align.0123456789abc
kernel/x86/microcode/GenuineIntel.bin
9794 blocks

Not sure how *useful* it is, since it only lists the TOC from the first
cpio archive in the initrd image, and there may be multiple.  But it
should give a human-readable table of contents.  If it doesn't, then
either you're not using GNU cpio (try cpio -it for portability), or
your archive may be corrupt.

Re: initrd sizes mushroomed several months ago

[The Wanderer]

On 2023-02-03 at 01:45, Felix Miata wrote:

> David Wright composed on 2023-02-01 22:39 (UTC-0600):


>> 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.

FTLIW, my own primary desktop has an AMD graphics card (and has since
before the initial Debian install), and doesn't have these large
initrds:

$ lh /boot/initrd.img-*
-rw-r--r-- 1 root root 36M Sep  2 08:27 /boot/initrd.img-5.18.0-4-amd64
-rw-r--r-- 1 root root 36M Dec  9 07:53 /boot/initrd.img-6.0.0-4-amd64

I haven't dug into them any deeper than this, but it may be worth having
the confirmation that it's not something common to all machines with AMD
graphics cards.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: initrd sizes mushroomed several months ago

[Felix Miata]

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= | file -
 
> where  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.0Mlib/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   HostLinesModsz 
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 gx78b445 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  

Re: initrd sizes mushroomed several months ago

[Felix Miata]

The Wanderer composed on 2022-11-13 06:54 (UTC-0500):

> On 2022-11-12 Felix Miata wrote:

>> # grep MODULES= /etc/initramfs-tools/initramfs.conf
>> MODULES=dep
>> # ls -Ggh /boot/initrd.img-[5,6]*
>> -rw-r--r-- 1 6.8M May  8  2022 /boot/initrd.img-5.17.0-1-686
>> -rw-r--r-- 1  31M Aug  2 03:06 /boot/initrd.img-5.18.0-3-686
>> -rw-r--r-- 1  31M Sep 30 15:43 /boot/initrd.img-5.19.0-2-686
>> -rw-r--r-- 1  36M Nov 12 01:36 /boot/initrd.img-6.0.0-3-686

>> Does anyone here have an explanation for the mega-change in size of initrds 
>> after
>> kernel 5.17? My initramfs.conf has had MODULES=dep since before 
>> testing/bullseye
>> became testing/bookworm.

> Just a stab in the dark, but:

> The changelog history for linux-image-5.18.0-4-amd64, on my system,
> gives the change from 5.17 to 5.18 as having happened in May of 2022.

> The changelog for initramfs-tools, on my system, shows exactly one
> version newer than May of 2022, released in July of 2022.

> The changelog for that version of initramfs-tools (0.142) includes the
> entry:

>   [ Dimitri John Ledkov ]
>   * [d8c5864] mkinitramfs: decompress compressed kernel modules

> with no reason or other information given. (There are a few other
> changes listed, which could also be relevant, but seem less obviously so
> from the brief descriptions - although it is of course hard to judge.)

> Just at first blush, it looks like something like that could produce an
> increase in size, potentially a notable one.

> (The previous version's changelog entry also switches compression to
> zstd, but that version came out in April, so it's unlikely to be the
> culprit.)

Size Date Version   HostLinesModsz 
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 gx78b445 434M Gati
34289103 Jun 20  2022 initrd.img-5.18.0-1-amd64 gx78b   1132 459M Gati
34788924 Aug  6 22:15 initrd.img-5.18.0-3-amd64 gx78b   1135 470M Gati
23754843 Oct 21 03:16 initrd.img-5.19.0-2-amd64 gx78b   1133 474M Gati
26414992 Dec 24 02:14 initrd.img-6.0.0-6-amd64 gx78b1196 457M Gati

Apt* history on this box only goes back to October. Oldest involving zstd is:
# zgrep zstd dpkg.log.2.gz
2022-10-21 01:40:37 install zstd:amd64  1.5.2+dfsg-1
2022-10-21 01:40:37 status half-installed zstd:amd64 1.5.2+dfsg-1
2022-10-21 01:40:37 status unpacked zstd:amd64 1.5.2+dfsg-1
2022-10-21 01:40:37 configure zstd:amd64 1.5.2+dfsg-1 
2022-10-21 01:40:37 status unpacked zstd:amd64 1.5.2+dfsg-1
2022-10-21 01:40:37 status half-configured zstd:amd64 1.5.2+dfsg-1
2022-10-21 01:40:37 status installed zstd:amd64 1.5.2+dfsg-1

# ls -gG /etc/initramfs-tools/initramfs.conf
-rw-r--r-- 1 1582 Aug  6 22:15 /etc/initramfs-tools/initramfs.conf
# grep zstd /etc/initramfs-tools/initramfs.conf
# COMPRESS: [ gzip | bzip2 | lz4 | lzma | lzop | xz | zstd ]
COMPRESS=zstd
# 0 - 19 for zstd

It's apparent in 5.19.0-2 that it was the first to have utilized zstd
in its creation.

I don't see any indication that module compression is directly involved in the
massive initrd size increase last June. In the response to David I haven't
finished is the bottom line that the egregious increase is inexplicable 
inclusion
of firmware for AMD/ATI GPUs.
-- 
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

Re: initrd sizes mushroomed several months ago

[David Wright]

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-dist2022-06-20 
> >> 16:54:17.0 -0400
> >> +++ /etc/initramfs-tools/initramfs.conf 2022-09-12 04:21:09.0 -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= | file -

where  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 root0 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 

Re: initrd sizes mushroomed several months ago

[Felix Miata]

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-dist2022-06-20 
>> 16:54:17.0 -0400
>> +++ /etc/initramfs-tools/initramfs.conf 2022-09-12 04:21:09.0 -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.
 
> I was under the impression that mushrooming occurred after 17, yet
> your 19…1 is small again.
 
> It's a simple matter to
 
>   $ lsmkinitramfs -l /boot/initrd.img-5.19.0-2-amd64
 
> 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. Grepping busy in all three produces same result.
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.
-- 
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

Re: initrd sizes mushroomed several months ago (was: switch from IDE to AHCI...)

[David Wright]

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-dist2022-06-20 
> 16:54:17.0 -0400
> +++ /etc/initramfs-tools/initramfs.conf 2022-09-12 04:21:09.0 -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

I was under the impression that mushrooming occurred after 17, yet
your 19…1 is small again.

It's a simple matter to

  $ lsmkinitramfs -l /boot/initrd.img-5.19.0-2-amd64

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.

(mc can show you the listing just by tapping F3.)

Cheers,
David.

Re: initrd sizes mushroomed several months ago (was: switch from IDE to AHCI...)

[Felix Miata]

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-dist2022-06-20 
16:54:17.0 -0400
+++ /etc/initramfs-tools/initramfs.conf 2022-09-12 04:21:09.0 -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
#
-- 
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

Re: initrd sizes mushroomed several months ago

[David Wright]

On Sun 13 Nov 2022 at 06:54:47 (-0500), The Wanderer wrote:
> On 2022-11-12 at 01:57, Felix Miata wrote:
> 
> > # grep MODULES= /etc/initramfs-tools/initramfs.conf
> > MODULES=dep
> > # ls -Ggh /boot/initrd.img-[5,6]*
> > -rw-r--r-- 1 6.8M May  8  2022 /boot/initrd.img-5.17.0-1-686
> > -rw-r--r-- 1  31M Aug  2 03:06 /boot/initrd.img-5.18.0-3-686
> > -rw-r--r-- 1  31M Sep 30 15:43 /boot/initrd.img-5.19.0-2-686
> > -rw-r--r-- 1  36M Nov 12 01:36 /boot/initrd.img-6.0.0-3-686
> > 
> > Does anyone here have an explanation for the mega-change in size of initrds 
> > after
> > kernel 5.17? My initramfs.conf has had MODULES=dep since before 
> > testing/bullseye
> > became testing/bookworm.
> 
> Just a stab in the dark, but:
> 
> The changelog history for linux-image-5.18.0-4-amd64, on my system,
> gives the change from 5.17 to 5.18 as having happened in May of 2022.
> 
> The changelog for initramfs-tools, on my system, shows exactly one
> version newer than May of 2022, released in July of 2022.
> 
> The changelog for that version of initramfs-tools (0.142) includes the
> entry:
> 
>   [ Dimitri John Ledkov ]
>   * [d8c5864] mkinitramfs: decompress compressed kernel modules
> 
> with no reason or other information given. (There are a few other
> changes listed, which could also be relevant, but seem less obviously so
> from the brief descriptions - although it is of course hard to judge.)
> 
> Just at first blush, it looks like something like that could produce an
> increase in size, potentially a notable one.
> 
> (The previous version's changelog entry also switches compression to
> zstd, but that version came out in April, so it's unlikely to be the
> culprit.)

AIUI¹ if you include compressed modules in the initramfs, then the
compressed archive that is generated will be larger than that with
uncompressed modules, so it makes sense to decompress the modules
while building the initramfs. I think that is the step that is
being added above.

That said, I dont see any xz-compressed modules in either
/lib/modules/ itself, or the initramfs archives I've mentioned.
(My bullseye mkinitramfs 0.140 dates from before the change above.)

The initramfs archives do contain /usr/bin/{xz,unxz,xzcat}, so
they could handle any potentially necessary steps.

¹ The final compression step takes advantage of patterns of data
  common to different (uncompressed) modules. However, when each
  module is individually compressed first, then these compressed
  modules will appear to be composed of pseudorandom data, with
  no patterns in common.

Cheers,
David.

Re: initrd sizes mushroomed several months ago

[David Wright]

On Sat 12 Nov 2022 at 01:57:51 (-0500), Felix Miata wrote:
> # grep MODULES= /etc/initramfs-tools/initramfs.conf
> MODULES=dep
> # ls -Ggh /boot/initrd.img-[5,6]*
> -rw-r--r-- 1 6.8M May  8  2022 /boot/initrd.img-5.17.0-1-686
> -rw-r--r-- 1  31M Aug  2 03:06 /boot/initrd.img-5.18.0-3-686
> -rw-r--r-- 1  31M Sep 30 15:43 /boot/initrd.img-5.19.0-2-686
> -rw-r--r-- 1  36M Nov 12 01:36 /boot/initrd.img-6.0.0-3-686
> 
> Does anyone here have an explanation for the mega-change in size of initrds 
> after
> kernel 5.17? My initramfs.conf has had MODULES=dep since before 
> testing/bullseye
> became testing/bookworm.

Another line of attack:

  $ grep MODULES= /etc/initramfs-tools/conf.d/*

Failing any matches with that, I'd like to see whatever is in
those initrds with lsinitramfs. After all, I just ran:

  # mkinitramfs -v -k -o ./initrd-5-10-0-19-amd64-dep-only
  # nano /etc/initramfs-tools/initramfs.conf
  # mkinitramfs -v -k -o ./initrd-5-10-0-19-amd64-most

and got:

  # ls -Glg ./initrd-5-10-0-19-amd64-*
  -rw-r--r-- 1  8252655 Nov 14 11:49 ./initrd-5-10-0-19-amd64-dep-only
  -rw-r--r-- 1 36952534 Nov 14 11:53 ./initrd-5-10-0-19-amd64-most
  # ls -Glg /boot/initrd.img-5.10.0-19-amd64
  -rw-r--r-- 1 36951179 Nov  4 13:16 /boot/initrd.img-5.10.0-19-amd64
  # 

Cheers,
David.

Re: initrd sizes mushroomed several months ago

[The Wanderer]

On 2022-11-12 at 01:57, Felix Miata wrote:

> # grep MODULES= /etc/initramfs-tools/initramfs.conf
> MODULES=dep
> # ls -Ggh /boot/initrd.img-[5,6]*
> -rw-r--r-- 1 6.8M May  8  2022 /boot/initrd.img-5.17.0-1-686
> -rw-r--r-- 1  31M Aug  2 03:06 /boot/initrd.img-5.18.0-3-686
> -rw-r--r-- 1  31M Sep 30 15:43 /boot/initrd.img-5.19.0-2-686
> -rw-r--r-- 1  36M Nov 12 01:36 /boot/initrd.img-6.0.0-3-686
> 
> Does anyone here have an explanation for the mega-change in size of initrds 
> after
> kernel 5.17? My initramfs.conf has had MODULES=dep since before 
> testing/bullseye
> became testing/bookworm.

Just a stab in the dark, but:

The changelog history for linux-image-5.18.0-4-amd64, on my system,
gives the change from 5.17 to 5.18 as having happened in May of 2022.

The changelog for initramfs-tools, on my system, shows exactly one
version newer than May of 2022, released in July of 2022.

The changelog for that version of initramfs-tools (0.142) includes the
entry:

  [ Dimitri John Ledkov ]
  * [d8c5864] mkinitramfs: decompress compressed kernel modules

with no reason or other information given. (There are a few other
changes listed, which could also be relevant, but seem less obviously so
from the brief descriptions - although it is of course hard to judge.)

Just at first blush, it looks like something like that could produce an
increase in size, potentially a notable one.

(The previous version's changelog entry also switches compression to
zstd, but that version came out in April, so it's unlikely to be the
culprit.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: initrd sizes mushroomed several months ago

[David Wright]

On Sat 12 Nov 2022 at 01:57:51 (-0500), Felix Miata wrote:
> # grep MODULES= /etc/initramfs-tools/initramfs.conf
> MODULES=dep
> # ls -Ggh /boot/initrd.img-[5,6]*
> -rw-r--r-- 1 6.8M May  8  2022 /boot/initrd.img-5.17.0-1-686
> -rw-r--r-- 1  31M Aug  2 03:06 /boot/initrd.img-5.18.0-3-686
> -rw-r--r-- 1  31M Sep 30 15:43 /boot/initrd.img-5.19.0-2-686
> -rw-r--r-- 1  36M Nov 12 01:36 /boot/initrd.img-6.0.0-3-686
> 
> Does anyone here have an explanation for the mega-change in size of initrds 
> after
> kernel 5.17? My initramfs.conf has had MODULES=dep since before 
> testing/bullseye
> became testing/bookworm.

Can you try running   lsinitramfs  | sort   on each, and
compare what's included, to see whether that differs. (Using
lsinitramfs -l   would need options adding to sort, and some
post-processing, to get much sense out of a diff.)

I have a system that's not fully configured, and is rather old.

drwxr-xr-x 2 root root 4096 Jan  8  2022 efi/
drwxr-xr-x 5 root root 4096 Jan  8  2022 grub/
-rw-r--r-- 1 root root   83 Dec  8  2021 System.map-5.10.0-10-amd64
-rw-r--r-- 1 root root   83 Sep 30  2021 System.map-5.10.0-9-amd64
-rw-r--r-- 1 root root   236056 Dec  8  2021 config-5.10.0-10-amd64
-rw-r--r-- 1 root root   236055 Sep 30  2021 config-5.10.0-9-amd64
-rw-r--r-- 1 root root 29578226 Jan  8  2022 initrd.img-5.10.0-10-amd64
-rw-r--r-- 1 root root 28159235 Jan  8  2022 initrd.img-5.10.0-9-amd64
-rw-r--r-- 1 root root  6841280 Dec  8  2021 vmlinuz-5.10.0-10-amd64
-rw-r--r-- 1 root root  6833568 Sep 30  2021 vmlinuz-5.10.0-9-amd64

However, they'll both be MODULES=most; perhaps I'll boot it sometime
and regenerate them with MODULES=dep.

Currently, this same machine, also MODULES=most, has:

drwx-- 3 root root 4096 Dec 31  1969 efi/
drwxr-xr-x 5 root root 4096 Nov  3 23:26 grub/
-rw-r--r-- 1 root root   83 Sep  2 08:54 System.map-5.10.0-18-amd64
-rw-r--r-- 1 root root   83 Oct 21 15:24 System.map-5.10.0-19-amd64
-rw-r--r-- 1 root root   236286 Sep  2 08:54 config-5.10.0-18-amd64
-rw-r--r-- 1 root root   236275 Oct 21 15:24 config-5.10.0-19-amd64
-rw-r--r-- 1 root root 36946455 Sep 12 15:20 initrd.img-5.10.0-18-amd64
-rw-r--r-- 1 root root 36951179 Nov  4 13:16 initrd.img-5.10.0-19-amd64
-rw-r--r-- 1 root root 36951452 Nov  3 23:21 initrd.img-5.10.0-19-amd64.bak
-rw-r--r-- 1 root root  6962016 Sep  2 08:54 vmlinuz-5.10.0-18-amd64
-rw-r--r-- 1 root root  6963648 Oct 21 15:24 vmlinuz-5.10.0-19-amd64

Cheers,
David.

initrd sizes mushroomed several months ago

[Felix Miata]

# grep MODULES= /etc/initramfs-tools/initramfs.conf
MODULES=dep
# ls -Ggh /boot/initrd.img-[5,6]*
-rw-r--r-- 1 6.8M May  8  2022 /boot/initrd.img-5.17.0-1-686
-rw-r--r-- 1  31M Aug  2 03:06 /boot/initrd.img-5.18.0-3-686
-rw-r--r-- 1  31M Sep 30 15:43 /boot/initrd.img-5.19.0-2-686
-rw-r--r-- 1  36M Nov 12 01:36 /boot/initrd.img-6.0.0-3-686

Does anyone here have an explanation for the mega-change in size of initrds 
after
kernel 5.17? My initramfs.conf has had MODULES=dep since before testing/bullseye
became testing/bookworm.
-- 
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