More context: https://github.com/dracut-ng/dracut-ng/issues/748

Upstream has CI testing strict mode (but no distribution yet shipping strict mode by default to my knowledge). 

I do not mean to weight in the default for Fedora, but upstream had plenty discussion and heads'up. One could certainly argue that sloppy mode got fixed and as a result it grow in size.

Thanks for the response, Laszlo. My revert suggestion is directed at Fedora 42 and 43. Upstream of course must do what it sees fit in the interest of all users, and that effort is appreciated. I also notice your concern in comment https://github.com/dracut-ng/dracut-ng/issues/748#issuecomment-2495150772 about the need for downstream testing, feedback back upstream, compatibility and potentially an experimental setting first.


---

-rw-------. 1 root root  36633932 Jul  8 19:33 initramfs-6.16.0-0.rc5.65.fc43.x86_64.img
-rw-------. 1 root root  61756189 Jul 20 12:45 initramfs-6.16.0-0.rc6.52.fc43.x86_64.img

From lsinitrd for those two initramfs:

Version: dracut-105-3.fc42
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'

Version: dracut-107-1.fc42
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'

What settings would dracut-107 need to produce the default dracut-105 behavior? Both /etc/dracut.conf and /etc/dracut.conf.d are empty on test systems. Seems there's only a change in default since the command lines are unchanged.


---

 35480 -rw-------. 1 root root  36328106 Jul  5 21:52 initramfs-6.15.4-200.fc42.x86_64-dracut105default.img
 60308 -rw-------. 1 root root  61755075 Sep  9 23:01 initramfs-6.15.4-200.fc42.x86_64-dracut107default.img
 32636 -rw-------. 1 root root  33418585 Sep  9 22:59 initramfs-6.15.4-200.fc42.x86_64-dracut107strict.img

Same as reported here: https://github.com/dracut-ng/dracut-ng/issues/748#issuecomment-3139041503

The dracut-105 default, and dracut-107 strict initramfs's are close in size but not identical. I can't assess if they're "close enough" that 107's strict is a drop-in substitute. If there's a legacy/compatible option that would seem to be better in the short term.

During mid-cycle in Fedora 42, I stopped being able to upgrade my system. With the default 3 kernels installed, the new kernel doesn't fit onto the 500MB /boot partition (the default size many releases back), and such users simply can't update their system at all. This wouldn't be a problem if it happened in a new Fedora release, but this is pretty bad when it happens during the regular lifecycle of an already stable release.

I'm proposing this as a Final blocker as a conditional violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed" for folks upgrading from Fedora 41 with small /boot partitions. (I say F41 specifically because F42 was already updated to 107 itself, but F41 was not).

In the upstream ticket, jozzsi seemed pretty lukewarm on 'strict':

"Yes, "strict" is the recommended option for smaller initramfs size, but not for compatibility. No such thing as backward compatibility here IMHO.

As @LaszloGombos mentioned in the referenced https://bugzilla.redhat.com/show_bug.cgi?id=2394213 bug, the changes in "sloppy" are "bug fixes/improvements", so there is no option to "remove bug fixes/improvements".

That sad "strict" has been never battle tested and has been always "use at your own risk". Since "sloppy" is the default, upstream prioritized fixing/improving "sloppy" before improving "strict" further.

You could help testing "strict" on your own machine for Fedora. I would however not try "strict" as a distro default with v107 or earlier.

I do think it would be a reasonable goal to at least consider "strict" as default in some future Fedora releases with v108 or later."

That doesn't give us any really great options here :(

I also detected an anomaly in the initrd:

[root@eve init]# du -sh usr/lib/firmware/nvidia/ga102/gsp/*
36K	usr/lib/firmware/nvidia/ga102/gsp/booter_load-535.113.01.bin.xz
36K	usr/lib/firmware/nvidia/ga102/gsp/booter_load-570.144.bin.xz
20K	usr/lib/firmware/nvidia/ga102/gsp/booter_unload-535.113.01.bin.xz
24K	usr/lib/firmware/nvidia/ga102/gsp/booter_unload-570.144.bin.xz
20K	usr/lib/firmware/nvidia/ga102/gsp/bootloader-535.113.01.bin.xz
20K	usr/lib/firmware/nvidia/ga102/gsp/bootloader-570.144.bin.xz
25M	usr/lib/firmware/nvidia/ga102/gsp/gsp-535.113.01.bin.xz
49M	usr/lib/firmware/nvidia/ga102/gsp/gsp-570.144.bin.xz

I'm pretty sure, two different firmware versions are a mistake:

