I just noticed this ~168% size increase in initramfs files on Fedora 42 (they are Fedora 43 kernels, shouldn't matter).
35M -rw-------. 1 root root 35M Jul 8 19:33 initramfs-6.16.0-0.rc5.65.fc43.x86_64.img 59M -rw-------. 1 root root 59M Jul 20 12:45 initramfs-6.16.0-0.rc6.52.fc43.x86_64.img
All subsequent initramfs are of the larger size including fc42 kernels.
$ sudo lsinitrd initramfs-6.16.0-0.rc5.65.fc43.x86_64.img | grep dracut Version: dracut-105-3.fc42
$ sudo lsinitrd initramfs-6.16.0-0.rc6.52.fc43.x86_64.img | grep dracut Version: dracut-107-1.fc42
Is anyone else seeing a big jump in initramfs files? Is it expected?
-- Chris Murphy
On 09/09/2025 18:07, Chris Murphy wrote:
Is anyone else seeing a big jump in initramfs files? Is it expected?
I've certainly had a number of systems start to run into space problems with /boot in the last week or so.
Tom
On Tue, 2025-09-09 at 13:07 -0400, Chris Murphy wrote:
I just noticed this ~168% size increase in initramfs files on Fedora 42 (they are Fedora 43 kernels, shouldn't matter).
35M -rw-------. 1 root root 35M Jul 8 19:33 initramfs-6.16.0-0.rc5.65.fc43.x86_64.img 59M -rw-------. 1 root root 59M Jul 20 12:45 initramfs-6.16.0-0.rc6.52.fc43.x86_64.img
All subsequent initramfs are of the larger size including fc42 kernels.
$ sudo lsinitrd initramfs-6.16.0-0.rc5.65.fc43.x86_64.img | grep dracut Version: dracut-105-3.fc42
$ sudo lsinitrd initramfs-6.16.0-0.rc6.52.fc43.x86_64.img | grep dracut Version: dracut-107-1.fc42
Is anyone else seeing a big jump in initramfs files? Is it expected?
Run lsinitrd on them and diff the output?
I did notice some openQA test failures recently caused by GNOME showing a warning for /boot being nearly full (these were webui install tests, so they run on the Workstation live image). I "fixed" it by bumping the /boot size used in the tests from 512MB to 1GB.
On Tue, Sep 09, 2025 at 10:19:20AM -0700, Adam Williamson wrote:
On Tue, 2025-09-09 at 13:07 -0400, Chris Murphy wrote:
I just noticed this ~168% size increase in initramfs files on Fedora 42 (they are Fedora 43 kernels, shouldn't matter).
35M -rw-------. 1 root root 35M Jul 8 19:33 initramfs-6.16.0-0.rc5.65.fc43.x86_64.img 59M -rw-------. 1 root root 59M Jul 20 12:45 initramfs-6.16.0-0.rc6.52.fc43.x86_64.img
All subsequent initramfs are of the larger size including fc42 kernels.
$ sudo lsinitrd initramfs-6.16.0-0.rc5.65.fc43.x86_64.img | grep dracut Version: dracut-105-3.fc42
$ sudo lsinitrd initramfs-6.16.0-0.rc6.52.fc43.x86_64.img | grep dracut Version: dracut-107-1.fc42
Is anyone else seeing a big jump in initramfs files? Is it expected?
Run lsinitrd on them and diff the output?
Comparing an old and new initramfs I see a tonne more files across a great many dirs:
* usr/lib/firmware * usr/lib/modules/$VER/kernel/arch/x86/crypto * usr/lib/modules/$VER/kernel/drivers/char/tpm * usr/lib/modules/$VER/kernel/drivers/crypto * usr/lib/modules/$VER/kernel/drivers/net * usr/lib/modules/$VER/kernel/fs * usr/lib/modules/$VER/kernel/net
With regards, Daniel
On Tue, Sep 09, 2025 at 06:55:09PM +0100, Daniel P. Berrangé wrote:
On Tue, Sep 09, 2025 at 10:19:20AM -0700, Adam Williamson wrote:
On Tue, 2025-09-09 at 13:07 -0400, Chris Murphy wrote:
I just noticed this ~168% size increase in initramfs files on Fedora 42 (they are Fedora 43 kernels, shouldn't matter).
35M -rw-------. 1 root root 35M Jul 8 19:33 initramfs-6.16.0-0.rc5.65.fc43.x86_64.img 59M -rw-------. 1 root root 59M Jul 20 12:45 initramfs-6.16.0-0.rc6.52.fc43.x86_64.img
All subsequent initramfs are of the larger size including fc42 kernels.
$ sudo lsinitrd initramfs-6.16.0-0.rc5.65.fc43.x86_64.img | grep dracut Version: dracut-105-3.fc42
$ sudo lsinitrd initramfs-6.16.0-0.rc6.52.fc43.x86_64.img | grep dracut Version: dracut-107-1.fc42
Is anyone else seeing a big jump in initramfs files? Is it expected?
Run lsinitrd on them and diff the output?
Comparing an old and new initramfs I see a tonne more files across a great many dirs:
- usr/lib/firmware
- usr/lib/modules/$VER/kernel/arch/x86/crypto
- usr/lib/modules/$VER/kernel/drivers/char/tpm
- usr/lib/modules/$VER/kernel/drivers/crypto
- usr/lib/modules/$VER/kernel/drivers/net
- usr/lib/modules/$VER/kernel/fs
- usr/lib/modules/$VER/kernel/net
...but in terms of individual file size, the really big additions are NetworkManager & lvm, and the various deps they have. The 30 biggest extra files in my initramfs from dracut 107, vs previous 105 are:
# tail -30 extra.txt 837072 usr/lib64/libkrb5.so.3.3 861664 usr/bin/xfs_db 874752 usr/bin/xfs_repair 886480 usr/bin/gawk 898440 usr/lib64/libtss2-fapi.so.1.0.0 898440 usr/lib64/libtss2-fapi.so.1.0.0 940496 usr/lib64/libcurl.so.4.8.0 940496 usr/lib64/libcurl.so.4.8.0 940496 usr/lib64/libcurl.so.4.8.0 949520 usr/bin/nmcli 980216 usr/lib64/libnftables.so.1.1.0 980216 usr/lib64/libnftables.so.1.1.0 1485320 usr/lib64/libp11-kit.so.0.4.1 1485320 usr/lib64/libp11-kit.so.0.4.1 1485320 usr/lib64/libp11-kit.so.0.4.1 1524136 usr/lib64/libnm.so.0.1.0 1524136 usr/lib64/libnm.so.0.1.0 1756032 usr/lib64/libunistring.so.5.0.0 1756032 usr/lib64/libunistring.so.5.0.0 1756032 usr/lib64/libunistring.so.5.0.0 1934632 usr/lib64/libgio-2.0.so.0.8504.0 1934632 usr/lib64/libgio-2.0.so.0.8504.0 1934632 usr/lib64/libgio-2.0.so.0.8504.0 2081688 usr/bin/dhclient 2783400 usr/bin/lvm 2889016 usr/lib64/libgnutls.so.30.40.4 2889016 usr/lib64/libgnutls.so.30.40.4 2889016 usr/lib64/libgnutls.so.30.40.4 3700224 usr/bin/NetworkManager 13763628 etc/udev/hwdb.bin
With regards, Daniel
I think --hostonly-mode sloppy became the default in 107, whereas it was using strict in 105.
At least size wise, a strict mode initramfs with 107 matches up size wise with 105 default.
I haven't looked at the code to see if the default did change. But it seems to me this should require a change proposal. And shouldn't have been changed in the middle of the lifecycle of a stable release.
OK it looks like sloppy mode was added and made default around this time, though I'm not understanding how to match the tags in the git repo with the versions I'm seeing in Fedora.
commit a695250ec7db21359689e50733c6581a8d211215 Date: Wed Jul 4 17:21:37 2018 +0800
Introduce tri-state hostonly mode
Add a new option --hostonly-mode which accept an <mode> parameter, so we have a tri-state hostonly mode:
* generic: by passing "--no-hostonly" or not passing anything. "--hostonly-mode" has no effect in such case. * sloppy: by passing "--hostonly --hostonly-mode sloppy". This is also the default mode when only "--hostonly" is given. * strict: by passing "--hostonly --hostonly-mode strict".
On Tue, Sep 9, 2025 at 6:51 PM Chris Murphy lists@colorremedies.com wrote:
OK it looks like sloppy mode was added and made default around this time, though I'm not understanding how to match the tags in the git repo with the versions I'm seeing in Fedora.
hostonly-mode was introduced with 107, and dracut was updated to 107 in f42 on/about early July, but the build unpushed. On/about a month ago a later build of 107 made it to stable.
I don't recall seeing a discussion as to why the update to 107 was needed/appropriate (but then I don't really pay that close of attention to such).
FD: I run most of my systems with hostonly=no, so I never saw an increase in size (I already had the kitchen sink in the initramfs).
On Tue, Sep 9, 2025, at 1:19 PM, Adam Williamson wrote:
Run lsinitrd on them and diff the output?
$ diff -u lsinitrd-dracut105-modulessorted.txt lsinitrd-dracut107-modulessorted.txt --- lsinitrd-dracut105-modulessorted.txt 2025-09-09 13:47:01.963719665 -0400 +++ lsinitrd-dracut107-modulessorted.txt 2025-09-09 13:47:14.475718482 -0400 @@ -1,7 +1,10 @@ base bash btrfs +cifs crypt +dbus +dbus-broker dm dracut modules: dracut-systemd @@ -9,13 +12,26 @@ fips fips-crypto-policies fs-lib +hwdb i18n +iscsi kernel-modules kernel-modules-extra +kernel-network-modules +lunmask +lvm +mdraid memstrack +net-lib +network +network-manager +nfs nss-softokn +nvmf openssl plymouth +qemu +qemu-net rootfs-block shell-interpreter shutdown @@ -26,10 +42,13 @@ systemd-initrd systemd-journald systemd-modules-load +systemd-pcrphase systemd-sysctl systemd-sysusers systemd-tmpfiles systemd-udevd terminfo +tpm2-tss udev-rules usrmount +virtiofs
All of the + files are in the 107 not in 105 version. This is on a laptop with no configuration changes between 105 and 107. None of the newly appearing modules are necessary on this system either before or after booting. Something is wrong.
Arguments: -f --kernel-image '/lib/modules/6.16.0-0.rc5.65.fc43.x86_64/vmlinuz' --kver '6.16.0-0.rc5.65.fc43.x86_64' Arguments: -f --kernel-image '/lib/modules/6.16.0-0.rc6.52.fc43.x86_64/vmlinuz' --kver '6.16.0-0.rc6.52.fc43.x86_64'
On Tue, Sep 9, 2025 at 7:08 PM Chris Murphy lists@colorremedies.com wrote:
I just noticed this ~168% size increase in initramfs files on Fedora 42 (they are Fedora 43 kernels, shouldn't matter).
35M -rw-------. 1 root root 35M Jul 8 19:33 initramfs-6.16.0-0.rc5.65.fc43.x86_64.img 59M -rw-------. 1 root root 59M Jul 20 12:45 initramfs-6.16.0-0.rc6.52.fc43.x86_64.img
All subsequent initramfs are of the larger size including fc42 kernels.
$ sudo lsinitrd initramfs-6.16.0-0.rc5.65.fc43.x86_64.img | grep dracut Version: dracut-105-3.fc42
$ sudo lsinitrd initramfs-6.16.0-0.rc6.52.fc43.x86_64.img | grep dracut Version: dracut-107-1.fc42
Is anyone else seeing a big jump in initramfs files? Is it expected?
Yeah - I saw a big increase in initramfs sizes during the F42 release cycle, a few months ago. Before I reinstalled my system with /boot being 1G large (the previous default of 512M was large enough for years), I needed to limit the number of installed kernels to 2 (down from 3). I haven't figured out why the size increased so much then ...
Fabio
On Tue, Sep 9, 2025, at 1:36 PM, Alexander Ploumistos wrote:
Hello,
Just FYI, this has appeared in F41 as well.
I see dracut-103-4.fc41 which shouldn't have the new --host-only sloppy mode. So your case might be related to an increase in GPU firmware size or other issue.
On 9/9/25 12:07 PM, Chris Murphy wrote:
Is anyone else seeing a big jump in initramfs files? Is it expected?
Yes. Looks like the blame is nvidia-gpu-firmware. Several new firmware files have been added and they are large files (compared to other firmware files). The initramfs files get a copy of /lib/firmware and those new nvidia firmware files are being pulled in.
It should be addressed before more files are added and /boot runs out of space on default Fedora installs.
On Tue, Sep 9, 2025 at 7:50 PM Michael Cronenworth mike@cchtml.com wrote:
On 9/9/25 12:07 PM, Chris Murphy wrote:
Is anyone else seeing a big jump in initramfs files? Is it expected?
Yes. Looks like the blame is nvidia-gpu-firmware. Several new firmware files have been added and they are large files (compared to other firmware files). The initramfs files get a copy of /lib/firmware and those new nvidia firmware files are being pulled in.
It should be addressed before more files are added and /boot runs out of space on default Fedora installs.
NVidia firmware can't be the reason, at least not on my system. lsinitrd shows zero nvidia firmware files (I have an AMD GPU).
Fabio
-
Adam Williamson -
Alexander Ploumistos -
Chris Murphy -
Daniel P. Berrangé -
Fabio Valentini -
Gary Buhrmaster -
Michael Cronenworth -
Tom Hughes