How to lock the kernel?

I’ve not been able to update (dup) for awhile due to bad timing I guess on my part as every time I run a dup my nvidia drivers don’t work due to a new kernel being installed. Generally I just wait a few weeks and try again when the issues has been addressed for the new kernel. Anyways I’m months behind due to this and was wanting to try and just pin (lock) the kernel thinking this might work. I’m using yast and have selected “kernel-default , kernel-default-devel and kernel-devel” and choose to protect and not modify…then accept. The lock icon is there and a console output from dup shows the new kernel not there anymore …but I’m seeing that it still wants to install the following which seems to be new .ko modules for the updated kernel I’m trying to reject. Locking this package in yast is not possible.

The following package requires a system reboot:

I’m still running on this kernel

uname -a
Linux localhost.localdomain 5.14.14-1-default #1 SMP Thu Oct 21 05:05:03 UTC 2021 (2b5383f) x86_64 x86_64 x86_64 GNU/Linux

It wants to install 5.17-1-1.2, this didn’t work so I had to roll back to get nvidia working. I’m assuming that base package above will cause issues with a older kernel. Is it possible to lock the running kernel and it’s drivers and then try to just update them latter?

[FONT=monospace]sudo zypper ll

| Name | Type | Repository | Comment

1 | kernel-default | package | (any) |
2 | kernel-default-devel | package | (any) |
3 | kernel-devel | package | (any) |

[/FONT]rpm -qa |grep nvidia

Sometimes the command line works better. I never try to manage locks with YaST except for tabooing during installation. Remove the three locks you have, then do:

sudo zypper al kernel-de*

AFAIK, kernel-default-base lacks things needed for a standard installation like you have.

Another option is to install

Thanks, I’ll try using zypper via the command line; I typically use it that way but kinda like yast.

Your using the 390.144 driver , the repository version is 390.147 plus it’s not built for the 5.17.x kernel by the looks…

It’s been fixed a few hours ago, so would just hang out with what you have got until it appears in the above repo and then do a zypper dup.

You can achieve the same thing in the Yast GUI by right clicking on the packages you want to lock and setting them to ‘Protected - do not modify’ and then clicking accept.

Yes, I tried this and it did not work as stated in my opening post.

Did you try that with the kernel?

I do not think that “works” because you can have different kernel versions installed and they are all different packages. By locking the package(s) that deliver a kernel, you only stop that version from being deleted or reinstalled. But you did not lock the packeges of new kernels and thus they are still candidates for installation.

Yes, sorry try locking the nvidia kernel module i.e. nvidia-gfxG06-kmp-default . If you do this zypper probably won’t query you about updating the kernel and you can proceed as usual.
Locking the kernel or any package this way from future updates seems to work fine on my system when I use Yast. It’s easily done through the command line but sometimes it’s easier to get an overview of available packages through the Yast GUI.

Rather than locking, just configure zypper multiversion (/etc/zypp/zyyp.conf) to keep the kernel version your wanting (or more if set the - value), then it will just add that as a boot option to grub. Once your happy that the newer kernel is working can boot from that and adjust as required.

Locking the nvidia module isn’t what I’m after, the dup wants to install a new kernel as it should and has nothing to do with nvidia. Kernels have to be patched for nvidia to work. The way around this is to lock the kernel that is patched and working so any nvidia modules compiled against it work.

Thanks for the reply, I think for me it’s easier to just zypper -al or -rl if that works out. And, now that I have the link provided above I’ll check to see where we are with patches before running dup. Curious if a script can be written to check the proposed update for the new kernel and if it’s patched or not? If dup wants to install a new kernel can that link above be checked to see if there’s a patch for it or not?

# zypper al kernel-de*
# zypper ll | grep nel-de
30 | kernel-de*                  | package | (any)      |

The above status will prevent any kernel-de* from being added or removed automatically.

# zypper in kernel-default

will report the lock exists and offer options to either: 1-remove the lock and install the latest available kernel-default, or; 2-skip installing kernel-default. By choosing to “remove” the lock, zypper will in fact ignore the existence of the lock, not remove it, because of the wildcard in the lock; and proceed with installing a kernel-default.

Yep it’s showing locked.

sudo zypper ll 

# | Name                 | Type    | Repository | Comment 
1 | kernel-default       | package | (any)      |  
2 | kernel-default-base  | package | (any)      |  
3 | kernel-default-devel | package | (any)      |  
4 | kernel-devel         | package | (any)      | 

Not as easy as I thought.

Problem: the to be installed bbswitch-kmp-default-0.8_k5.17.1_1-11.61.x86_64 requires ‘kernel-uname-r = 5.17.1-1-default’, but this requirement cannot be provided

I’m not sure if I even need this?

zypper info --requires  bbswitch    
Loading repository data... 
Reading installed packages... 

Information for package bbswitch: 
Repository     : Main Repository (OSS) 
Name           : bbswitch 
Version        : 0.8-11.61 
Arch           : x86_64 
Vendor         : openSUSE 
Installed Size : 25.7 KiB 
Installed      : Yes (automatically) 
Status         : out-of-date (version 0.8-11.38 installed) 
Source package : bbswitch-0.8-11.61.src 
Summary        : Bumblebee ACPI kernel module 
Description    :  
    bbswitch is a kernel module which automatically detects the required 
    ACPI calls for two kinds of Optimus laptops. 
Requires       : [2] 
    (kmod(bbswitch.ko) if kernel)

It’s the kernel module that is patched, not the kernel… just remember you may be forsaking an important security issue on a package totally unrelated to a kernel update, not dupping may have the potential to expose your system (unlikely, but is possible).

I see you have an issue with bbswitch, is this system a laptop? To me a simple edit of one file and changing a number or adding a kernel version is a lot easier to maintain than having to add a lock for this and that AND remember to remove so you can actually update the system…

It is a laptop…a old asus laptop. The package says it’s for “Optimus laptops”. I’m not too concerned about the security as I’m behind two firewalls and use nat; also the browser is the most used so I regularly update it.

Then yes it’s needed, so next question, do you need the features the proprietary driver provide?

Nvidia kernel modules are built for specific versions of the kernel. In your case 5.14(nvidia**-gfxG04-kmp-default-390.144_k5.14.11_2-31.5.x86_64**) was the last working on your system from your post.

Locking the nvidia kernel module isn’t what you’re after but for some reason you’re updating to the new kernel when running zypper dup even after placing a lock on the kernel.
I’m assuming that’s because you’re removing the lock via the zypper prompt when doing a zypper dup because it suggests installing the new nvidia kernel module for 5.16 or 5.17.
Put the additional lock on the Nvidia kernel module as suggested and you should be able to zypper dup without complications.

Do it this way if you’re not happy with the other suggestions.

No sir, after the lock it’s not updating the kernel anymore…I was just saying dup complained cause the bbswitch has a newer version and it’s apparently kernel specific as well. It’s not a huge deal, I can lock that to or just wait until the latest patch to the modules hits the main repo.