[root@eve init]# rpm -qf /usr/lib/firmware/nvidia/ga102/gsp/booter_load-570.144.bin.xz 
nvidia-gpu-firmware-20250808-1.fc41.noarch
[root@eve init]# rpm -qf /usr/lib/firmware/nvidia/ga102/gsp/booter_load-535.113.01.bin.xz
nvidia-gpu-firmware-20250808-1.fc41.noarch


the initrd size on a intel only device, it just 35M total.

I think that's normal. There are multiple versions of the NVIDIA proprietary driver that support different hardware. You may need one or the other depending on what card you have.

For the long term solution, would it make sense to merge https://github.com/dracut-ng/dracut-ng/commit/bc69bf4e3416791b50ad09d4b9d218e05b46c99d into rawhide to start collecting feedback on default strict mode from Fedora users ? 

I expect that based on Rawhide data and back porting some PRs to v107 strict mode could be enabled as default even on v107.

(In reply to Adam Williamson from comment #4)
> I'm proposing this as a Final blocker as a conditional violation of "For
> each one of the release-blocking package sets, it must be possible to
> successfully complete a direct upgrade from a fully updated, clean default
> installation of each of the last two stable Fedora releases with that
> package set installed" for folks upgrading from Fedora 41 with small /boot
> partitions. (I say F41 specifically because F42 was already updated to 107
> itself, but F41 was not).

Adam, can you reproduce a failed upgrade on any "clean default installation" of F41? Because in my testing, it defaults to 1GB /boot, and that should be fine in terms of an upgrade (3 kernels installed + 1 to be installed). Only quite old systems (upgraded over many releases) that have 500 MB /boot will encounter an issue, in my experience.

ugh, good point. I didn't test, just figured it was worth considering this as a blocker, but maybe we can't :/

Discussed at the 2025-09-15 (blocker / freeze exception) review meeting:

This bug is accepted as a violation of the "Upgrade requirements" criterion because increasing the initramfs space makes the system unable to upgrade if the space on the boot partition is taken by bigger images. It is considered serious enough to be addressed before the Final release.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-09-15/f43-blocker-review.2025-09-15-16.00.txt

Hello,

I agree this might bring negative user experience - but I decided to upgrade to dracut-107 in Fedora 42+ anyway, as it was long requested (and simply overdue).

One of the supporting reasons why, is that I have a test machine (workstation, which I think I installed with defaults) - upgraded for number of times, installed a along time ago (I can see some *fc38* files in my /boot), and it has a 1GB /boot, so I sipmly considered it enough to go with upstream direction.

I however agree it's very reasonable not to introduce this mid-cycle; and I'm sorry I did not consider reverting some of the upstream changes before; I've located these commits, which can be reverted to reduce the size in hostonly mode closer to the original one:

https://github.com/dracut-ng/dracut-ng/commit/87304767b16f45b7eacd1e5e622adab029e7902e
https://github.com/dracut-ng/dracut-ng/commit/53537ae77e49ab5ba157fdab544489db10ad8b1b
https://github.com/dracut-ng/dracut-ng/commit/8519dcdb154b55c5feb6e4638a525c33e8fa7f66
https://github.com/dracut-ng/dracut-ng/commit/de862885ec55bb19bfa3e3f1afd27577b7c5e309
https://github.com/dracut-ng/dracut-ng/commit/5ff7dab00830c25168eff1f962685ab915d3c18b

I'll carefully revert those, and will share a test build / COPR build tomorrow. I'd very much appreciate any help with testing the chages prior to pushing.

I've set the bug to version F42, as I don't really see this as an issue on any machine with 1GB+ initrd. I hope upstream will introduce some compatibility in next release (now the issue has their attention). A workaround for users with 500MB boot would be to use strict hostonly mode (which will be more stable+used in the future). I'd however not recommend setting it as default, as of now.

Please let me know if you want me to revert more commits; or disagree with the above, so I can better see how to resolve this.

___________________________

@lruzicka can you give me more information on the blocker? Most importantly, why was the decision made, and what are the expectations? Do we really want to patch this behaviour downstream "in the long run"? Is the size difference that serious for users (which ones?), when there's a simple workaround (drop-in config with `hostonly_mode="strict"`).

I think the expected long term plan would be to use strict mode. Not sure whether it makes the most sense to start that with F43 or F44.

I think sloppy and a 1GiB boot volume has an indeterminate time frame of reliability. The growth rate of firmware is high, and there's more firmware in the sloppy initramfs, therefore I think 1GiB boot may not be big enough for the next 5 years.

It's been 8-9 years since 1GiB boot came along and yet we're running into cases with 500M boot becoming full.

Kdump isn't commonly used, but is still a valid use case. And those files are large. Dracut isn't the only consumer of the boot volume.

It might be best to consider parallel strategies: hostonly-mode "strict" and bump the boot volume to maybe 1500MiB or even 2GiB. It is a lot of extra space, but we can't resize boot because it's wedged between two partisions.

(In reply to Adam Williamson from comment #12)
> I think the expected long term plan would be to use strict mode. Not sure
> whether it makes the most sense to start that with F43 or F44.

I don't think this is a good idea, because that will break the use-case that introduced the strict mode, which is the super minimal initrd for kdump.

I've drafted the following source-git PRs; COPR/scratch build in the comment.

F42 revert: https://github.com/redhat-plumbers/dracut-fedora/pull/72#issuecomment-3299858760
F43 revert: https://github.com/redhat-plumbers/dracut-fedora/pull/73#issuecomment-3299881256
Rawhide revert: https://github.com/redhat-plumbers/dracut-fedora/pull/74#issuecomment-3299911826

Please let me know here if you have any feedback.

> I don't think this is a good idea, because that will break the use-case that introduced the strict mode, which is the super minimal initrd for kdump.

I don't understand this. Are you saying that the 'strict' mode will be too strict for general use and making it more like the old 'sloppy' mode upstream would break its intended purpose? Or something else?

I think reverting the specific patches in 107 is fine as a short-term solution and probably the best option for fixing F42 and maybe shipping F43, but it doesn't seem sustainable as a long-term fix. It'd be a constant game of downstream whack-a-mole, and we learned that was a bad business to be in many years ago...

F42 update: https://bodhi.fedoraproject.org/updates/FEDORA-2025-8d7d432266

Please test if you can.

_________________________________

(In reply to Adam Williamson from comment #16)
> > I don't think this is a good idea, because that will break the use-case that introduced the strict mode, which is the super minimal initrd for kdump.
> 
> I don't understand this. Are you saying that the 'strict' mode will be too
> strict for general use and making it more like the old 'sloppy' mode
> upstream would break its intended purpose? Or something else?

Even upstream agrees that it's not meant for general use. And yes, modifying it for general use would most probably break it's purpose. (AFAIU "strict" very size-focused; is just to get inintrd going =root mounted, but not necessarily to "boot".)

> I think reverting the specific patches in 107 is fine as a short-term
> solution and probably the best option for fixing F42 and maybe shipping F43,
> but it doesn't seem sustainable as a long-term fix. It'd be a constant game
> of downstream whack-a-mole, and we learned that was a bad business to be in
> many years ago...

It seems upstream works on reverting those patches as well, and will most probably introduce a different arg for that "portable" usecase.

https://github.com/dracut-ng/dracut-ng/pull/1673

FTR; upstream issue about "strict" definition: https://github.com/dracut-ng/dracut-ng/issues/1669

Should this bug be cloned and set to Fedora 43 for separately tracking the blocker bug? Or revert this bug to 43, and set the clone to 42?

> 
> @lruzicka can you give me more information on the blocker? Most
> importantly, why was the decision made, and what are the expectations? Do we
> really want to patch this behaviour downstream "in the long run"? Is the
> size difference that serious for users (which ones?), when there's a simple
> workaround (drop-in config with `hostonly_mode="strict"`).

If you mean the decision about the blocker, that was voted on at the last blocker review meeting and it passed almost unanimously. There were around six people present; five voted in favor. I didn’t vote myself because I was chairing the meeting at the time (Adam was unavailable due to other commitments), but overall it was essentially unanimous.

The issue was that, according to the reporter and others, the sloppy mode increases the size of the initramfs, causing the boot partition to fill up more quickly. I pointed out that the ability to swap hardware and still boot successfully is actually a good thing. However, they argued that the rescue kernel provides the same benefit, and that users with small boot partitions could be at risk of not being able to upgrade because they might run out of space for a new kernel.

I've questioned the blocker status here, and we're happy to see your opinions there as well:
https://pagure.io/fedora-qa/blocker-review/issue/1925#comment-986066

Pavel, what's the current plan/status here? It'd be good to get any planned changes in soon for testing. Thanks.

> The issue was that, according to the reporter and others, the sloppy mode
> increases the size of the initramfs, causing the boot partition to fill up
> more quickly. I pointed out that the ability to swap hardware and still boot
> successfully is actually a good thing. However, they argued that the rescue
> kernel provides the same benefit, and that users with small boot partitions
> could be at risk of not being able to upgrade because they might run out of
> space for a new kernel.

Also it stops devices with less RAM booting, like anything with 512Mb of RAM, which means a bunch of arm devices and likely small VMs run out of memory trying to load the initrd into RAM.

> It seems upstream works on reverting those patches as well...
> https://github.com/dracut-ng/dracut-ng/pull/1673

Upstream patch landed ..

Yes, but upstream is past 109 at this point. F43 is on 107. We don't really want to do a major bump for F43 at this point.

In my opinion upstream patch can be back-ported to 107.

The situation is pretty dire here, for some configurations, even with 1G /boot.

I installed F43 beta a few days ago on an older laptop with Intel and NVIDIA GPUs (Optimus). Can't compare with previous versions on this system as it did not run Linux.

After updates, with just 2 kernels (1 update) I have very little space left:

df -h says
/dev/sda5       974M  692M  215M  77% /boot

ls -lh /boot/
total 661M
-rw-r--r--. 1 root root 286K Aug 25 03:00 config-6.17.0-0.rc3.31.fc43.x86_64
-rw-r--r--. 1 root root 286K Sep 22 03:00 config-6.17.0-0.rc7.56.fc43.x86_64
drwx------. 4 root root 4.0K Sep 26 00:57 efi
drwx------. 5 root root 4.0K Sep 30 21:31 grub2
-rw-------. 1 root root 257M Sep 26 00:58 initramfs-0-rescue-80abdb9ce6a54f37ac05594d543b640e.img
-rw-------. 1 root root 166M Sep 26 00:59 initramfs-6.17.0-0.rc3.31.fc43.x86_64.img
-rw-------. 1 root root 165M Sep 25 22:36 initramfs-6.17.0-0.rc7.56.fc43.x86_64.img
drwxr-xr-x. 3 root root 4.0K Sep 26 00:57 loader
drwx------. 2 root root  16K Sep 26 00:55 lost+found
lrwxrwxrwx. 1 root root   51 Sep 26 00:57 symvers-6.17.0-0.rc3.31.fc43.x86_64.xz -> /lib/modules/6.17.0-0.rc3.31.fc43.x86_64/symvers.xz
lrwxrwxrwx. 1 root root   51 Sep 25 22:36 symvers-6.17.0-0.rc7.56.fc43.x86_64.xz -> /lib/modules/6.17.0-0.rc7.56.fc43.x86_64/symvers.xz
-rw-r--r--. 1 root root  12M Aug 25 03:00 System.map-6.17.0-0.rc3.31.fc43.x86_64
-rw-r--r--. 1 root root  12M Sep 22 03:00 System.map-6.17.0-0.rc7.56.fc43.x86_64
-rwxr-xr-x. 1 root root  17M Sep 26 00:58 vmlinuz-0-rescue-80abdb9ce6a54f37ac05594d543b640e
-rwxr-xr-x. 1 root root  17M Aug 25 03:00 vmlinuz-6.17.0-0.rc3.31.fc43.x86_64
-rwxr-xr-x. 1 root root  17M Sep 22 03:00 vmlinuz-6.17.0-0.rc7.56.fc43.x86_64

The initramfs images add up to 588M, with the kernels and System.map there's room for just a third kernel and even that is tight (165M + 17M + 17M = 199M, very close to the 215M free). If dnf keeps 3 kernels by default as searches suggest and if, on the 4th one, it first adds the files and then deletes this means guaranteed failure after a few updates.

I unpacked initramfs-6.17.0-0.rc3.31.fc43.x86_64.img via lsinitrd --unpack in a dir in my home.

Exploring the largest 40 contributors to that I get:
find . -type f -exec du -b {} + | sort -nr | head -40

51324396	./usr/lib/firmware/nvidia/ga102/gsp/gsp-570.144.bin.xz
25639648	./usr/lib/firmware/nvidia/ga102/gsp/gsp-535.113.01.bin.xz
13745780	./etc/udev/hwdb.bin
13371848	./usr/lib/firmware/nvidia/tu102/gsp/gsp-570.144.bin.xz
12589816	./usr/lib/firmware/nvidia/tu102/gsp/gsp-535.113.01.bin.xz
5609440	./usr/lib64/libcrypto.so.3.5.1
5151544	./usr/lib64/systemd/libsystemd-shared-258-1.fc43.so
3700240	./usr/bin/NetworkManager
2889016	./usr/lib64/libgnutls.so.30.40.4
2783376	./usr/bin/lvm
2668216	./usr/lib64/systemd/libsystemd-core-258-1.fc43.so
2492976	./usr/lib64/ossl-modules/fips.so
2459528	./usr/lib64/libc.so.6
2081688	./usr/bin/dhclient
1934632	./usr/lib64/libgio-2.0.so.0.8600.0
1836716	./usr/lib/modules/6.17.0-0.rc7.56.fc43.x86_64/kernel/drivers/gpu/drm/i915/i915.ko.xz
1787576	./usr/libexec/vi
1756032	./usr/lib64/libunistring.so.5.0.0
1578568	./usr/bin/nvme
1544392	./usr/lib64/libgcrypt.so.20.5.1
1524144	./usr/lib64/libnm.so.0.1.0
1514304	./usr/lib64/libp11-kit.so.0.4.3
1502072	./usr/bin/bash
1422808	./usr/lib/systemd/systemd-executor
1420568	./usr/lib64/libglib-2.0.so.0.8600.0
1364392	./usr/bin/btrfs
1279712	./usr/lib64/libharfbuzz.so.0.61151.0
1226448	./usr/lib64/libsystemd.so.0.41.0
1151492	./usr/lib/modules/6.17.0-0.rc7.56.fc43.x86_64/kernel/drivers/gpu/drm/nouveau/nouveau.ko.xz
1009248	./usr/lib64/libm.so.6
983840	./usr/lib64/ld-linux-x86-64.so.2
982512	./usr/lib64/libssl.so.3.5.1
972144	./usr/lib64/libnftables.so.1.1.0
949552	./usr/bin/nmcli
923752	./usr/lib64/libcurl.so.4.8.0
898440	./usr/lib64/libtss2-fapi.so.1.0.0
886480	./usr/bin/gawk
874712	./usr/bin/xfs_repair
857528	./usr/bin/xfs_db
840624	./usr/lib64/libfreetype.so.6.20.2

NVIDIA firmware alone adds up to 102MB uncompressed. Add 13MB for hwdb.bin, add ~ 35 other files > 1MB, even with compression, can see how it adds up to 165MB.

I checked out the upstream repo, and built images in various combinations of hostonly (sloppy and strict), on tags going from 101 to 108 plus current tip of the main branch. Will attach script and full results. Summary is: strict is 134MB, sloppy is 165MB going all the way back to the 103 tag. The tag makes no difference. So I guess this kind makes it another bug: /boot space will not suffice for NVIDIA users over the lifetime of F43. Should I file another bug? Seems serious enough for me to also be a F43 final blocker, NVIDIA is very common and the problem is pretty much guaranteed.

Created attachment 2108157 [details]
Script to explore resulting sizes - ran these as my user not root and they showed some errors but expect that does not influence the final size much

Created attachment 2108158 [details]
Sizes of images per dracut tag - shows the dracut version does not matter much as NVIDIA dominates

Indeed, got the 6.17.0 kernel upgrade and now df -h says

> /dev/sda5       974M  885M   23M  98% /boot

Further discussion here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HK3SXYGZFXE3VJZHCXMIB5VIGS37QGXO/

This Fedora 42 user reports a ~280 MB rescue initramfs, and ~180 MB hostonly initramfs before revert, and ~156 MB after revert. The after reversion initramfs is still too big for some users. Removing 100 MB of that because nvidia firmware and we can't do much about that right now, leaves 56 MB which is 2x what I'd expect.
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/Q7QDXSHSFVSDXKES53NBG7ITIJKEGNC5/

Was asked to add this from email discussion on Fedora list

Did see a slightly smaller kernel size on machine if nvidia card after 107 dracut. dropped from 180 to 156?
 
 180180424 Sep 20 07:48 /boot/initramfs-6.16.5-200.fc42.x86_64.img
 180186953 Sep 21 09:10 /boot/initramfs-6.16.7-200.fc42.x86_64.img
 156167106 Sep 26 14:36 /boot/initramfs-6.16.8-200.fc42.x86_64.img
 279490712 Sep 26 14:43 /boot/initramfs-0-rescue-5454d68084c145e496d5ce383b5147de.img

The first two created with earlier dracut. The last two created after 107.

Have another Dell Lattitude 5580 without nvidia and its kernels are
  53293213 Sep 24 19:56 /boot/initramfs-6.16.8-200.fc42.x86_64.img
  78165169 Sep 15 17:12 /boot/initramfs-6.16.7-200.fc42.x86_64.img
  79431805 Sep  9 18:32 /boot/initramfs-6.16.5-200.fc42.x86_64.img
 177136228 Sep 15 17:13 /boot/initramfs-0-rescue-3b8d97eb0c824e69a66569165466fcc9.img

First kernel is new after 107, others were created earlier.

Created attachment 2108260 [details]
lsinitrd -s /boot/initramfs-6.16.8-200.fc42.x86_64.img  output

From discussion on Fedora list asked to do lsinitrd and upload output.

The most important comparison, I think, would be dracut 105 vs. post-revert dracut 107. Without NVIDIA involved because it will confuse things if linux-firmware version was different between the images.

dracut can't really do anything about NVIDIA dumping more firmware on us.

(In reply to Michael Setzer II from comment #33)
> Created attachment 2108260 [details]
> lsinitrd -s /boot/initramfs-6.16.8-200.fc42.x86_64.img  output

OK I'm seeing some dupes, but I'm not sure why the 32-bit version is also being pulled into the initramfs.

-rwxr-xr-x   1 root     root      2447520 Aug 26 10:00 usr/lib64/libc.so.6
-rwxr-xr-x   1 root     root      2453956 Aug 26 10:00 usr/lib/libc.so.6
-rwxr-xr-x   1 root     root      5012704 Jul 14 10:00 usr/lib64/libcrypto.so.3.2.4
-rwxr-xr-x   1 root     root      4314176 Jul 14 10:00 usr/lib/libcrypto.so.3.2.4

(In reply to Adam Williamson from comment #34)
> The most important comparison, I think, would be dracut 105 vs. post-revert
> dracut 107.

Yeah, I was mentally deducting the 100 MB nvidia from Mike's initramfs, but still wondering why it's so big.

a. I think if we ask Mike to downgrade dracut to 105:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2691637

b. Run it with defaults, e.g.
sudo dracut /boot/initramfs-6.16.8-200.fc42-dracut105.x86_64.img 6.16.8-200.fc42.x86_64

c. Report back on that file's size so we can compare to 
156167106 Sep 26 14:36 /boot/initramfs-6.16.8-200.fc42.x86_64.img

d. If it's meaningfully smaller, another lsinitrd -s might help show the differences. 

(I'm curious if those 32-bit libraries are not present in the 105 version. I'm suspicious anything needs 32-bit libraries during boot.)

It seems like the current likely option is for /boot to be expanded to 2GB https://pagure.io/fesco/issue/3482 which will fix this for new installs.

Still seems good to try to find a solution for people (in general and with NVIDIA in particular) upgrading which keep 500MB or 1GB.

(In reply to Laszlo from comment #24)
> > It seems upstream works on reverting those patches as well...
> > https://github.com/dracut-ng/dracut-ng/pull/1673
> 
> Upstream patch landed ..

I can give some numbers on the effect of this on my machine
- 107-7.fc43:                                                                                       sloppy 165MB, strict 134MB
- upstream commit 54c0f12f, the one right before https://github.com/dracut-ng/dracut-ng/pull/1673:  sloppy 186MB, strict 131MB
- upstream commit ac8cb5e5, the one from https://github.com/dracut-ng/dracut-ng/pull/1673:          sloppy 145MB, strict 131MB
- upstream main as of today 7f41458b:                                                               sloppy 145MB, strict 131MB

So seems like backporting https://github.com/dracut-ng/dracut-ng/pull/1673 does make sense

Another idea (on top of the backport) would be to follow https://github.com/dracut-ng/dracut-ng/pull/1175 which deletes some AMD firmware files based on criteria like "this is x86 and that firmware is not for x86". For NVIDIA the firmware files seem to be per "family" so just ga102 or tu102 etc would be kept depending on the GPU model. It's brittle and someone would need to write that code but would be reasonably effective (least effective for the newer GPUs with large firmware but those are more likely to be fresh installs).

(In reply to Catalin Iacob from comment #37)
> It seems like the current likely option is for /boot to be expanded to 2GB
> https://pagure.io/fesco/issue/3482 which will fix this for new installs.

It won't fix it for smaller devices with < 1Gb RAM.

Catalin: thanks for the tests, but they're missing an important line. The current F43 package doesn't have *any* backport/change for this bug at all. For some reason, Pavel only did it in the F42 build - dracut-107-4.fc42 . The comparison I'd most like to see is dracut 105 vs. dracut-107-4.fc42. That would tell us whether doing in F43 what was done in F42 would be a sufficient solution.

AdamW: don't have F42 but took the builds from https://bodhi.fedoraproject.org/updates/?search=&packages=dracut&releases=F42 and scripted to unpack them side by side in my home and run with dracutbasedir set appropriately to pick up the respective versions. To be sure I'm running the unpacked dracut and not the F43 system one the script does a dracutbasedir=path_here dracut --version and compares it to the expected  version as a sanity check.

The results match the fact that Pavel's patch in https://github.com/redhat-plumbers/dracut-fedora/pull/72#issuecomment-3299858760 appears in 107-3, that shaves 8MB from sloppy but is still 4MB larger than 105. For this system not a huge difference but that's due to the large NVIDIA firmware which gets into all and dominates everything else.

105-2-sloppy 136M
105-2-strict 129M

105-3-sloppy 136M
105-3-strict 129M

107-1-sloppy 148M
107-1-strict 133M

107-2-sloppy 148M
107-2-strict 133M

107-3-sloppy 140M
107-3-strict 133M

107-4-sloppy 140M
107-4-strict 133M

(In reply to Adam Williamson from comment #22)
> Pavel, what's the current plan/status here? It'd be good to get any planned
> changes in soon for testing. Thanks.

I'll backport this ASAP; ideally by EOW. The plan is to backport upstream fix (https://github.com/dracut-ng/dracut-ng/pull/1673/) and then check back here for feedback/possible improvements.

Thanks. ASAP would really help, as we're in the final freeze now.

I see this commit for Rawhide but no equivalent commit for Fedora 43.
https://src.fedoraproject.org/rpms/dracut/c/6908946c3c0751e9ca807bd230ba62e8a42d38f8?branch=rawhide

This should be POST as there's no change landed downstream for F43 yet.

FEDORA-2025-ab1996ab09 (dracut-107-8.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-ab1996ab09

Welp, since it still didn't happen I went ahead and did it myself. I took the rawhide patch and rediffed it. It only needed filename changes to reflect the fact that all the modules got given different numbers between 107 and 108.

FEDORA-2025-ab1996ab09 has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-ab1996ab09`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-ab1996ab09

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2025-ab1996ab09 (dracut-107-8.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.

We still need verification for this blocker, reopening.

I performed F43 Beta (dracut-107-6.fc43.x86_64) and Final RC1.4 (dracut-107-8.fc43.x86_64) installation on an AMD GPU laptop, there is a reduction 89M->68M for the regular initramfs image:

Beta:
# ls -lh initramfs*
-rw-------. 1 root root 257M Oct 21 12:12 initramfs-0-rescue-4d109538e03441c0a54f96d95a84bf63.img
-rw-------. 1 root root  89M Oct 21 12:12 initramfs-6.17.0-0.rc3.31.fc43.x86_64.img

Final:
# ls -lh initramfs*
-rw-------. 1 root root 257M Oct 22  2025 initramfs-0-rescue-98d43f2ea76043db8e2ef3dd04f8015d.img
-rw-------. 1 root root  68M Oct 21 12:21 initramfs-6.17.1-300.fc43.x86_64.img


Can somebody please confirm whether this is within the expected range of improvements, and we can close this bug, or whether this is not good enough? Thanks.
(I might be able to test with an nvidia gpu laptop tomorrow, if needed, but I don't know which gpu family it is atm).

And F42 (dracut-105-2.fc42.x86_64) for comparison, on the same hardware:

# ls -lh initramfs*
-rw-------. 1 root root 168M Oct 22 03:29 initramfs-0-rescue-8aa16be25c714973aea2b6c336e36c2f.img
-rw-------. 1 root root  53M Oct 22 03:29 initramfs-6.14.0-63.fc42.x86_64.img


So going from F42 to F43 RC 1.4, we have:
initramfs          53 -> 68M
initramfs-rescue   168 -> 257M

I *think* the rescue image size is not relevant to *this* bug as this is about changes to hostonly and the rescue initramfs is not built hostonly. /usr/lib/kernel/install.d/51-dracut-rescue.install says:

            dracut -f --no-hostonly --no-uefi \
                -a "rescue" \
                $([[ $KERNEL_INSTALL_VERBOSE == 1 ]] && echo --verbose) \
                --kver "$KERNEL_VERSION" \
                "$BOOT_DIR_ABS/$INITRD"

so, we're only concerned with 'regular' initramfs'es in this bug. To be real sure, we should account for the 53 -> 68M growth in yours. I'd do this by mounting it and using du or baobab to compare the contents - does the F43 RC 1.4 one have stuff in it that the F42 one doesn't? Or does it have the same stuff but that stuff got bigger?

I'll try and run this experiment on my end today if I get time.

Hello,

I tried old dracut and new dracut at "Slimbook" with nvidia graphics :

lspci -nn:

01:00.0 3D controller [0302]: NVIDIA Corporation GA107M [GeForce RTX 3050 Ti Mobile] [10de:25a0] (rev a1)
00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-P GT2 [Iris Xe Graphics] [8086:46a6] (rev 0c)

=====
I have fedora43 with 
initramfs-6.17.1-300.fc43.x86_64.img

I regenerated with BOTH old and new dracut (dracut -f).
There is also initramfs which comes with installation. It was created during installation.



the differences:

OLD REGENERATED by dracut-105-2.fc43
141M	./initramfs-6.17.1-300.fc43.x86_64.img
files: 3085

NEW REGENERATED by dracut-107-8.fc43
147M	./initramfs-6.17.1-300.fc43.x86_64.img
module:tpm2-tss this module was added
files: 3207


I would say that more 6MB are due to:
new dracut adds module tpm2-tss + adds some files about that, with no big amount of data
updated drivers: /usr/lib/firmware/nvidia and /usr/lib/firmware/i915

Top 10 Largest New Files Added:
Size	File	Purpose
1.7 MB	libunistring.so.5.0.0	Unicode string handling library
923 KB	libcurl.so.4.8.0	HTTP client library for network operations
898 KB	libtss2-fapi.so.1.0.0	TPM2 Feature API library
874 KB	xfs_repair	XFS filesystem repair utility
857 KB	xfs_db	XFS filesystem debugger
837 KB	libkrb5.so.3.3	Kerberos authentication library
728 KB	btrfstune	Btrfs filesystem tuning utility
672 KB	tpm2	TPM2 command-line tools
621 KB	libcryptsetup.so.12.11.0	Disk encryption library
579 KB	libtss2-esys.so.1.0.0	TPM2 Enhanced System API



-------------

F43 after installation, not changed by user, not regenerated by user
150M	./initramfs-6.17.1-300.fc43.x86_64.img
files: 3236 , slightly more compare to dracut -f

changes between F43 initramfs regenerated by user:
+3MB

Files Removed During Regeneration (30 files, 2.59 MB):
Largest Removed Files:
XFS filesystem module (xfs.ko.xz) - 1.1 MB - Complete XFS filesystem support
QLogic iSCSI driver (qla4xxx.ko.xz) - 197 KB - Enterprise iSCSI adapter
JFS filesystem (jfs.ko.xz) - 160 KB - IBM JFS filesystem
Module metadata (modules.alias, modules.alias.bin) - 263 KB - Kernel module aliases
Network filesystem (netfs.ko.xz) - 123 KB - Network filesystem helpers
Module symbols (modules.symbols.bin, modules.symbols) - 181 KB - Kernel symbols
EROFS filesystem (erofs.ko.xz) - 96 KB - Enhanced Read-Only File System
HFS+ filesystem (hfsplus.ko.xz) - 84 KB - Apple HFS+ filesystem
HFS filesystem (hfs.ko.xz) - ~50 KB - Apple HFS filesystem
Other filesystem modules (ISO, MINIX, UFS, MSDOS) - ~100 KB

===
I would say there is no regression between dracut-105-2.fc43 and dracut-107-8.fc43.
There are added files about TPM2 modules, and some minor app and libraries

Created attachment 2110457 [details]
lsinitrd initramfs-6.17.1-300.fc43.x86_64.img -s

Created attachment 2110458 [details]
lsinitrd initramfs-6.17.1-300.fc43.x86_64.img -s

file regenerated by 'dracut -f' with old dracut-105-2.fc43

Created attachment 2110459 [details]
files in initramfs which comes after installations

Thanks a lot for the detailed analysis!

It looks like we've pretty much done all we can here, so closing.

Hello Adam,

thanks for fixing this for F43; I have prepared identical PR[1] to what you have pushed before I got sick (sorry I could not finish it).

[1] https://github.com/redhat-plumbers/dracut-fedora/pull/79

sigh, somehow I never find pull requests. :D hope you're feeling better now!

Do we have any advice for users of older installations with < 500 MB /boot?  With NVIDIA firmware, kernel upgrades fail even with installonly_limit=2 in /etc/dnf/dnf.conf.  Should there be something in the release notes telling them to repartition or reinstall?

(In reply to Peter Oliver from comment #61)
> Do we have any advice for users of older installations with < 500 MB /boot? 
> With NVIDIA firmware, kernel upgrades fail even with installonly_limit=2 in
> /etc/dnf/dnf.conf.  Should there be something in the release notes telling
> them to repartition or reinstall?

I think it's a reprovision, yes. Less than 500 MiB /boot would be quite a while ago.

(In reply to Peter Oliver from comment #61)
> Should there be something in the release notes telling
> them to repartition or reinstall?

We covered it in common issues (but we haven't made a comment about it here in Bugzilla, sorry):
https://discussion.fedoraproject.org/t/170285