After updating nvidia-dkms today, nvidia-smi showed Failed to initialize NVML: Driver/library version mismatch. After attempting to reinstall nvidia-dkms multiple times, I fixed it by running sudo dracut-rebuild. Seems like dracut did not trigger an initramfs rebuild even after removing the module and installing it back.
If an update doesn’t finish properly it won’t run the hooks at the end that regenerate the boot images.
Without seeing the output from the update, it is hard to understand what may have happened.
1 Like
hmmm nvidia-dkms will build modules and should not be directly need initramfs rebuild or i do miss something? as long as you do not include the modules inside the initramfs…
So it looks more like dkms was not rebuilding the modules properly or failed.
But anyway welcome here and lets solve your first puzzle 
1 Like
will be this what was happen for sure…
I am experiencing this as well. When dkms builds new moduls for zfs or vmware-workstation, dracut is not creating new initrd’s. The result is, that after boot still the old modules are being loaded.
This was particularly annoying with the latest vmware update vmware-workstation 17.0.2-2 → 17.5.0-1. dkms was building the new modules, but they were not incorporated into the intrd. As a result, after boot, the new vmware-workstation app crashed the computer without any trace. No core dump, no kernel panic, just a hard reboot. A manual reinstall-kernels resolved the issue.
https://aur.archlinux.org/packages/vmware-workstation
Somehow dkms does not work well with dracut yet.
I actually made a kernel-install-for-dracut recently to rebuild the initrd’s when dkms modules change. I hadn’t released it yet because I hadn’t had a chance to test it.
1 Like
I noticed this as well in the past.
Is there any chance to make dracut or mkinitcpio a user choice during installation?
edit: actually this is a question for devs like @dalto, @joekamprad , etc…
As mentioned above. It will be resolved with the next release of kernel-install-for-dracut. It isn’t actually an issue with dracut, the hook just isn’t triggering for dkms changes.
We have talked about it in the past. Personally, I don’t think it makes sense to do so.
It would make the install more complicated for the user. We are already reaching the point where we are asking too many questions as part of the install.
It would also be quite a lot of work to implement since that is a pretty fundamental element we are switching out. There are many installer modules that do different things based on mkinitcpio vs dracut.
Lastly, it would make it more complicated to troubleshoot both the install process and installed system.
1 Like
Thanks for replying, I just prefer mkinit because we can find solutions easily looking at archwiki. On the other hand, dracut seems to be more like just another “distant” option…
If you prefer to use mkinitcpio you can install and configure mkinitcpio yourself manually, after you have it setup you can just remove dracut.
Yes, I know and already did, thanks.
But I still prefer mkinitcpio for the documentation available.