After upgrade to Fedora 44, dracut fails to create initramfs

Greetings!

After upgrading one of my machines from F43→F44, I find that it’s still running the F43 kernel:

# rpm -q kernel
kernel-7.0.6-100.fc43.x86_64
kernel-7.0.6-200.fc44.x86_64
kernel-7.0.8-200.fc44.x86_64
# uname -a
Linux firiel 7.0.6-100.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Wed May 13 14:54:26 UTC 2026 x86_64 GNU/Linux

Apparently, dracut is unable to create an initramfs for any of the F44 kernels and gives errors about libc and libpthread:

# ll /boot/initramfs-*
-rw------- 1 root root 96355179 Dec 18  2023 /boot/initramfs-0-rescue-6d4ccc83295bb7e0574eda00458c6d8d.img
-rw------- 1 root root 43843404 May 14 10:47 /boot/initramfs-7.0.6-100.fc43.x86_64.img
# ll /boot/vmlinuz-*
-rwxr-xr-x 1 root root 14669576 Dec 18  2023 /boot/vmlinuz-0-rescue-6d4ccc83295bb7e0574eda00458c6d8d
-rwxr-xr-x 1 root root 18430312 May 13 02:00 /boot/vmlinuz-7.0.6-100.fc43.x86_64
-rwxr-xr-x 1 root root 18684264 May 13 02:00 /boot/vmlinuz-7.0.6-200.fc44.x86_64
-rwxr-xr-x 1 root root 18684264 May 15 02:00 /boot/vmlinuz-7.0.8-200.fc44.x86_64
# dnf reinstall kernel-core
Updating and loading repositories:
Repositories loaded.
Package                                     Arch        Version                                     Repository                  Size
Reinstalling:
 kernel-core                                x86_64      0:7.0.8-200.fc44                            updates                 99.1 MiB
   replacing kernel-core                    x86_64      0:7.0.8-200.fc44                            updates                 99.1 MiB

Transaction Summary:
 Reinstalling:       1 package
 Replacing:          1 package

Total size of inbound packages is 20 MiB. Need to download 20 MiB.
After this operation, 0 B extra will be used (install 99 MiB, remove 99 MiB).
Is this ok [y/N]: y
[1/1] kernel-core-0:7.0.8-200.fc44.x86_64                                                   100% |   7.2 MiB/s |  20.4 MiB |  00m03s
------------------------------------------------------------------------------------------------------------------------------------
[1/1] Total                                                                                 100% |   6.1 MiB/s |  20.4 MiB |  00m03s
Running transaction
[1/4] Verify package files                                                                  100% |   1.0   B/s |   1.0   B |  00m01s
[2/4] Prepare transaction                                                                   100% |   2.0   B/s |   2.0   B |  00m01s
[3/4] Reinstalling kernel-core-0:7.0.8-200.fc44.x86_64                                      100% |   7.8 MiB/s |  29.6 MiB |  00m04s
[4/4] Removing kernel-core-0:7.0.8-200.fc44.x86_64                                          100% |   0.0   B/s |  17.0   B |  01m00s
>>> Running %posttrans scriptlet: kernel-core-0:7.0.8-200.fc44.x86_64
>>> Finished %posttrans scriptlet: kernel-core-0:7.0.8-200.fc44.x86_64
>>> Scriptlet output:
>>> dracut-install: ERROR: could not locate dependency libpthread.so.0 requested by '/var/tmp/dracut.dny69x6/initramfs/usr/lib/liblzma.so.5.2.2'
>>> dracut-install: ERROR: could not locate dependency libc.so.6 requested by '/var/tmp/dracut.dny69x6/initramfs/usr/lib/liblzma.so.5.2.2'
>>> xargs: /usr/lib/dracut/dracut-install: exited with status 255; aborting
>>> dracut[F]: Resolving executable dependencies failed
>>> /usr/lib/kernel/install.d/50-dracut.install failed with exit status 1.
>>> 
Complete!

I get the same errors when running dracut manually.

Any ideas? Reinstalling glibc, xz-libs and dracut did not help, and the system works fine otherwise.

I get the same error on my machine due lack of space in /boot or /boot/efi, I’m not sure which.

The solution is to remove the oldest kernel, reboot and dnf update --refresh.

dnf remove kernel-core-7.0.6*

in my example, you have to use your own kernel version of course.

And you may have to reinstall the latest kernel

dnf reinstall kernel-*-7.0.8*

again in my example.

No, this doesn’t seem to be it.

I removed the 7.0.6 F44 kernel (don’t want to lose the working F43 one), but I still get the same dracut error when reinstalling 7.0.8.

