Missing GUI feedback during background akmod builds on reboot (Fedora 43)

Project Discussion
,
1

Problem Description: After a standard system update (including a kernel jump from .10 to .12), the system appeared to hang for several minutes during a GUI-initiated reboot. There was no visual feedback, progress bar, or “Operations in progress” message.

- - - Technical Discovery - - -

DNF History: Transaction #15 shows kernel-6.18.12-200.fc43 installation started at 14:51.

Akmod Logs: The build log shows completion at 19:54.

/var/cache/akmods/nvidia/580.119.02-1-for-6.18.12-200.fc43.x86_64.log

Inhibitor Absence: Running systemd-inhibit --list during the process revealed that akmods does not register a shutdown/reboot inhibitor.

Timeline (Feb 20):

14:53: Kernel update finished.

14:54: akmod triggered a background build of the NVIDIA driver (Transaction #16).

~20:00: User attempted GUI reboot; system became unresponsive because the background kmod installation was still finalizing or locking the RPM database.

Discussion point: This is a significant UX flaw. On a mid-range system (Intel i3-10100 / GTX 1650), building the NVIDIA 580.119 driver takes considerable time. Without a Plymouth splash message or a GNOME/KDE inhibitor, users are likely to force-reboot their machines, leading to corrupted initramfs or broken driver states.

- - - System Info - - -

OS: Fedora Linux 43 (Workstation Edition)

Kernel: 6.18.12-200.fc43.x86_64

CPU: Intel Core i3-10100 (8) @ 4.30 GHz

GPU: NVIDIA GeForce GTX 1650

NVIDIA Driver: 580.119.02 (via RPM Fusion)

For more:

Снимок экрана от 2026-02-21 07-28-47
Снимок экрана от 2026-02-21 07-28-47689×518 50.5 KB

2

I don’t disagree with your main point that it would be good to have a message telling the user that the kmod is being rebuilt during boot.

However, 5 hours to build the driver is very abnormal.

As a reference point, when I look at the /var/cache/akmods ... .log file for my last kmod build, it took 46 seconds. That’s on a Ryzen 5700X, which is probably slightly faster than your CPU, but not massively so.

On your hardware it should take a few minutes at most, so it would be interesting to see what’s going on there.

When you look at the line-by-line timestamps in that log file, do you see any particularly big time gaps between lines?

1 Like
3

Hello. Thanks for reply.

I ran a filter on the log file, and the results are staggering. In just one second (19:54:09), the build process generated 14 903 lines of warnings.

It’s a massive flood of -Wmissing-prototypes for the NVIDIA driver’s libspdm components. It seems the compilation is stuck in an I/O wait because of this excessive logging. This likely explains both the 5-hour build time and why the system was unresponsive to the shutdown command - it was too busy writing millions of warnings to the cache.

4

:astonished_face:

Yes, that sounds not great at all!

You might want to post a new topic with an example of the warnings, and see if someone can advise how to fix that.

1 Like
5

Thanks. I will take a note about this. Have a good day! :ok_hand:

2 Likes
6

My akmods build after the dnf update ran, but failed (silently to me) with this:

Total size of inbound packages is 8 MiB. Need to download 0 B.
After this operation, 36 MiB extra will be used (install 36 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
2026/02/20 11:40:51 akmods: Could not install newly built RPMs. You can find them and the logfile in
2026/02/20 11:40:51 akmods: /var/cache/akmods/nvidia/580.119.02-1-for-6.18.12-200.fc43.x86_64.failed.log

Rebooting 10 minutes later had it rebuild again, successfully, but it did take about 40 seconds to do so with a black screen whilst it was eexecuting. Once it completed, no further issues though.

@plazmus1 can you provide some examples of the libspdm issues you see - I have a few entries like

2026/02/20 11:40:46 akmodsbuild: nvidia/libspdm_ec.c:60:6: warning: no previous prototype for ‘libspdm_ec_check_key’ [-Wmissing-prototypes]

… but only a few and certainly not hundreds of thousands going on for hours. 40 seconds from start to finish.

1 Like
7

Hi! In my case, it’s not just a few warnings. I’m seeing a massive flood specifically in libspdm_x509.c. For example, at 19:54:09, my log shows 14,903 lines of -Wmissing-prototypes warnings in a single second. It seems like my environment triggers a much more aggressive feedback loop from the compiler than yours.

I’ve opened a new topic in ‘Proposed Common Issues’ to document this, as 5 hours of build time vs your 40 seconds definitely points to a logging/IO bottleneck caused by these warnings.