cebix
(Christian Bauer)
May 17, 2026, 4:53pm
1
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.
trugul
(Truls Gulbrandsen)
May 17, 2026, 5:15pm
2
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.
cebix
(Christian Bauer)
May 17, 2026, 5:36pm
3
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.)
trugul
(Truls Gulbrandsen)
May 17, 2026, 5:42pm
4
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
tomh
(Tom Hughes)
May 17, 2026, 5:43pm
5
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?
cebix
(Christian Bauer)
May 17, 2026, 5:55pm
7
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?
tomh
(Tom Hughes)
May 17, 2026, 6:00pm
9
Well mostly that the path was /usr/lib not /usr/lib64 in the errors?
cebix
(Christian Bauer)
May 17, 2026, 6:09pm
10
/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?
cebix
(Christian Bauer)
May 17, 2026, 6:27pm
11
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!
That 32 bit fc1 would not run a 64bit os…