How safely upgrade kernel (so can default to already working one if needed)?

That’s it, I protected kernel-desktop in Yast and it worked, doesn’t appear anymore :slight_smile:
Thank you very much sir.

Interesting discussion in Tumbleweed and Pre-release Beta sections (particularly post #4 of this thread) suggest that the issues I experienced may relate to nVidia driver package rather than my inexperience with multiversion.

Trust this is useful.

One more question :

When I upgraded kernel from org 3.4.x to 3.7.x I wasn’t using ATI Catalyst drivers, so I installed those drivers after kernel upgrade, that all went fine.

Now with kernel 3.7.x and installed ATI catalyst drivers, what would be the proper way to upgrade the kernel and use ATI catalyst drivers ?

  1. Install new kernel , reboot, install ATI drivers, reboot.
  2. Install new kernel, install ATI drivers, reboot.
  3. Something else.

2 should work. 1 also of course but don’t need 2 reboots

Yeah, 2 was logical to me but had to ask before I try it out.


So what are the kernel modules? How do I know what might/might-not be compatible and how do I fix that?

Well, my laptop doesn’t have nVIDIA. I believe it’s just an Intel-integrated GPU.

But if I wanted to try out a more recent kernel what steps would I need to take to make sure all the modules work with it or are updated to work with it?

On 2013-02-13 02:56, 6tr6tr wrote:
> How do I know what might/might-not be
> compatible and how do I fix that?

Become a kernel dev…

Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

Ah, so this is not for anyone less knowledgeable than that.

I assume though, I can install a new kernel and roll back if there are issues, correct?

On 2013-02-14 01:56, 6tr6tr wrote:
> I assume though, I can install a new kernel and roll back if there are
> issues, correct?

Yes, that’s what we can do.

Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

I am not sure where all of this is headed exactly. We have one known kernel developer here that is a regular, but the rest of us just learn as we go. The kernel is the Linux operating system and it is Linux while most everything else is added by our distribution, in this case, openSUSE. For the most part hardware drivers are built into the kernel and come in the form of modules that can be loaded (built into the kernel no matter what), excluded (not present at load time) and modules allowed to load only if the hardware is found at boot time. Since something might get plugged in later, think USB 3 or a Thumb drive, you may just want to include support there all of the time no matter if the hardware was found or not. The last function (of installing an unused driver) can make the kernel bigger and perhaps slower so there is an art to deciding what stays in and what is left out for the kernel that becomes part of a distribution, like openSUSE. This “configuration” comes in the form of a reusable kernel config file located on your PC and can be used as the basis of any kernel compile you make on your own. Each release of openSUSE comes with a certain kernel version, the most recent stable kernel version at the point the latest openSUSE distribution feature list gets frozen and so 3.7 is the basis for openSUSE 12.3. As time goes forward, released kernels get updates for security and to fix bugs. The new released kernels show up into the openSUSE update repository. You have the option to configure YaST to maintain more than one kernel version, within the same major release, just in case a new kernel does not agree with your system. Not keeping a spare kernel before its too late has bit more than one person here in the openSUSE forum. You can also decide to add kernel repositories into YaST, (like this Index of /repositories/Kernel:/HEAD/standard) to get the very latest one installed if you wish. And I have SAKC, a bash script to install any version of the kernel posted at The Linux Kernel Archives. SAKC can be used to modify the configuration, either manually or in a GUI if you wish. As to hardware drivers, one final word about binary drivers, that must be externally compiled and installed into the kernel. This is true for the proprietary nVIDIA and AMD video drivers and true for the VirtualBox VM drivers. These companies provide free drivers to Linux users, but chose to not supply (all) of their source code so that support could be built directly into the kernel and thus on every kernel update, major or minor, their proprietary driver must be recompiled and installed into the new kernel to work.

S.A.K.C. - SUSE Automated Kernel Compiler - Version 2.78:

Thank You,

Answering some questions…

The kernel is the heart (or the brain?) of the operating system, almost everything that happens is managed and often executed in the kernel in some way.

As for the GPU "kernel “modules,” it’s actually a “helper app” that provides compatibility to a common driver. This is one of many examples of how the Linux kernel has implemented a layered approach to interoperability which has been happening since approx. kernel 2.6.x. In this case, it allows the development of the kernel to proceed at a different pace than the GPU driver (nVidia in this case). The kernel can expose a more or less common interface for any GPU and the GPU manufacturer can write GPU drivers… But, instead of writing an entirely new driver to be distributed every time there is a kernel change <and> every time the GPU driver changes, a “kernel module” is implemented that “shims” the kernel to the GPU driver. In reality actually the GPU driver rarely changes so most often the GPU kernel driver provides common interoperability with common drivers despite frequent kernel changes.

This description applies strictly to the GPU kernel module described in this thread, I wouldn’t know of this use of “kernel module” would apply anywhere else, eg would absolutely not apply to “LKM” (Loadable Kernel Modules).

As for disabling kernel updates even for a past kernel, I woouldn’t advise unless you never intend to use that kernel again… But if that were the case, why would you even want a multi-version kernel? BTW - note that if you do install the multi-version kernel, you can edit the config file to limit the number of kernels you want to keep.


Maybe I didn’t describe what I want to do properly?

Here’s what I want:

  1. Currently I am on openSUSE 12.2 exactly as it was installed via liveDVD (along with zypper up)

  2. I want to keep my current kernel to be my default (so when I start up, that’s the one that runs if I do nothing)

  3. I’d like to be able to install and try out 3.6.x, 3.7.x and 3.8.x with openSUSE 12.2

  4. If those kernels work well, I’ll keep them, otherwise delete them

  5. If one of the “trial” kernels works really well, I’ll want to make that one my default

How would I do those steps?

Your wish is my command. What you need is my Grub2CMD bash script to set the default kernel to load, see option 4 in the main menu to change the default. By default, the highest kernel version is default:

GNU Grub2 Command Help/Config Editor - Version: 1.91:

And to install any kernel version you want, see my SAKC bash script, while keeping the default openSUSE one as well.

S.A.K.C. - SUSE Automated Kernel Compiler - Version 2.78:

And to keep things tidy, remove any kernels installed with SAKC with this:

S.A.K.R. - SUSE Automated Kernel Remover - Version 1.0.4:

And if there is a kernel version you can’t find at The Linux Kernel Archives, download it with this:

S.G.T.B. - SuSE Git Kernel Tarball Creator - Version 1.86:

All totally free, as in free beer and come complete with the entire source code (they are just bash scripts you can read), ready for you to use.

Thank You,

Amazing! Thank you! I can’t wait to try those out. I hope someday I’ll be able to offer you even close to that detailed and helpful a post (and code). :slight_smile:

Everyone here who likes to use openSUSE can help in the effort. No one knows everything and when you see something online here that you have direct experience with, you have got to jump in and help. If you see a question you too would like the answer to, do some research on the subject. You might be the one with the answer and learn something new at the same time. You would be amazed at how much more you can learn about using openSUSE when you try to help others in using openSUSE. And if you have any comments on using those bash script I mention, make sure to post your comments in the corresponding blog.

Thank You,

Just to mention a couple alternatives if you want to “try out” kernels without actually putting your system at risk…

Two virtualization technologies I know of allow you to run a virtualized emulator environment, matching your choice of kernel with your choice of file system.

UML(User Mode Linux) - Built into every current kernel so you don’t have to install anything. You can download practically every default vanilla kernel in existence from Today, I’ve found all sorts of problems with the pre-built bootstrap file systems but you may prefer to simply copy your existing working file system. Fairly simple and easy command syntax with a multitude of networking options.

QEMU-KVM - Although been around for awhile and is mostly solid I’ve recently been running into some issues with very recent new features. Optionally can use the libvirt graphical tools (virt-manager, virt-install). Full emulation available, can uniquely run non x86 kernels like Solaris, Alpha and ARM on your x86 machine.