Earlier today while performing the update on my Fedora desktop, I encountered an issue with the new kernel update. As a result, the initramfs was not generated for the new installed kernel. So, I’ll share with you how to rebuild or generate the initramfs while fixing real issue on my Fedora workstation.
First, here is an output showing the source of the issue. It might not be clear of what’s going on, but that’s okay as it’s not the main focus of this blog post.
...
File descriptor 3 (pipe:[122032]) leaked on vgs invocation. Parent PID 33204: grub2-probe
File descriptor 9 (pipe:[122101]) leaked on vgs invocation. Parent PID 33204: grub2-probe
File descriptor 3 (pipe:[122032]) leaked on vgs invocation. Parent PID 33204: grub2-probe
File descriptor 9 (pipe:[122101]) leaked on vgs invocation. Parent PID 33204: grub2-probe
File descriptor 3 (pipe:[122032]) leaked on vgs invocation. Parent PID 33204: grub2-probe
File descriptor 9 (pipe:[122101]) leaked on vgs invocation. Parent PID 33204: grub2-probe
File descriptor 3 (pipe:[122032]) leaked on vgs invocation. Parent PID 33204: grub2-probe
File descriptor 9 (pipe:[122101]) leaked on vgs invocation. Parent PID 33204: grub2-probe
File descriptor 3 (pipe:[122032]) leaked on vgs invocation. Parent PID 33204: grub2-probe
File descriptor 9 (pipe:[122101]) leaked on vgs invocation. Parent PID 33204: grub2-probe
grub2-probe: error: ../grub-core/kern/fs.c:121:unknown filesystem.
/usr/sbin/grub2-probe: error: ../grub-core/kern/fs.c:121:unknown filesystem.
Found Fedora Linux 40 (Workstation Edition) on /dev/mapper/fedora_watkor-root_snap
warning: %posttrans(kernel-core-6.10.5-200.fc40.x86_64) scriptlet failed, exit status 1
Error in POSTTRANS scriptlet in rpm package kernel-core
Running scriptlet: kernel-modules-6.10.5-200.fc40.x86_64 142/142
Running scriptlet: acpid-2.0.34-7.fc40.x86_64 142/142
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
KeyboardInterrupt: Terminated.
I had to hit Ctrl+c
to interrupt the update process above. At this point, I suspected that the initramfs was not correctly generated correctly. One way to find out is listing the /boot
directory.
[root@watkor ~]# ls -1 /boot/initramfs*
/boot/initramfs-0-rescue-8d0434dbcc454db49d61aa54595268aa.img
/boot/initramfs-6.10.3-200.fc40.x86_64.img
/boot/initramfs-6.10.4-200.fc40.x86_64.img
[root@watkor ~]# rpm -q kernel-core
kernel-core-6.10.3-200.fc40.x86_64
kernel-core-6.10.4-200.fc40.x86_64
kernel-core-6.10.5-200.fc40.x86_64
The initramfs for new kernel 6.10.5-200.fc40.x86_64
was no where to be found.
So, how to generate the initramfs on Fedora? Simple, just reinstall the kernel-core-xxxx
package.
[root@watkor ~]# dnf reinstall kernel-core-6.10.5-200.fc40.x86_64
... <snip> ...
Total size: 17 M
Installed size: 69 M
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] kernel-core-6.10.5-200.fc40.x86_64.rpm: Already downloaded
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Reinstalling : kernel-core-6.10.5-200.fc40.x86_64 1/2
Running scriptlet: kernel-core-6.10.5-200.fc40.x86_64 1/2
Running scriptlet: kernel-core-6.10.5-200.fc40.x86_64 2/2
Cleanup : kernel-core-6.10.5-200.fc40.x86_64 2/2
Running scriptlet: kernel-core-6.10.5-200.fc40.x86_64 2/2
dkms: running auto installation service for kernel 6.10.5-200.fc40.x86_64
Error! zfs/2.2.5 is broken! Missing the source directory or the symbolic link pointing to it.
Manual intervention is required!
dkms: autoinstall for kernel 6.10.5-200.fc40.x86_64 Done.
dracut[W]: If you need to use bluetooth, please include it explicitly.
dracut[W]: If you need to use bluetooth, please include it explicitly.
dkms: running auto installation service for kernel 6.10.5-200.fc40.x86_64
Error! zfs/2.2.5 is broken! Missing the source directory or the symbolic link pointing to it.
Manual intervention is required!
dkms: autoinstall for kernel 6.10.5-200.fc40.x86_64 Done.
Reinstalled:
kernel-core-6.10.5-200.fc40.x86_64
Complete!
Well, ignore the error with zfs kernel module for now. I’ll get it sorted soon. The most important thing is that, the initrafs for kernel 6.10.5-200 had been generated. Let’s verify that:
[root@watkor ~]# ls -1 /boot/initr*
/boot/initramfs-0-rescue-8d0434dbcc454db49d61aa54595268aa.img
/boot/initramfs-6.10.3-200.fc40.x86_64.img
/boot/initramfs-6.10.4-200.fc40.x86_64.img
/boot/initramfs-6.10.5-200.fc40.x86_64.img
/boot/initrd-plymouth.img
Alternatively, the initramfs can also be generated with dracut
command as below:
# dracut --generate-all
Now, let’s try to fix the zfs dkms issue.
[root@watkor ~]# dkms status
zfs/2.2.5: broken
Error! zfs/2.2.5: Missing the module source directory or the symbolic link pointing to it.
Manual intervention is required!
[root@watkor ~]# cd /var/lib/dkms/zfs/2.2.5
[root@watkor 2.2.5]# ls -l
total 4
drwxr-xr-x. 3 root root 4096 Aug 7 18:42 6.9.12-200.fc40.x86_64
lrwxrwxrwx. 1 root root 18 Aug 7 18:39 source -> /usr/src/zfs-2.2.5
[root@watkor 2.2.5]# ls -l /usr/src/zfs-2.2.5
ls: cannot access '/usr/src/zfs-2.2.5': No such file or directory
Wait, what? Why /usr/src/zfs-2.2.5
no longer existed? But it’s okay, I can get back by reinstalling the zfs
package.
[root@watkor ~]# dnf install zfs
Last metadata expiration check: 2:42:14 ago on Wed 21 Aug 2024 07:12:48 PM AEST.
Error:
Problem: problem with installed package zfs-fuse-0.7.2.2-30.fc40.x86_64
- package zfs-2.2.4-1.fc40.x86_64 from zfs conflicts with zfs-fuse provided by zfs-fuse-0.7.2.2-30.fc40.x86_64 from @System
- package zfs-2.2.4-1.fc40.x86_64 from zfs conflicts with zfs-fuse provided by zfs-fuse-0.7.2.2-30.fc40.x86_64 from fedora
- conflicting requests
- package zfs-2.2.5-1.fc40.x86_64 from zfs conflicts with zfs-fuse provided by zfs-fuse-0.7.2.2-30.fc40.x86_64 from @System
- package zfs-2.2.5-1.fc40.x86_64 from zfs conflicts with zfs-fuse provided by zfs-fuse-0.7.2.2-30.fc40.x86_64 from fedora
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
Wow, why did this happen again? The zfs
package had been replaced by zfs-fuse
. Well, let’s replace the zfs-fuse
package with zfs
one.
[root@watkor ~]# dnf install zfs --allowerasing
Last metadata expiration check: 2:44:39 ago on Wed 21 Aug 2024 07:12:48 PM AEST.
Dependencies resolved.
... <snip> ...
Installed:
kernel-devel-6.8.5-301.fc40.x86_64 zfs-2.2.5-1.fc40.x86_64 zfs-dkms-2.2.5-1.fc40.noarch
Removed:
kernel-devel-6.10.3-200.fc40.x86_64 zfs-fuse-0.7.2.2-30.fc40.x86_64
Complete!
Let’s list the zfs kernel module again.
[root@watkor ~]# dkms status
zfs/2.2.5, 6.10.4-200.fc40.x86_64, x86_64: installed
zfs/2.2.5, 6.9.12-200.fc40.x86_64, x86_64: installed (WARNING! Missing some built modules!) (WARNING! Missing some built modules!)
[root@watkor ~]# rpm -q kernel
kernel-6.10.3-200.fc40.x86_64
kernel-6.10.4-200.fc40.x86_64
kernel-6.10.5-200.fc40.x86_64
So, I’m missing the zfs kernel module for the new kernel kernel-6.10.5-200.fc40.x86_64
. Let’s build dksm for the missing version:
[root@watkor ~]# dkms install zfs/2.2.5 -k 6.10.5-200.fc40.x86_64
...
Building module:
Cleaning build area...
Building module(s)................................
Signing module /var/lib/dkms/zfs/2.2.5/build/module/zfs.ko
Signing module /var/lib/dkms/zfs/2.2.5/build/module/spl.ko
Running the post_build script:
Cleaning build area...
zfs.ko.xz:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/6.10.5-200.fc40.x86_64/extra/
spl.ko.xz:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/6.10.5-200.fc40.x86_64/extra/
depmod......
[root@watkor ~]# dkms status
zfs/2.2.5, 6.10.4-200.fc40.x86_64, x86_64: installed
zfs/2.2.5, 6.10.5-200.fc40.x86_64, x86_64: installed
zfs/2.2.5, 6.9.12-200.fc40.x86_64, x86_64: installed (WARNING! Missing some built modules!) (WARNING! Missing some built modules!)
The last thing to do is to reboot the system. If you don’t see any follow up on this post, then it can be assumed that everything went well. :)
Reference: