Safe way of mixing repos

Hello,
I have a kaby-lake machine that requires newer kernel. Currently, I have a Leap installation with following customizations:
Kernel from Kernel:stable repo
bbswitch and virtualbox packages from Kernel:stable:KMP repo

My question is that is it possible to switch those 3 packages to Tumbleweed repos? Anyone using mixed repos? What are the risks if I for example add TW repo with lowest priority and manually link packages (kernel-default, bbswitch, etc) to TW repo.

Note: The reason I ask is that zypper sometimes installs kernel 4.4 from Leap repo and switches all above packages to Leap if I don’t follow the updates closely. Also, since kernel version from TW follows behind and more people are using it so I assume it is more stable than the version in Kernel-stable repo. Moreover, I feel safer if I use an official repo from openSUSE instead. I am trying Tumbleweed, but it had issues with the external monitor and also I don’t prefer its frequent updates to all packages.

thanks.
ilker.

Leap 42.3 should have better support for Kaby Lake, you may consider it instead.

It seems to have kernel version 4.4 and I think kaby-lake wants at least 4.10. But I will try when it is out.

Kernel:stable is the Testing Repo for Tumbleweed…

I would not switch to Tumbleweed, also I would not switch back to Kernel from Leap.
If you need an additional Kernel-Package for kernel:stable, ask.

Zypper does not switch to kernel from Leap, if you disable the Kernel from Leap, see the Versions Tab in Yast—Software.

Yes and No.

Although the kernel of 42.3 calls itself “4.4.SOMETHING” a lot of code from newer kernel versions has been backported, so it is not really a 4.4.SOMETHING any more.

AK

P.S. This means a lot of extra “fun” when packaging kernel modules for 42.3 as I had the “pleasure” to find out recently, because some (a lot) of my patches or some unpatched code does not build any more against the “4.4.SOMETHING” although it did build fine with “4.4.SOMETHING” from 42.2 and one needs some extra quirks to get things working again.

@Sauerland AFAIK you have some KMP packages in your repo, if you get hit by this, send me a PM, chances are good I already had been hit by the same problem and have a fix for it.

//Edit:

What a coincidence:

https://forums.opensuse.org/showthread.php/525768-Cannot-install-oracle-virtualbox-5-1-5-1-22_115216

I am pretty sure this is exactly that problem.

Please see wolfi323 answer :

http://forums.opensuse.org/showthread.php/525768-Cannot-install-oracle-virtualbox-5-1-5-1-22_115216?p=2828728&posted=1#4

First thing <not> to do is add the distro repo, in your case Tumbleweed. You’ll run a chance of creating a Frankenstein mising LEAP with TW.

AFAIK you can try any kernel you want from any of the kernel repos, you’ll find them in

http://download.opensuse.org/repositories/Kernel:/

As noted by others, if what you want is in Kernel:/Stable: then go ahead and add that repo.
Or, try something else, but beware that experimental kernels won’t likely have kernel modules built in so may either need to be loaded manually (if available) or won’t be suitable short of re-compilation.

After you add your new kernel repo and assuming you wish to install the newest kernel available, all you will need to do is update your system to automatically detect and install. Since nowadays multi-kernel support is default, if you find that the kernel you try won’t work, you can always reboot and select your previous kernel.

zypper up

TSU

Thanks for the replies.

@Sauerland, I don’t disable the kernel, I am just changing vendors. I didn’t know kernel-stable is a testing repo for TW.
@tsu2, why do you think kernel from kernel-stable is preferable to kernel from TW? (see what I did below). I am not looking for the newest kernel, I want a working one and as stable as possible.
@Akoellh I will definitely try 42.3 to check if it solves my issues.

For now, I decided to remove kernel-stable repo and switch my kernel to the version from TW. Here is what I did:

I added TW oss repo with a lower priority and disabled it. I changed vendor of kernel-default and few other packages from Leap to TW (also removed Leap versions to prevent future conflicts). I plan to update system regularly, since TW repo is disabled it will (hopefully) follow Leap updates (and kernel wont be updated since it is older version). Every month or so I plan to carefully run the below script “kernelUpdate.sh” which temporarily enables TW repo and updates kernel from TW.

Do you guys see any specific flaws or any risk in doing the above? Below are the details…


$ cat kernelUpdate.sh 
#!/bin/bash  -x 
# First update all packages from Leap
sudo zypper update 

sudo snapper create --description "Another Kernel Update"

# Update including TW repo 
sudo zypper --plus-content TUMBLEWEED-OSS update

echo ============ List packages from TW ================
sudo zypper --plus-content TUMBLEWEED-OSS search -i -r TUMBLEWEED-OSS


Here are my repos :


$ zypper lr


 | Alias                     | Name                                    | Enabled | GPG Check | Refresh
