After an update a few days ago, booting to KDE failed after plymouth.
I’ve lost count of how many times this has happened - usually a kernel change that is incompatible with the nvidia fusion drivers (I wonder if any quality control is done on Fedora before pushing kernel updates - I mostly use FreeBSD and I’ve had almost no problems on that platform).
This is with Fedora 37 on a fairly old HP Intel Xeon workstation, GT 370 video card, 390 nvidia drivers.
If I switch to a terminal, I see that the nouveau kernel modules are loaded and there are no sign of the nvidia drivers (presumably cos dkms failed).
That GPU and those drivers are old and not supported well.
The fact you are mentioning dkms tells me you did not install the drivers from rpmfusion. Had you installed from the rpmfusion repo your drivers would be automatically updated for a newer kernel with akmods and the user would not need to do anything manually.
Since the nvidia drivers are not distributed nor supported directly by fedora this statement is way off base. Fedora cannot do quality control for software it does not distribute. When users choose to use packages and repos that are not within the fedora ecosystem then it is up to them to manage the software they added to the system. It cannot be claimed to be fedora’s responsibility unless the user chooses to ONLY use software that fedora distributes through their own repos.
Most members here will gladly support users with problems but rants and accusing statements about quality control like that are out of line and should not be seen.
If you are having problems with your system please post some details about the system, hardware, versions, and exactly what the problem is. Help is available for most situations.
Now you are making things up. If I said that I installed via rpmfusion it is because I installed via rpmfusion.
Well yes, it should work automatically. In reality it breaks frequently as kernels get pushed with incompatible interface changes. This is a recurring issue - there are many threads on this forum to start with.
In this case it seems that nv-gpu-numa.c no longer builds due to a function signature change to a member of nv_dir_context_t (the return type having changed from int to bool).
Are you saying that Fedora can’t test compatibility with the market leading graphics card vendor? It takes two to tango and coordination with nvidia could be much better,
I’m afraid this is a limitation of the current development model, when free and open-source code takes priority and performs the leading role, and non-free code delays the development and becomes a problem for those who want to use it.
I doubt the current practice can be changed, so you should probably use methods that minimize negative effects, but this likely requires to sacrifice some security for the sake of stability.
A simple workaround is to avoid booting kernels which has issues building the module and just stick to the latest working kernel until a new working kernel arrives.
Otherwise, try to avoid buying and using hardware that depends on non-free code.
There are several GT 730s with significant differences. Only 1 specific model requires the 390xx drivers (I think the GF108); the rest are supported by 470xx drivers.
Check the PCI ID with lspci -nn and compare the second set of 4 hex digits with the previously linked Nvidia list.
When you update the kernel, DKMS will automatically recompile the driver for the new kernel. If you update and reboot right away, then the recompile gets cut off. Generally I recommend waiting about 5 minutes after updating before you reboot. I know this because I dealt with it a lot.
I learned this hard way couple of times I wonder if it’s possible to do it visible, e.g., via notification. And ask additional questions in case user wants to reboot/shutdown before DKMS akmod has finished its job.
The Quadro FX 370 was released in 2007
If you instead meant the Geforce GT 730 it was released in 2014
Nothing in your post says it was installed from rpmfusion, and you mentioned dkms implying that the modules came from another source. It has always been my experience that the drivers from rpmfusion are built by akmods and that has automatically worked as long as the user allows time for the drivers to be rebuilt before the reboot. Dkms is never even installed on recent versions of fedora unless one chooses to install a package from a 3rd party repo (other than rpmfusion) which requires dkms for the module build.
With that said, The nvidia.com site drivers page says the GT 730 is properly supported by the 470 driver. I would suggest that you remove the 390 driver you claim to be using and instead install the 470xx driver from rpmfusion. That may give a much better support for that GPU.
akmods should build required kmods on boot (see /usr/share/doc/akmods/README). So rebooting early should not cause any problems—but I don’t know since I do offline upgrades with dnf, which avoids this situation entirely.
If you or @arturasb are feeling adventurous, I would suggest testing this again . Next kernel update, just reboot immediately.
If you have a graphical boot screen (e.g. Fedora logo), you can press Esc to see the boot messages. You should see something about akmods.service indicating the kmod is being built. It may take a couple of minutes (pretty consistently ~1m25s on my 5-year-old i5-8400).
There are reports on the fedora users list that akmod fails to rebuild sometimes on first boot if you do not wait. Personally I have not see this, but more then one person reported the breakage.
I know, that akmod builds on boot, but maybe couple of times there was something wrong with build and manual intervention was needed. I just think that visual clues about akmod in action would improve UX.
Akmods startup script will rebuild akmod packages during system boot,
while its background daemon will build them for kernels right after they were installed.
kmods are the tools/programs needed for the “kernel management modules”
while akmods are startup scripts to trigger this tools for apps listed above to update.
This could cause that the system has to be restartet twice if akmod/kmod packages are updated at the same time as a kernel ? Could this be causing this hick ups @arturasb mentioned ?
Answer from @vgaetera links to the build guidelines and says:
# Ensure that any installed kmods are built for the currently-running
# kernel at boot
# https://bugzilla.redhat.com/show_bug.cgi?id=1518258
enable akmods.service
kmod package contains programs related to kernel module management, e.g. lsmod and modprobe.
But in the context of “building a kmod” or “nvidia kmod”, it’s just short for “kernel module”.
akmods package contains the programs to automatically build kernel modules as rpm packages, and various systemd services to build on startup/shutdown.
No. With a live update (e.g. dnf upgrade), after the reboot, the new kernel/akmods/whatever package are already being used. The new kmod will be built, causing the boot to take longer, but no additional reboot is needed.
With offline update, on the first reboot, the new kernel/akmods/whatever package is installed. On the second reboot (normal for an offline update), it behaves like the live update’s first reboot.
I wonder if it’s possible to do it visible, e.g., via notification. And ask additional questions in case user wants to reboot/shutdown before 
. Next kernel update, just reboot immediately.
on