# zypper addlock kernel-default-4.3.0-1.1
Specified lock has been successfully added.
Looks promising, but how can I know it works? If the lock matches any package at all, it must have some measurable effect on further treatment of that package, right?
So let’s see if zypper has anything against removing the package (by that exact name):
# zypper rm kernel-default-4.3.0-1.1
Loading repository data …
Reading installed packages …
Resolving package dependencies...
The following package is going to be REMOVED:
kernel-default-4.3.0-1.1
1 package to remove.
The action will free up 226,7 MiB disk space.
Do you want to continue? [y/n/? show options] (y):
(1/1) Removing kernel-default-4.3.0-1.1 ........[succeeded]
No warning that the package was locked! In fact, it’s still locked, as seen by zypper locks.
But the lock is just a pattern you say? How about this (very general) pattern:
# zypper addlock kernel
# zypper up kernel-firmware
Loading repository data...
Reading installed packages...
No update candidate for 'kernel-firmware-20151109git-1.1.noarch'. The highest available version is already installed.
Resolving package dependencies...
Nothing to do.
It actually tried!
I had really hoped I could test the lock itself without actually waiting for the next kernel update, and actually letting it try upgrading my precious kernel version! Am I having the wrong expectations, or should I report this as a bug?
I see you have no replies to this so far. I’m having similar issue, and share my details in the hope it gives some ideas or help:
When I did #zypper patch, I got openSUSE-2016-1426 and openSUSE-2016-1438 as needed patches. Installed them because I’ve trusted openSUSE devs and zypper for long time now, no problems. These two patches indicate the need to upgrade the kernel from kernel-default-4.4.27 to kernel-default-4.4.36 so I install them; of course reboot is required. On reboot, my system stalls at black screen with error message:
error: [1.785009] tpm_tis 00:08 “A TPM error (6) occurred attempting to read a pcr”
Have no idea what any of this means. Note: my systems does have a TPM feature in the bios, but the TPM and UEFI have both been turned off since 2 years ago; no software or hardware boot problems since initial set-up. Reboot system and scroll down (with Leap-42.2 dvd boot) to option to select ‘safe mode’ or previous kernel. Previous kernel is 4.4.27 and boots fine. I would stay with the earlier kernel except that the 2 patches listed above are featured CVE security issues! Have no clue what to do next. So I use #zypper addlock openSUSE-2016-1426 and also #zypper addlock openSUSE-2016-1438. Zypper tells me that locks are properly entered in zypper. But when I do #zypper patch and/or #zypper up neither lock is kept. Again, I cannot solve your issue or mine, but the info may help you as you investigate. Hope this helps! Take Care. Ignore profile:
currently using Leap-42.2 with kernel 4.4.27 on same Lenovo M78. (sorry, edit profile problems!)
Unfortunately (or maybe that’s fortunately) I’m not seeing what the poster from a year ago and you (rob) are seeing:
I’m on TW, and I have an existing lock on kaffeine (which I had added through the Yast SM module not so long ago) and its respected:
# zypper rm kaffeine
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Problem: conflicting requests
Solution 1: remove lock to allow removal of kaffeine-1.2.2-33.3.x86_64
Solution 2: do not ask to delete all solvables providing kaffeine.x86_64 = 1.2.2-33.3
Choose from above solutions by number or cancel [1/2/c] (c): c
To check / simulate what the OP did, I choose a small test package not currently installed on this system. The results are as expected:
# zypper in libvulkan_intel
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following NEW package is going to be installed:
libvulkan_intel
1 new package to install.
Overall download size: 792.1 KiB. Already cached: 0 B. After the operation, additional 2.4 MiB will be used.
Continue? [y/n/? shows all options] (y): y
Retrieving package libvulkan_intel-13.0.2-148.1.x86_64 (1/1), 792.1 KiB ( 2.4 MiB unpacked)
Retrieving: libvulkan_intel-13.0.2-148.1.x86_64.rpm ...............................................................................................................[done (916.4 KiB/s)]
Checking for file conflicts: ....................................................................................................................................................[done]
(1/1) Installing: libvulkan_intel-13.0.2-148.1.x86_64 ...........................................................................................................................[done]
# zypper addlock libvulkan_intel
Specified lock has been successfully added.
# zypper rm libvulkan_intel
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Problem: conflicting requests
Solution 1: remove lock to allow removal of libvulkan_intel-13.0.2-148.1.x86_64
Solution 2: do not ask to delete all solvables providing libvulkan_intel.x86_64 = 13.0.2-148.1
Choose from above solutions by number or cancel [1/2/c] (c): c
Further, if I had selected 1 to remove the package (as I did just a second ago, since my last post above) you’re asked to confirm the operation:
Choose from above solutions by number or cancel [1/2/c] (c): 1
Resolving dependencies...
Resolving package dependencies...
The following package is going to be REMOVED:
libvulkan_intel
1 package to remove.
After the operation, 2.4 MiB will be freed.
Continue? [y/n/? shows all options] (y): y
(1/1) Removing libvulkan_intel-13.0.2-148.1.x86_64 ..............................................................................................................................[done]
I think package locks don’t work the way you expect for kernel packages. This is probably related to the multi-version kernel support.
Package locks work fine for other packages.
If you really want to lock the kernel packages, maybe try disable multi-version kernel support at the same time (in “/etc/zypp/zypp.conf” as I recall).