Also, /boot is a 1G volume with over 70% free space:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       230G  160G   70G  70% /
devtmpfs        7.6G     0  7.6G   0% /dev
tmpfs           7.6G     0  7.6G   0% /dev/shm
tmpfs           3.1G  1.4M  3.1G   1% /run
none            1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
none            1.0M     0  1.0M   0% /run/credentials/systemd-resolved.service
/dev/sdc        932G  524G  407G  57% /data
/dev/sda1      1007M  221M  787M  22% /boot
tmpfs           128M     0  128M   0% /tmp
none            1.0M     0  1.0M   0% /run/credentials/getty@tty1.service
tmpfs           1.6G   28K  1.6G   1% /run/user/0

(There is no /boot/efi, as this is a legacy system.)

My kernel versions was just example from my setup.

And you did the dnf reinstall and not just dnf update?

If this did not work, then I am unable to help further. Sorry

Did you reinstall the 32 bit versions, or the 64 bit ones? Because it appears to be 32 bit ones it is complaining about?

Have these two libs missing is your problem.
But I’d expect your system to be very broken if those two .SO are missing.

Check for them in /lib64 for bopth of them,

Do you have ant dracut custom rules that might explain the odd error messages?

There don’t seem to be any 32-bit versions of packages installed on the system:

# rpm -qa | grep i686
# rpm -q glibc xz-libs dracut kernel-core
glibc-2.43-5.fc44.x86_64
xz-libs-5.8.2-2.fc44.x86_64
dracut-108-7.fc44.x86_64
kernel-core-7.0.6-100.fc43.x86_64
kernel-core-7.0.8-200.fc44.x86_64

Fedora is a 64bit system, dracut does not need any 32bit libs.
Did I miss something in the output that said its 32 bit that is missing?

Well mostly that the path was /usr/lib not /usr/lib64 in the errors?

/etc/dracut.conf.d is empty, and /etc/dracut.conf contains just three comment lines:

# ll /etc/dracut.conf.d/
total 0
# cat /etc/dracut.conf
# PUT YOUR CONFIG IN separate files
# in /etc/dracut.conf.d named "<name>.conf"
# SEE man dracut.conf(5) for options

System library installation looks inconspicuous:

# rpm -V glibc glibc-devel xz-libs
# ll /lib64/{libc,libpthread,liblzma}.*
-rw-r--r-- 1 root root     253 May 12 02:00 /lib64/libc.so
-rwxr-xr-x 1 root root 2490288 May 12 02:00 /lib64/libc.so.6
lrwxrwxrwx 1 root root      16 Jan 17 01:00 /lib64/liblzma.so.5 -> liblzma.so.5.8.2
-rwxr-xr-x 1 root root  219768 Jan 17 01:00 /lib64/liblzma.so.5.8.2
-rw-r--r-- 5 root root       8 May 12 02:00 /lib64/libpthread.a
-rwxr-xr-x 1 root root   11272 May 12 02:00 /lib64/libpthread.so.0
# rpm -qf /lib64/{libc,libpthread,liblzma}.*
glibc-devel-2.43-5.fc44.x86_64
glibc-2.43-5.fc44.x86_64
glibc-devel-2.43-5.fc44.x86_64
glibc-2.43-5.fc44.x86_64
xz-libs-5.8.2-2.fc44.x86_64
xz-libs-5.8.2-2.fc44.x86_64

Although Tom is right, the dracut error message mentions “/var/tmp//initramfs/usr/lib/liblzma.so.5.2.2” which is not the version from the xz-libs package. Where does that come from?

Oh, there is in fact a 32-bit liblzma installed in /usr/lib:

# ll /usr/lib/liblzma.so.5*
lrwxrwxrwx 1 root root     16 Feb  5  2016 /usr/lib/liblzma.so.5 -> liblzma.so.5.2.2
-rwxr-xr-x 1 root root 172936 Feb  5  2016 /usr/lib/liblzma.so.5.2.2
# file /usr/lib/liblzma.so.5.2.2 
/usr/lib/liblzma.so.5.2.2: ELF 32-bit LSB shared object, Intel i386, version 1 (SYSV), dynamically linked, BuildID[sha1]=42f40682218d14111a97f2e4dcc3c42ac040930f, stripped
# rpm -qf liblzma.so.5*
file /usr/lib/liblzma.so.5 is not owned by any package
file /usr/lib/liblzma.so.5.2.2 is not owned by any package

This must have been a leftover from some earlier upgrade process. I think this system was originally installed with Fedora Core 1 back in the day and never fully reinstalled, only upgraded with each new release. Strange that it didn’t cause any issues until now…

Deleting the stray files from /usr/lib made the reinstall of kernel-core go smoothly, and the machine is now running the correct kernel.

Thanks, guys! :smiling_face_with_three_hearts:

That 32 bit fc1 would not run a 64bit os…