KDE Plasma 5.24.7 GUI won't completely load after boot.

[TinyTim]

Not for sure but think after a kernel upgrade from 6.2.0-34 generic to 6.2.0-35 the KDE Plasma GUI will not completely load up. The KDE mouse cursor shows, but the tool bar with icons, system tray, task mgr does not show up, there is no left or right mouse click action, the desktop does not function. Tried to remove KDE config file and let it reset it, did not succeed. It works sometimes on the first reboot, sometimes the second. Loaded the old kernel from GRUB and it seems to work that way. Turned off compositor and start up programs to ease the load and that is not associated with the issue. I tried ALT F2 to delete config file or reinstall KDE fresh, ALT F2 will not function, the only thing that seems to work is Ctl + Alt + T and Ctl + Alt + Del. Use Ctl/Alt/T to turn KDE off to delete config, well naturally I'm left with a blank screen. Tried to use TTL at boot w no success. Thinking about editing the GRUB and having it boot up on old kernel, wondering if it could be Nvidia driver issue? Graphics X11

[Schwarzer Kater]

Probably some problem with Nvidia and the latest kernel again… - but you could also try the following:

• press e.g. [Ctrl] [Alt] [F4] at the log-in screen to get to a tty
• log in with your user account
• enter cd ; sudo rm -r .cache/* (exactly as written here)
• enter your password
• enter exit
• press [Ctrl] [Alt] [F1] to get back to the graphical log-in
• log in with your user and test if the problem still occurs

This deletes all user caches of the corresponding user, including the Plasma caches.

[TinyTim]

It booted into the new kernel today without a hitch. Save for the HP splash screen lingering a few seconds longer than normal. I will study this further before applying any fixes. It seems odd that Nvidia and new Kernels are always conflicting. People tell me that it is Nvidia causing the problem... but, it is the new Kernel who seems to have changed something to make it not work correctly. How does one determine in all that code, who, what, how this occurs? I have two machines, Ubuntu Studio 22.04 (low latency) and Kubuntu 22.04, both machines have experienced this problem with kernel updates. The kernel changed not Nvidia.

[claydoh]

The kernel changed not Nvidia.

That doesn't really matter. The kernel requires that the nvidia 'shim' that connects the driver to the kernel be rebuilt for each new kernel, unfortunately.
Nvidia drivers have *always* had this sort of issue with even small security fixes in the same major kernel version (such as is the case in Ubuntu LTS ones)
I am talking about decades of this sort of thing, or close to it.
Even small changes to fix a security hole can have an effect on some people's specific hardware, even if the vast majority don't see anything.
Nvidia are worse since the kernel and distro devs have zero access to the driver code, so they can't really know 100%

But I moved (ran) away from team green many years ago, for this exact reason.
of course, not everyone can do so.

Maybe any current Nvidia users can suggest basic precautions or settings used to prevent or alleviate these sorts of messes?

[TinyTim]

That doesn't really matter. The kernel requires that the nvidia 'shim' that connects the driver to the kernel be rebuilt for each new kernel, unfortunately.
Nvidia drivers have *always* had this sort of issue with even small security fixes in the same major kernel version (such as is the case in Ubuntu LTS ones)
I am talking about decades of this sort of thing, or close to it.
Even small changes to fix a security hole can have an effect on some people's specific hardware, even if the vast majority don't see anything.
Nvidia are worse since the kernel and distro devs have zero access to the driver code, so they can't really know 100%

But I moved (ran) away from team green many years ago, for this exact reason.
of course, not everyone can do so.

Maybe any current Nvidia users can suggest basic precautions or settings used to prevent or alleviate these sorts of messes?

A kernel upgrade for Ubuntu Studio 22.04 happened one time and it put two new kernels on there, the old kernel still worked, if it would of completed the upgrade, it would have made the old kernel no good. What I did is blocked that upgrade and had to go in and edit the GRUB and tell it to use the last kernel it booted on each time. Eventually I did allow it to upgrade (to learn) and I was left with the option of only using the new kernel with only (ONE) 1 low resolution driver. I reinstalled the system to fix it. (it even made useless the recovery kernel)

A kernel upgrade for Kubuntu 22.04 happened, and I have use of the Nvidia driver but some glitches. The Nvidia propitiatory driver is working on both machines. (I can still boot up on the old kernel if needed)

With the information you have provided. The solution to the problem as far as I know... Do not allow any kernel upgrade using Nvidia GPU, until a year or so later when and if you know for a fact Nvidia has resolved this "shim" issue. The other option is do not use Nvidia GPU. Which leaves another problem and my final question... How would you know when and if Nvidia has put out a proper working driver? (I suspect you would not, until you installed and tried it) One last question, I also can not find... how do you stop Discovery, Konsole, from upgrading the kernel? I know how with Muon Pkg Mgr.

I think this the way to lock the current kernel with Konsole?

uname -r 4.10.0-27-generic
sudo apt-mark hold 4.10.0-27-generic

I am very grateful for this knowledge on "shim" that one word was my missing link.

[Schwarzer Kater]

[…]
The other option is do not use Nvidia GPU. […]
How would you know when and if Nvidia has put out a proper working driver? (I suspect you would not, until you installed and tried it) […]

Exactly.

Harshly said: IMHO if you don't depend on using CUDA, do not use Nvidia with Linux to have as little trouble as possible with GPUs.
But especially with some laptops unfortunately you don't have a choice…

And you would only know when you try it with a new kernel some times, as other people with other Nvidia graphics card models may have other experiences with their hardware (and the kernel release of their distribution).

It could become much better when Nvidia's own drivers will be fully open-sourced - but this could take another 4 or 8 or 12 years (or may never really happen)…

[TinyTim]

Exactly.

Harshly said: IMHO if you don't depend on using CUDA, do not to use Nvidia with Linux to have as little trouble as possible with GPUs.
But especially with some laptops unfortunately you don't have a choice…

And you would only know when you try it with a new kernel some times, as other people with other Nvidia graphics card models may have other experiences with their hardware (and the kernel release of their distribution).

It could become much better when Nvidia's own drivers will be fully open-sourced - but this could take another 4 or 8 or 12 years (or may never really happen)…

I use two desktops, and from what I have read, CUDA is only used if a program calls for it. I was looking to disable CUDA when I read that, because I don't think I need it. I do some slightly heavy desktop graphics for a publisher, (no games). *Read that CUDA can not be disabled -do you know if and how it can be? I'm thinking my solution is to lock in the old kernel, keep it for as long as there is no problems. (and watch for future solutions) SHIM
I think my question is answered, and I will mark it as solved. Much thanks Schwarzer Kater & claydoh

[Schwarzer Kater]

No need to disable CUDA - it won't make any difference as it most certainly is not the culprit (but it is an additional feature of Nvidia graphics cards/drivers that e.g. AMD lacks to provide in this form for Linux).
Perhaps my English was not clear enough, sorry…

[TinyTim]

That doesn't really matter. The kernel requires that the nvidia 'shim' that connects the driver to the kernel be rebuilt for each new kernel, unfortunately.
Nvidia drivers have *always* had this sort of issue with even small security fixes in the same major kernel version (such as is the case in Ubuntu LTS ones)
I am talking about decades of this sort of thing, or close to it.
Even small changes to fix a security hole can have an effect on some people's specific hardware, even if the vast majority don't see anything.
Nvidia are worse since the kernel and distro devs have zero access to the driver code, so they can't really know 100%

But I moved (ran) away from team green many years ago, for this exact reason.
of course, not everyone can do so.

Maybe any current Nvidia users can suggest basic precautions or settings used to prevent or alleviate these sorts of messes?

It took some time, and I have borked the Kubuntu system twice now, and have even installed Manjaro because they seemed more friendly about working with Nvidia. I stumbled into a guy from the Ubuntu Studio forum, who told me ' sudo dkms autoinstall ' would keep the kernel in line with the installed proprietary driver. I used it on Ubuntu and it seems (for now) to have worked. I wish I would have known this before bailing on Kubuntu. From what I can tell each time a new kernel upgrade comes up, you have to run ' sudo dkms autoinstall ' again.

[claydoh]

From what I can tell each time a new kernel upgrade comes up, you have to run ' sudo dkms autoinstall ' again.

That is exactly what is supposed to be happening automatically to begin with in *buntu (and something similar on most distros, I think). What causes this to break for some, I dunno.
But the drivers still seem to hit every distro with random breakages regularly, even the Archies (despite what they may try telling you, lol).

I would have figured more folks in here would have chimed in, I can't image *everyone* here bailed and switched GPUs or entire laptops. Maybe this doesn't happen as often as it used to, in the olden times ( a few years back)?

[TinyTim]

That is exactly what is supposed to be happening automatically to begin with in *buntu (and something similar on most distros, I think). What causes this to break for some, I dunno.
But the drivers still seem to hit every distro with random breakages regularly, even the Archies (despite what they may try telling you, lol).

I would have figured more folks in here would have chimed in, I can't image *everyone* here bailed and switched GPUs or entire laptops. Maybe this doesn't happen as often as it used to, in the olden times ( a few years back)?

Appreciate that info. (On Ubuntu machine 1) Even though the dkms autoinstall did work on the Ubuntu machine, now I have a (current) mismatch between built and installed module, I would assume from holding the upgrades back. I have tried to --force it but dkms says it can not find it in dkms tree. Am I thinking correctly, booting into previous kernel, uninstall that mismatch and reinstall it incrementally, or would I be able to force it from there? Each answered question, a hundred more questions arise. (On former Kubuntu machine 2, now Manjaro) I think it may be best if I remove the 2g nivida card and just use the onboard 256mb AMD and reinstall Kubuntu, because zsh konsole is unbearable to me.

[Schwarzer Kater]

[…]I think it may be best if I remove the 2g nivida card and just use the onboard 256mb AMD and reinstall Kubuntu, because zsh konsole is unbearable to me.

Why not. I sold my final Nvidia graphics card some time ago for quite a good price and used the Intel HD 630 iGPU instead as long as I had the computer, which was sufficient for my use cases on the machine.
Of course you have to be sure that you don't need the extra processing power of the additional Nvidia card for something (and if you do you could always change it for an AMD one)…