One of the most common issues we see here is when someone that has an Nvidia GPU does an update, they don’t know or forget to wait the magical 5 minutes before rebooting. I’ve done it myself. This is one of those things that really impacts the new user experience and floods these forums with support requests.
It seems like there must be a better way.
I know nothing about the akmods process, but couldn’t something be done to improve this?
Run it as a foreground process instead of background so the update doesn’t complete until it’s done?
Give the user feedback that it is being built and ask them not to reboot, then tell them when it’s done?
Inhibit reboot until it’s done building?
Something else?
Expecting users to know to wait 5 minutes, or monitoring btop or installing something else, etc. to avoid this is not user friendly. It needs to automatically handle this better for all users.
It would need to accommodate updates done both through CLI and GUI.
I’ve been thinking about the top things we could do to improve the Fedora experience lately and this one seems like a big one that shouldn’t be too difficult to address.
I have a systemd unit which watches for *failed*.log in the /var/cache/akmods/nvidia/directory. If it sees one being created, I get a notification.
Saying that, I look at that directory myself when I’m expecting akmods to execute, so I rarely pay any attention to the notification, as I’ve notified myself.
I also believe that there’s an inhibit / blocking flag created as part of the post installation hook. Whether it works or not… /shrug
I could also mention that I’ve never actually seen the akmods process failed to build the driver but I have seen it fail due to an RPM lock, as in:
2025/10/28 17:28:43 akmods: Installing newly built rpms
2025/10/28 17:28:43 akmods: DNF detected
Updating and loading repositories:
Repositories loaded.
Package Arch Version Repository Size
Installing:
kmod-nvidia-6.17.4-300.fc43.x86_64 x86_64 3:580.95.05-1.fc43 @commandline 35.3 MiB
Transaction Summary:
Installing: 1 package
Total size of inbound packages is 8 MiB. Need to download 0 B.
After this operation, 35 MiB extra will be used (install 35 MiB, remove 0 B).
Running transaction
Transaction failed: Failed to obtain rpm transaction lock. Another transaction is in progress.
Warning: skipped OpenPGP checks for 1 package from repository: @commandline
2025/10/28 17:28:49 akmods: Could not install newly built RPMs. You can find them and the logfile in:
2025/10/28 17:28:49 akmods: /var/cache/akmods/nvidia/580.95.05-1-for-6.17.4-300.fc43.x86_64.failed.log
There is a work in progress in order to get rid of this using libdnf5-plugin-actions,
but there is some points to fix. See: this akmods bz
This will apply also to packagekit when it will be updated to use dnf5, planned IIRC
for F44. Gnome Software and Discover will thus also benefit of that.
akmod driver rebuilds triggered by a kernel update seem to be protected by systemd-inhibit
(see akmods@.service ) and a quick test in a F43 VM confirmed that this seems to work for F43 workstation.
$ systemd-inhibit --list
WHO UID USER PID COMM WHAT WHY MODE
ModemManager 0 root 1001 ModemManager sleep ModemManager needs to reset devices delay
NetworkManager 0 root 1088 NetworkManager sleep NetworkManager needs to turn off networks delay
UPower 0 root 865 upowerd sleep Pause device polling delay
akmods 0 root 372789 systemd-inhibit shutdown:sleep:idle Akmods Transaction running block
[deleted]
attempts to reboot the system while akmodsbuild was still active
# reboot
Operation inhibited by "akmods" (PID 68928 "systemd-inhibit", user root), reason is "Akmods Transaction running".
User ignite is logged in on tty2.
Please retry operation after closing inhibitors and logging out other users.
'systemd-inhibit' can be used to list active inhibitors.
Alternatively, ignore inhibitors and users with 'systemctl reboot -i'.
$ reboot
Operation inhibited by "akmods" (PID 68928 "systemd-inhibit", user root), reason is "Akmods Transaction running".
Please retry operation after closing inhibitors and logging out other users.
'systemd-inhibit' can be used to list active inhibitors.
Alternatively, ignore inhibitors and users with 'systemctl reboot -i'.
journal entry of attempt to reboot via gnome control applet
$ journalctl -b -g inhibit |cat
Feb 22 02:00:27 fedora gnome-session-service[1810]: Shutdown failed: GDBus.Error:org.freedesktop.login1.BlockedByInhibitorLock: Operation denied due to active block inhibitor
Could something similar be implemented for the posttrans scriptles of akmod-nvidia to protect driver installation and upgrades, too?
Maybe an easy workaround could be changing the akmod-<driver>.spec template in kmodtool from (line 180 )
I have a hunch that in most cases, the problem is that the akmods process actually failed, rather than the user interrupting it in flight because they didn’t wait long enough. 5 minutes is pretty conservative - on modern-ish mid-range hardware it’s more like 1 minute in practice.
This is not intended to detract from your fundamental point - of course it’s indeed not a great experience for the user if the process just fails with no clear indication of status.
I have had mixed results with this. I do not use offline upgrades, but sometimes the rebuild with the boot fails to run if the initial build after an update has been interrupted at the point where the system thinks it has completed, even if not 100% complete. (maybe between the build and installing of the new kmod package?)
When that happens it has been necessary to manually run the akmods command so the driver is properly built and installed, then boot again to load the driver.
Yes, this could happen if a premature reboot is done just during the (mandatory)
call of depmod done by the postinstall transaction of the kmod-KMOD-KVER RPM.
there is no failed attempt, because a rebuild is blocked. My tests with a reboot after a dnf remove kmod-nvidia-$(uname -r ) were always successful. And plymouth would notify the user of the ongoing akmodsbuild.
For me, failure to provide an nvidia driver for the kernel has happened twice since September 2025, according to the logs.
Unfortunately, the second time was yesterday with the 6.18.12 update. I rebooted anyway, despite knowing it had failed, and the entire thing was rebuilt and installed cleanly upon start-up, but having the entire thing wait and retry just because some other transaction was running would be better.
A build failure is one thing but a clean build and a failure to apply the driver due to an RPM lock seems to be easily dealt with. I run my updates from the command line and I get zero error messages about anything not working unless I actively monitor for a failure log file or check myself.
To be absolutely honest, I’d never really considered the fact that I run dnf update, stuff happens and eventually I get the prompt back, and unless I go looking in a specific directory four layers deep for the existence of a specifically named file, or I take the time to read a log file in /var/log/<package>/I have no indication that there was a failure of any sort.
That smells like UI balls-up to me - if everything is quiet I assume it’s successful as that’s the Linux way. No news is good news, just like a zero RC. The fact that silently, the package manager didn’t do something because it conflicted with itself doing something else (I know not what!) and it doesn’t notify me…
Good job we don’t see many “Black screen after reboot” issues from users eh…
