erlangen:~ # zypper ar -f https://download.opensuse.org/repositories/Kernel:/HEAD/standard testkernel
Adding repository 'testkernel' ........................................................................................................................................................................................................[done]
Repository 'testkernel' successfully added
URI : https://download.opensuse.org/repositories/Kernel:/HEAD/standard
Enabled : Yes
GPG Check : Yes
Autorefresh : Yes
Priority : 99 (default priority)
Repository priorities are without effect. All enabled repositories share the same priority.
erlangen:~ # zypper dup --from testkernel -D
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
2 Problems:
Problem: problem with installed package kernel-firmware-20180518-1.1.noarch
Problem: problem with installed package ucode-amd-20180518-1.1.noarch
Problem: problem with installed package kernel-firmware-20180518-1.1.noarch
Solution 1: install kernel-firmware-20180518-218.1.noarch (with vendor change)
openSUSE --> obs://build.opensuse.org/Kernel
Solution 2: keep obsolete kernel-firmware-20180518-1.1.noarch
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): 1
Problem: problem with installed package ucode-amd-20180518-1.1.noarch
Solution 1: install ucode-amd-20180518-218.1.noarch (with vendor change)
openSUSE --> obs://build.opensuse.org/Kernel
Solution 2: keep obsolete ucode-amd-20180518-1.1.noarch
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): 1
Resolving dependencies...
Computing distribution upgrade...
The following 2 packages are going to be upgraded:
kernel-firmware ucode-amd
The following 2 packages are going to change vendor:
kernel-firmware openSUSE -> obs://build.opensuse.org/Kernel
ucode-amd openSUSE -> obs://build.opensuse.org/Kernel
2 packages to upgrade, 2 to change vendor.
Overall download size: 68.7 MiB. Already cached: 0 B. No additional space will be used or freed after the operation.
Continue? [y/n/...? shows all options] (y):
“zypper dup” does not switch vendor by default since quite some time. Does “zypper dup --allow-vendor-change” work? Or you can explicitly install exact version from another repository, then zypper will offer vendor switch.
Zypper is an excellent spftware management backend. However, in some cases like this one it will stand all your trials without yielding it : )
Me, I’ve always updated any OpenSUSE distro on to at least the kernel version currently presented as stable, so I know about the problem. When having added the kernel repo you prefer (either STABLE OR HEAD, both will always make troubles) do as follows:
Do NOT give the additional kernel repo a higher priority for this might disturb later automatic updates!
Go into the graphical Yast software manager, check the option “allow vendor change”, then from inside the graphical software tool do update each kernel package “by hand” - no fear, because in an ordinary case it’s three packages only you can easily identify from the shown newer versions available outlined by colour, too, two “kernel-…” packages and one “ucode”. So you have to use the package search function twice, first for “kernel”, afterwards for “ucode”.
After reboot you’ll have the most modern kernel in use, but every automatic update following later on will update both kernels, the leading one you have chosen and the distribution’s specified one as well - just for your accomodation because you might want to fall back.
Cheers.
Thank you all for help.
But I think I found the problem.I think that repository is not sync yet.
I have kernel-default and kernel-devel (4.16.11-1).
Zypper do not want to upgrade because in repository there is only kernel-default-4.17.rc5, kernel-default-devel-4.17.rc5 and kernel-devel-4.17.rc6.
I tried to explicity install rc5 but it not want because nothing provide devel-rc5 (only rc6).
Now is working with kernel 4.17rc7 because there are kernel-default and kernel-devel. The reason because not worked last time - there wasn’t the same kernel-default and kernel-devel (number).
I tried the new kernel because I read that with kernel 4.17 some of the AMD errors messages from boot will disappear. Now the only error is that with sp5100_tco.
Indeed. Last time was kernel-default.4.17.rc6 build only for 32 bit. For 4.17.rc5 was 64bit build (default and default-devel) but kernel-devel was only for 4.17.rc6. Because I wanted kernel-devel I was not able to install anything.
BTW it seems that are some problems with kernel 4.17.rc7 and Nvidia 396.24. I switched to nouveau.
Unfortunately something like that can happen on additional OBS repo, and cannot be prevented.
OBS treats all architectures independently of each others. If a package is ready for one architecture it will be published, even if it hasn’t been built yet on other architectures.
Generally that’s probably a good thing, but in the case of noarch packages it can be problematic like in this case, because “noarch” is shared between i586 and x86_64, there even only is one directory on the servers.
I.e. a repo typically has three directories on the server, i586, x86_86, and noarch.
Shouldn’t happen with Tumbleweed itself of course (normally, unless there are other problems…), because that’s only published explicitely when a snapshot is considered to be ready.
I think that when you use some “not official” repositories you are aware that not all things will be fine.
Anyway I am very happy with TW - less errors than one expected from a rolling distro.
And that’s probably the main reason why Tumbleweed exists in its current form in the first place: to be able to always get the latest and greatest software/packages without the risks of having to add dozens of “3rd party” repos, and the inherent danger to mix incompatible package versions by doing so.