@Neal you can use the multi-version in zypper to keep the kernel, no need for locks at all on that item. See /etc/zypp/zypp.conf and multiversion.kernels = part
multiversion.kernels = latest,latest-1,running,<your-kernel-version-to-keep>
eg
multiversion.kernels = latest,latest-1,running,6.4.9-1.2
Not sure if you could find old nvidia rpms… I use the run file here, but I’m on newer devices…
Ok, so keeping the old kernel like you show …does this also keep the current drivers compiled with that kernel? I want to be able to use the current kernel and nvidia drivers I’m using as a fail safe. It sucks …I know. Next laptop I buy I want to get a intel gpu or something that doesn’t require this headache and anxiety on updating.
@Neal but it’s the same nvidia rpm, just built against the newer kernel…
If you have dkms installed and boot from an older kernel, my understanding is that is should build against that. BUT I don’t use nvidia that way or the rpms, maybe another Forum user can advise.
I really don’t know how it works with proprietary drivers, if it’s any different. Initrds normally are built with kernel device drivers included. All I know about NVidia’s is they cause a lot of people a lot of grief, so they come here often to get helped past it. All my GPUs, AMD, Intel, NVidia and other, are 100% using FOSS for essential graphics. I do lock my initrds with immutable bits. Once I know one works, it’s prevented from being rebuilt without my involvement.
There is a always a lot of FUD about proprietary Nvidia drivers. Mainly because the FUD spreaders don‘t even have a Nvidia card or have absolutely no clue about it and cause the problems on their own by not following clear instructions how to install drivers.
I have 3 different Nvidia cards with G04, G05, G06 proprietary drivers in use and i can‘t remember when i had the last problems. In most cases there is only for 1 or 2 days a small hickup when there are major kernel version jumps ( eg. 5->6) as there may be a patch needed.
The biggest FUD spread is that Nvidia/openSUSE need to recompile everytime the kernel/driver when a new version is released.
For this since decades the kms/dkms function exists. That means if there is a kernel or driver update, the necessary kernel module is automatically built on the user machine without need for any interaction.
If you use the „hard way“ like Malcom, you need to execute the Nvidia run file when a new version is released. This will trigger the kernel module build process.
That is the reason to have multiversion kernel enabled, because a working kernel module don‘t get removed as long as you don‘t remove the kernel itself.
So that means the TO should first dup to an actual kernel and driver version and see if the problem is fixed. If he followed the instructions and have multiversion properly set up, he can boot again the old kernel version if the dup makes anything worse than before.
Es example on my main machine i have set it to keep 6 kernel versions. This are enough versions to „sit out“ any problems without the need to lock any kernel versions.
@Neal It depends on what your wanting to do with the laptop. So question on the hardware, it’s not a hybrid setup with the intel/amd igpu disabled?
My experience is different. Even kernel changes within the same minor releases like 6.0.1 to 6.1.1 broke things much less major releases. And, for me often it was not days it was weeks and a few times now in the last four years using TW it’s been months. All of this is why I locked the kernel and drivers. I’d like to know more about the kms/dkms do you have any documentation on how you’ve deployed it. The only time I’ve heard about dkms was when people didn’t want to use zypper…are you saying you’re not using zypper anymore?
Thanks for your input.
It’s a old as dirt Asus G75V…not anything even remotely fancy.
localhost:~> lspci |grep NV
01:00.0 VGA compatible controller: NVIDIA Corporation GF114M [GeForce GTX 670M] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF114 HDMI Audio Controller (rev a1)
Perhaps you should consider Leap which does not change as much as TW.
@Neal it’s Dynamic Kernel Module Support use zypper if dkms to see the info… zypper is still used…
In four years I’ve only had a few issues mostly due to the graphics card and locking the kernel and drivers solved it just fine; then a issue with sudo permissions about a year ago that was fixed quickly. I think not using TW just because of this is a little overkill at this point.
Thanks Malcolmlewis.
I found that the nvidia drivers seemed to be patched for the new kernel so I released the locks. And, I choose option 1 for the dup error instead of using zypper. Anyhow…after a new dup just now I’m typing this on the laptop. I guess glibc and the new drivers/kernel was the most likely culprit.
Thanks for all those that chimed in as it was greatly appreciated.