Re: initrd sizes mushroomed several months ago
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.
Reply to: