install by zypper dup force alternate kernel

I currently have tumbleweed installed on my partition, but I would like to make it 15.3. (This is in a separate partition from my normal use, so there is no danger of me not being able to access my system if it messes up). The problem is, the kernel that is standard in 15.3 won’t support the new hardware of my NVMe PCIe SSD. So I need to install a 15.3 base system but with a new kernel, preferably one that is at least as high as what is available in tumbleweed.

So I deleted all the tumbleweed repositories and added in the 15.3 repositories, including the Kernel:stable repository, because I saw that it contains a kernel that I think will work on my system. Here is what my repositories look like:

#  | Alias          | Name           | Enabled | GPG Check | Refresh
 1 | Downloads      | downloads      | Yes     | ( p) Yes  | Yes
 2 | google-chrome  | google-chrome  | Yes     | (r ) Yes  | Yes
 3 | kernel-stable  | kernel-stable  | Yes     | (r ) Yes  | Yes
 4 | packman        | packman        | Yes     | (r ) Yes  | Yes
 5 | repo-non-oss   | repo-non-oss   | Yes     | (r ) Yes  | Yes
 6 | repo-oss       | repo-oss       | Yes     | (r ) Yes  | Yes
 7 | source-non-oss | source-non-oss | Yes     | (r ) Yes  | Yes
 8 | source-oss     | source-oss     | Yes     | (r ) Yes  | Yes
 9 | update-non-oss | update-non-oss | Yes     | (r ) Yes  | Yes
10 | update-oss     | update-oss     | Yes     | (r ) Yes  | Yes

The kernel-stable repository is at this uri:

And here are the kernels that are available:

# zypper se -s kernel-defaultLoading repository data...
Reading installed packages...

S  | Name                           | Type       | Version                  | Arch   | Repository
i+ | kernel-default                 | package    | 5.13.8-1.1               | x86_64 | (System Packages)
v  | kernel-default                 | package    | 5.13.12-5.1.g33df9c6     | x86_64 | kernel-stable
v  | kernel-default                 | package    | 5.13.12-5.1.g33df9c6     | i586   | kernel-stable
v  | kernel-default                 | package    | 5.3.18-57.3              | x86_64 | repo-oss
   | kernel-default                 | srcpackage | 5.13.12-5.1.g33df9c6     | noarch | kernel-stable
   | kernel-default                 | srcpackage | 5.3.18-57.3              | noarch | source-oss
   | kernel-default-base            | package    | 5.12.9-1.1.gf17eb01.66.1 | x86_64 | kernel-stable
   | kernel-default-base            | package    | 5.12.9-1.1.gf17eb01.66.1 | i586   | kernel-stable
   | kernel-default-base            | package    | 5.3.18-        | x86_64 | repo-oss
   | kernel-default-base            | srcpackage | 5.12.9-1.1.gf17eb01.66.1 | noarch | kernel-stable
   | kernel-default-base            | srcpackage | 5.3.18-        | noarch | source-oss
   | kernel-default-base-rebuild    | package    | 5.12.9-1.1.gf17eb01.66.1 | x86_64 | kernel-stable
   | kernel-default-base-rebuild    | package    | 5.12.9-1.1.gf17eb01.66.1 | i586   | kernel-stable
   | kernel-default-base-rebuild    | package    | 5.3.18-        | x86_64 | repo-oss
   | kernel-default-debuginfo       | package    | 5.13.12-5.1.g33df9c6     | x86_64 | kernel-stable
   | kernel-default-debuginfo       | package    | 5.13.12-5.1.g33df9c6     | i586   | kernel-stable
   | kernel-default-debugsource     | package    | 5.13.12-5.1.g33df9c6     | x86_64 | kernel-stable
   | kernel-default-debugsource     | package    | 5.13.12-5.1.g33df9c6     | i586   | kernel-stable
   | kernel-default-devel           | package    | 5.13.12-5.1.g33df9c6     | x86_64 | kernel-stable
   | kernel-default-devel           | package    | 5.13.12-5.1.g33df9c6     | i586   | kernel-stable
   | kernel-default-devel           | package    | 5.3.18-57.3              | x86_64 | repo-oss
   | kernel-default-devel-debuginfo | package    | 5.13.12-5.1.g33df9c6     | x86_64 | kernel-stable
   | kernel-default-extra           | package    | 5.3.18-57.3              | x86_64 | repo-oss
   | kernel-default-livepatch-devel | package    | 5.13.12-5.1.g33df9c6     | x86_64 | kernel-stable
   | kernel-default-livepatch-devel | package    | 5.13.12-5.1.g33df9c6     | i586   | kernel-stable
   | kernel-default-optional        | package    | 5.3.18-57.3              | x86_64 | repo-oss

You can see that 5.13 is available in the kernel-stable repository, but when I run a zypper dup, it will only choose the 5.3 kernel from the oss repository. I tried changing the priority of the kernel-stable repository so that it would be preferred over the oss, but it didn’t help.

How do I make my system do a zypper dup and at the same time install the 5.13 kernel?

Kernel:stable Repo does not work in Leap because it is build against the libs in Factory.

Here with my own kernel:stable:backports Repo (a branch of the above):

uname -a && lsb-release -id
Linux linux64 5.13.11-lp153.5.g8c13a2d-default #1 SMP Mon Aug 16 05:23:16 UTC 2021 (8c13a2d) x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: openSUSE
Description:    openSUSE Leap 15.3

Ok, thank you. I have switched the kernel repository to the one you suggested.

