Hello. I’m a relatively new Fedora kde user. I also have an old nvidia card which needs an older dkms driver which is no longer supported and lives in the rpmfusion repo.
When there is a new kernel, after a manual
dnf upgrade the nvidia driver has to be rebuilt(after dnf has quit) and if i don’t wait long enough the install will be broken.
If i do the update through kde’s
discover it’ll install the update after the next reboot. Here’s the kicker though: the nvidia drivers will be rebuilt after the upgrade process is done during the next boot. So if you have no idea what’s going on, like i did just a minute ago, you’ll be staring at a blinking cursor for about 3-5 minutes while it’s compiling in the background with no hints at all thinking your install is broken after an update. But if you let it finish everything’s good.
I just wanted to ask, can the rebuilding be part of the “system is upgrading” process before the main boot? Or maybe there could be a systemd message while booting. Or is this just accepted as normal behavior because old dkms drivers are unsupported?
Thank you for reading.
When upgrading the kernel the
dkms will be run through the script
/usr/lib/kernel/install.d/40-dkms.install. This script is installed as part of the
dkms package from the fedora repository.
I see. So is it possible to get this script to run as part of dnf’s upgrade and make dnf wait until it’s done?. Because dnf finishes for me and then it spawns 4 cc1 threads without informing the user that something important is still going on.
As far as i recall Arch’s pacman for example won’t finish until the scripts are run. And then the graphical offline upgrader would also take this into account, run a longer time but the problem would be solved.
Are you sure you are talking about dkms and not akmods?
AFAIK there are 0 dkms-based packages in RPM Fusion (or Fedora).
Sorry, yes, i am not sure what the difference between those 2 are.
I just meant whatever process that happens when you upgrade the kernel with
xorg-x11-drv-nvidia-390xx-390.157-2.fc38.x86_64 from rpmfusion-nonfree already installed
They serve the same purpose, but akmods builds the kernel module as an rpm package which can then be managed easily (installed/uninstalled as a whole unit), instead of loose files installed by dkms.
Anyway, it seems like the main problem is the lack of visual feedback, not when it builds.
I don’t use plymouth (graphical boot screen) or rhgb/quiet kernel cmdline options, so I see boot messages by default. There is definitely a message from akmods service when it’s building during boot (although it’s not very descriptive). When you say there is only a blinking cursor, is that after pressing Esc to view boot messages?
The first time i encountered this i had the usual Fedora setup with
quiet in the linux kernel parameters so it used plymouth. It happened like this: Fedora showed it was updating, then it rebooted, plymouth showed the usual fedora splash screen, it briefly blinked “Booting Fedora kde (kernel version)” and then cleared the screen only with a continuously blinking cursor remaining. I could not hit escape, any arrow keys and i could not switch to any of the TTYs.
I also tried Fedora’s rescue mode through grub but it had the same results.
Believing that something went wrong with the update, that my system was in some kind of loop(my only indication that something was going on are my loud laptop fans) i booted with a live usb stick and managed to remove the
quiet kernel parameter and also explicitly activate one of the TTYs through systemd.
This time i saw the systemd msgs. Everything seemed well but at the end it still seemed stuck. I do not remember if the systemd msg about akmod was the last one but i also think it doesn’t matter much because it’s probably not descriptive enough. The user has no idea what akmod, what it’s doing or that they just need to wait some time and then everything is going to be fine in just a few minutes.
What made finally sense to me was when i was able to go to the TTY and in the process see with
top the familiar cc1 compilation threads.
So my proposal, if the process can’t be contained inside the graphical upgrade screen, would be at least make the akmod message stand out a bit more. But it also does not show with
quiet at all so i’m not sure if that would even help for the average user.
It seems the issue is lack of communication.
The build of the akmod package for nvidia seems to not start until the kernel finishes the update and the kernel scripts are the last shown by dnf during the upgrade. This seems to indicate to the user that it is safe to reboot when it actually may not be ready yet.
For me I have simply learned to never reboot immediately after finishing a dnf upgrade but to wait at least 5 or more minutes after dnf completes the upgrade before I reboot.
This provides adequate time for most systems to allow time for the drivers to be built and properly installed.
It would be nice if the
akmods package were to provide some feedback when launched from a dnf upgrade so the user would know when it actually completes the build & install phase, but without that one must simply pace themselves and not immediately reboot the system. Even running
akmods manually does not receive any feedback on progress.
I agree but remember that there are 2 sides to this story. This proposal is good but would only work for people running
dnf upgrade manually through the command line and it would only work for people who pay attention to the output.
i think most people run the updates graphically though something like Gnome Software or Discover. These updates are then scheduled to be applied after the reboot and then will result in the behavior which i described. If i understand correctly this wouldn’t result in more feedback to the user while booting up when the usual systemd messages are shown(if you have them enabled at all, which the usual Fedora install does not)
I agree, which is one reason I abhor the gui upgrade which often does the automatic reboot and does not wait for the driver build process to complete.
It can (sometimes successful, sometimes not) complete the rebuild during the reboot – often requiring another reboot to load those drivers – but that is what the OP was asking about.
I use dnf and never have an issue. It seems users relying on the gui often have issues.
I admittedly have not performed this upgrade many times but so far it has not failed me. The original issue is that there is no communication that it’s happening and perhaps the order in which it is done. The user simply does not know that something else is going on in the background or during boot after the upgrade is seemingly done and the “update is being applied” screen goes away.
AFAIK the situation has always been like this for anyone who uses GNOME Software or Discover to do offline upgrades with akmod-nvidia.
I think there is probably no interest to improve it from the usual desktop stakeholders, since the main benefit is for users with Nvidia proprietary drivers. akmods itself is packaged in Fedora, but no Fedora package uses it; all the akmods-based packages are from RPM Fusion.
I see. Then i hope someday someone interested notices this. With all the advantages, Fedora and desktop linux still have many areas that can be improved. I get that nvidia are the odd one out being proprietary but it’s also true that their market share is significant.
From NVIDIA’s viewpoint, as long as desktop linux market share stays high they don’t need to take resources away from datacenter AI use cases. AI could produce completely different ways to get images onto desktop displays.