-+---------------------------+-----------------------------------------+---------+-----------+--------
 | repo-non-oss              | openSUSE-Leap-42.2-Non-Oss              | Yes     | (r ) Yes  | Yes    
 | repo-oss                  | openSUSE-Leap-42.2-Oss                  | Yes     | (r ) Yes  | Yes    
 | repo-update               | openSUSE-Leap-42.2-Update               | Yes     | (r ) Yes  | Yes    
 | repo-update-non-oss       | openSUSE-Leap-42.2-Update-Non-Oss       | Yes     | (r ) Yes  | Yes    
 | TUMBLEWEED-OSS            | TUMBLEWEED-OSS                          | No      | ----      | ----   


Below are packages installed from TW. (I also needed smartmontools for nvme support since Leap version is not working)



$ sudo zypper --plus-content TUMBLEWEED-OSS search -i -r TUMBLEWEED-OSS
Temporarily enabling repository 'TUMBLEWEED-OSS'. --plus-content]
Loading repository data...
Reading installed packages...


S  | Name                        | Summary                                                 | Type   
---+-----------------------------+---------------------------------------------------------+--------
i+ | bbswitch-kmp-default        | Bumblebee ACPI kernel module                            | package
i+ | kernel-default              | The Standard Kernel                                     | package
i+ | kernel-default-devel        | Development files necessary for building kernel modules | package
i+ | kernel-devel                | Development files needed for building kernel modules    | package
i+ | kernel-firmware             | Linux kernel firmware files                             | package
i+ | kernel-macros               | RPM macros for building Kernel Module Packages          | package
i+ | smartmontools               | Monitor for SMART devices                               | package
i+ | ucode-amd                   | Microcode updates for AMD CPUs                          | package
i+ | virtualbox-host-kmp-default | Host kernel module for VirtualBox                       | package




Why do you ask if you do what you want???

Do it, but do not ask for Errors…

Better way is kernel:stable.

In both of your posts you are saying kernel-stable is a better option. Why? That is exactly why I ask.

Another reason I wrote is maybe someone knows a better way to use TW kernel in Leap than the above (which is not ideal).

It is clear that using kernel from a different repo has its own risks. But what errors are you mentioning specifically which doesn’t exist in the case of using kernel-stable and its kmp repos?

Without a huge amount of care it is possible to mix in other parts of TW and thus break leap entirely. It is far far better to use the 42.2 stable repo.

If you don’t want to take advise why post??

Using the kernel from 42.2 repo won’t work on a kaby-lake cpu, at least not on my machine. That is the point of this topic.

I post to get a technical answer to a question. Not to get into unnecessary discussions.

Answer:

In Kernel:stable is only the Kernel, nothing more.

I am using the Repo for a Year…
In openSUSE 13.2 and now in Leap 42.2

Mixing repos? No, no, no. You’re breaking the integrity of your system. And this will no doubt lead to other breakage, erroneous behaviour. Maybe not now, but it will break. At that point nobody will be able to help. If you want TW’s kernel, install or upgrade to TW.

Just imagine next scenario: you need to compile a kernel module. Your Leap has gcc-4.8.5, TW’s kernel is done with gcc-7* . And that’s only one example.

TW is not for me (I have low risk appetite), and also it is having HDMI wake-up issues of external monitor.

I won’t be compiling kernel or any other component, but as I understand the main risk is that packages from TW might be installed unintentionally during updates or new installs if the user doesn’t monitor closely, which might lead into trouble.

The alternative (Leap with Kernel-Stable) had its own glitches I experienced. For example a minute ago when I try to switch vendors:



Problem: kernel-default-base-4.12.0-2.1.g7c5c393.x86_64 conflicts with kernel-default = 4.12.0-2.1.g7c5c393 provided by kernel-default-4.12.0-2.1.g7c5c393.x86_64
 Solution 1: deinstallation of kernel-default-4.12.0-2.1.g7c5c393.x86_64
 Solution 2: do not install kernel-default-base-4.12.0-2.1.g7c5c393.x86_64



There is nothing new. kernel and kernel-base are mutually exclusive. kernel-base provides reduced set of modules and is intended for something like VM where you normally do not need hardware drivers. It had been this way for as long as I remember. Why do you try to install both of them?

It was already installed (from Leap repo version 4.4) I tried to change vendor to kernel-stable repo.

Akoellh wrote:

> Although the kernel of 42.3 calls itself “4.4.SOMETHING” a lot of code
> from newer kernel versions has been backported, so it is not really a
> 4.4.SOMETHING any more

Is this valid for the kernel-vanilla too or only for kernel-default of 42.3?

**After applying today update which contains kernel 4.4.74-1, I can install Virtualbox without problem.

**