However, when I setup the zypper dup, it still calculates the distribution upgrade with the 5.3 kernel instead of the 5.13. Is there a way to force the zypper dup to look at the 5.13 kernel instead of the 5.3? I was thinking of running the installation on it and adding a lock, but that seems like a bad idea.


zypper dup --allow-vendor-change --from xxxxx 

you have to choose explizit --allow-vendor-change because vendor-change in dup is disable for some time.
Also use --from xxxxxxx (kernel:stable Repo)
to not switching all packages, only the one that are in the kernel:stable:backport Repo.

I do not recommend a

zypper dup

I would use

zypper dup --from

and do it some times more to get the packages from that Repo I want (and in the right order).

Ok, I have upgraded the kernel by that method. Haven’t tried to reboot yet. Still tried to do a full zypper dup afterwards to go to 15.3, with a lock on the new kernel, and it seems like 15.3 just isn’t ready to be run with an advanced kernel like that.

The reason I would prefer 15.3 to tumbleweed is I am generally not savvy enough to work through a lot of the technical glitches that come up when using the bleeding edge developments in tumbleweed in a reasonable amount of time. I tried it in the past and had to go back to a more stable distribution because of the time I was spending fixing things - I think that was when 42.3 was out. Of course, fixing things keeps you sharp, so I don’t totally mind I suppose.

So if the real solution is that I just need to stay with tumbleweed, is there a way to use tumbleweed in such a way that it is a little more stable? Perhaps by doing something like only running a zypper dup in tumbleweed once a month instead of every week?

If you go ahead and to the “zypper dup”, then it will probably keep the Tumbleweed kernel that you already have. And you should be able to boot that to make further changes and install the kernel that you want.

An addendum. If you are using UEFI booting, you might need to disable secure-boot for this to work. Once you switch to Leap, the “shim.efi” that comes with Leap 15.3 may not recognize the Tumbleweed kernel. You can later fix that by manually installing the kernel that you want. But, until you get to that point, try disabling secure-boot.

Ok, so I have installed the new kernel and rebooted, and added a lock to the new kernel so that zypper won’t change it. Here is what happens when I try a zypper dup:

# zypper dupLoading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
3 Problems:
Problem: problem with the installed libnfs13-4.0.0-1.7.x86_64
Problem: the installed kernel-default-5.13.8-1.1.x86_64 conflicts with 'filesystem < 84' provided by the to be installed filesystem-15.0-11.3.2.x86_64
Problem: the to be installed icewm-1.4.2-7.12.1.x86_64 requires 'icewm-theme-branding', but this requirement cannot be provided

Then when it gets to the 2nd problem, here is what comes up:

Problem: the installed kernel-default-5.13.8-1.1.x86_64 conflicts with 'filesystem < 84' provided by the to be installed filesystem-15.0-11.3.2.x86_64 Solution 1: Following actions will be done:
  deinstallation of filesystem-84.87-2.1.x86_64
  deinstallation of systemd-248.6-2.1.x86_64
  deinstallation of yast2-packager-4.4.6-1.1.x86_64
  deinstallation of yast2-network-4.4.22-1.1.noarch
  deinstallation of yast2-4.4.16-2.1.x86_64
 Solution 2: keep obsolete filesystem-84.87-2.1.x86_64
 Solution 3: remove lock to allow removal of kernel-default-5.13.8-1.1.x86_64

Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c/d/?] (c):

So it looks like the filesystem 84 is what is forcing the kernel back down if I remove the lock.

Not sure what exactly is filesystem 84?

BTW, I really appreciate everyone that is trying to help on this. This is why I like the openSUSE community.

I habitually lock kernels. I install them when I’m good and ready, and I choose when, or even if, to remove them. This rarely causes a problem. With the 15.2 to 15.3 dup on at least one installation here that proved an exception, but I wouldn’t expect the same obstacle going backwards from TW’s already installed newer kernel. You could chattr +i its initrd to avoid the possibility of an automatic initrd rebuild causing some compat issue or other breakage.

I don’t understand how some particular NVME device could require a kernel newer than Leap’s for support.

I am not sure why that happened either. When I initially tried to install 15.3, the 15.3 system that was loaded by the USB install media for 15.3 wouldn’t read that the new NVMe SSD that I installed was there. So that is the reason I went to tumbleweed in the first place. It was suggested that the newer kernel in tumbleweed would be able to read any advanced hardware. It worked.

I’m not sure about that.

Note that it says “filesystem < 84”. Checking the package description, the “filesystem” package gives the directory layout. And that recently changed with Tumbleweed. For example, with Tumbleweed “/bin” no longer exists as a separate directory and is instead a symlink to “/usr/bin”. This might be a big problem for going back to Leap from current Tumbleweed.

Perhaps a better plan would be to stay with Tumbleweed for now, and file a bug report. Perhaps that can persuade the kernel team to come up with a kernel for Leap 15.3 that supports your hardware.

Well, I tried to ignore the filesystem 84 thing when executing the zypper dup, and it broke the installation. In fact, it broke the system, and it is no longer useable. As I mentioned, it is really not a problem because this was an experimental installation in a separate partition that I don’t need, so I can still boot into tumbleweed on another partition and work on that.

I think for now I will just try and run tumbleweed and see how it goes.

What about providing full info about hardware?

1st solution: change installation image:
With your new hardware you’ll need the newest kernel and possibly Mesa 3D.

2nd solution: use SATA drive for Leap. May work.

3rd solution: use SATA drive + add SATA controller.

4th solution: PCIe lanes from CPU may not work, but these lanes from chipset may do.