System Updater Not Creating initramfs every time it updates the kernel

Hey all,

I’ve run into a rather infuriating issue with my fedora installation. Every time the software updater updates my kernel, my system ends up failing to boot. The new kernel complains that it cannot find initramfs, so I need to reboot, go to grub, open an older kernel, then enter an elevated terminal session and run “dracut -f --regenerate-all” to force initramfs to generate.

This happens every single time an automated system update installs a newer version of my kernel.

Has anyone else experienced this? Does anyone have any idea why the updater might not be creating the new initramfs for me?

I’m running Fedora 41. This has been happening for all 6.11 and 6.12 kernels.

In the cases that I know about this failing, user has a dkms build that fails.
For dkms case I filed this bug report 2333757 – initrd is not created if a dkms build fails leaving system boot to fail

Is this also the case for you?

Hey Barry,
I am wondering if this happens when updates are run via the software/package kit updater vs running dnf manually from the command line. I have had the dkms fail, Nividia drivers …, and I still get good kernel builds/bootable updates (I am currently on 6.12.5-200.fc41.x86_64) …
The only times where this has been an issue for me is when I don’t make a conscious effort to make certain that the dracut actually finishes before a reboot …
… Just a thought …

Dracut runs synchronously which means once dnf finishes you can reboot. But the issue with dkms is a new failure mode it seems.
The only place I have dkms is with my arm VMs and since f39 always could reboot.

I’ve been having the same issue since jumping from 6.11.10 to 6.12.4 and now 6.12.5, having had to manually invoke dracut to create the initramfs image for the new kernel.
Now that i’m looking at the journal, i can see the following:

Dec 24 14:06:37 fedora packagekitd[22921]: Failed command:
Dec 24 14:06:37 fedora packagekitd[22921]: 'make' KDIR=/lib/modules/6.12.5-200.fc41.x86_64/build
Dec 24 14:06:37 fedora packagekitd[23574]: Error! Bad return status for module build on kernel: 6.12.5-200.fc41.x86_64 (x86_64)
Dec 24 14:06:37 fedora packagekitd[23574]: Consult /var/lib/dkms/hid-tmff2/0.83/build/make.log for more information.
Dec 24 14:06:37 fedora packagekitd[22614]: Autoinstall on 6.12.5-200.fc41.x86_64 failed for module(s) hid-tmff2(10).
Dec 24 14:06:37 fedora packagekitd[23575]: Error! One or more modules failed to install during autoinstall.
Dec 24 14:06:37 fedora packagekitd[23575]: Refer to previous errors for more information.
Dec 24 14:06:37 fedora packagekitd[22575]: /usr/lib/kernel/install.d/40-dkms.install failed with exit status 11.
Dec 24 14:06:37 fedora packagekitd[1113]: warning: %posttrans(kernel-core-6.12.5-200.fc41.x86_64) scriptlet failed, exit status 11

So, it appears my issue is DKMS related as well.

Can you add your logs to my bug report?

I am also having this issue for the last two kernel updates.

Updating from kernel.x86_64 6.11.10-300.fc41 to kernel.x86_64 6.11.11-300.fc41 failed to generate the file.
And updating from kernel.x86_64 6.11.11-300.fc41 to kernel.x86_64 6.12.7-200.fc41 also failed to generate the file.

To find out what is going on you can run

sudo kernel-install -v add 6.12.7-200.fc41.x86_64 /lib/modules/6.12.7-200.fc41.x86_64/vmlinuz

which will display all the steps taken and whether they were successful or not.

1 Like

A fixed dkms is in testing repos. If you enable the testing repos you could installed the fixed dkms.

My issue was that the following modules were failing to build:

> Autoinstall on 6.12.9-200.fc41.x86_64 failed for module(s) hid-xpadneo(10) xone(10).
>>> 
>>> Error! One or more modules failed to install during autoinstall.
>>> Refer to previous errors for more information.

Removing those with dkms fixed my problem.

This must what I am experiencing, still(!), on both my Fedora machines… Every time I perform an update which includes a new kernel, dracut silently fails (or I don’t see any clear sign) to build initramfs, which consequently causes the new kernel to not boot and go into kernel panic. On my stationary PC, GRUB shows the old kernels and I can easily fix the issue from an old kernel using dracut --force --kver <new kernel version>. On my Laptop though, for some reason I don’t see GRUB at all which was very painful, as I had to boot into a live usb and mount my whole filesystem and chroot into the installation and fix dracut though there.

I suspect my issue stems from this, which I managed to dig out of the journal after stumbling across this post

heinä 10 22:14:30 fedora-laptop packagekitd[31181]: Sign command: /lib/modules/6.15.4-200.fc42.x86_64/build/scripts/sign-file
heinä 10 22:14:30 fedora-laptop packagekitd[31181]: Signing key: /var/lib/dkms/mok.key
heinä 10 22:14:30 fedora-laptop packagekitd[31181]: Public certificate (MOK): /var/lib/dkms/mok.pub
heinä 10 22:14:30 fedora-laptop packagekitd[31181]: Autoinstall of module xpad/0.4 for kernel 6.15.4-200.fc42.x86_64 (x86_64)
heinä 10 22:14:31 fedora-laptop packagekitd[31396]: Building module(s)...(bad exit status: 2)
heinä 10 22:14:31 fedora-laptop packagekitd[31396]: Failed command:
heinä 10 22:14:31 fedora-laptop packagekitd[31396]: make -j16 KERNELRELEASE=6.15.4-200.fc42.x86_64 KVERSION=6.15.4-200.fc42.x86_64
heinä 10 22:14:31 fedora-laptop packagekitd[31645]: Error! Bad return status for module build on kernel: 6.15.4-200.fc42.x86_64 (x86_64)
heinä 10 22:14:31 fedora-laptop packagekitd[31645]: Consult /var/lib/dkms/xpad/0.4/build/make.log for more information.
heinä 10 22:14:31 fedora-laptop packagekitd[31181]: Autoinstall on 6.15.4-200.fc42.x86_64 failed for module(s) xpad(10).
heinä 10 22:14:31 fedora-laptop packagekitd[31646]: Error! One or more modules failed to install during autoinstall.
heinä 10 22:14:31 fedora-laptop packagekitd[31646]: Refer to previous errors for more information.
heinä 10 22:14:31 fedora-laptop packagekitd[30624]: /usr/lib/kernel/install.d/40-dkms.install failed with exit status 11.
heinä 10 22:14:31 fedora-laptop packagekitd[1100]: warning: %posttrans(kernel-core-6.15.4-200.fc42.x86_64) scriptlet failed, exit status 11

dkms fails to rebuild xpad driver each time, which, according to what you guys here have noticed, may cause the dracut “build” to fail as a consequence?

I am not quite sure personally now, should this be fixed? If so, why is it not fixed for me? Is it related to dkms or xpad specifically (in my case)?

Yeah, it seemed fixed for me for a while, but it started doing it again recently. Ive started preemptively invoking dracut manually every time I update, and eventually just removed xpad.

Actually, I just figured it out! A roller coaster of events as I created an xpad GH issue and responded to it twice myself and closed it… :smiley:
Please see the solution and reasoning here: dkms autoinstall of xpad fails after new kernel installation on fedora · Issue #325 · paroj/xpad · GitHub

Long story short, I had the xpad source code cloned locally which ofc dkms was meant to auto build with new kernels. This started failing at some (fairly) recent kernel, as some C-api had changed causing the old source code clone to be incompatible with newer kernels. The fix was to simply update the source I had locally, using the simple instructions on the github page: GitHub - paroj/xpad: Linux Kernel Driver for the Xbox/ Xbox 360/ Xbox One Controllers

cd /usr/src/xpad-0.4
sudo git fetch
sudo git checkout origin/master
sudo dkms remove -m xpad -v 0.4 --all
sudo dkms install -m xpad -v 0.4

After this, I could see the dkms statusfinally showed the xpad module for the current (6.15) kernel and everything should now be resolved, with respect to the dkms failure caused by xpad. Still waiting for RHEL fix for the bug that consequently causes dracut to fail though…