Kernel panic after update to kernel 4.4.136-4

After the automatic update to kernel 4.4.136-4 my system boots into a kernel panic. There was a further update to 4.4.136-5 but is has the same problem.
See screenshot below:

I’m now back to 4.4.135-8-default. Thanks for the multikernel feature! To keep this I’ve commented

## Default: Do not delete any kernels if multiversion = provides:multiversion(kernel) is set
# multiversion.kernels = latest,latest-1,running

in /etc/zypp/zypp.conf to keep this working kernel available.

Are there others with the same problem? Any idea what to do?

Google pointed me to set selinux=0 for exactly this error message, but it had no effect for me.



At some time in the past, I added “oldest” to the list of what to keep. Then, every so often I would manually remove the oldest after I was sure that the current kernel was good.

Hmm, I am not seeing that kernel update. Perhaps you are using the update-test repo? Or maybe they have pulled that patch. The latest that I am seeing is 4.4.132-53. However, I’m mostly using Leap 15.0 these days, so I may have missed some 42.3 updates.

@nrickert: The first answer and already helpful!
I checked the source of the kernel package and indeed, it’s non standard (but hosted by opensuse):

> rpm -qi kernel-default-4.4.136-4.1.x86_64
Name        : kernel-default
Version     : 4.4.136
Release     : 4.1
Architecture: x86_64
Install Date: Tue 12 Jun 2018 07:18:23 PM CEST
Group       : System/Kernel
Size        : 248282814
License     : GPL-2.0
Signature   : RSA/SHA256, Mon 11 Jun 2018 02:29:44 PM CEST, Key ID 8e6b853275c01b00
Source RPM  : kernel-default-4.4.136-4.1.nosrc.rpm
Build Date  : Mon 11 Jun 2018 02:25:23 PM CEST
Build Host  : lamb71
Relocations : (not relocatable)
Vendor      : obs://
URL         :
Summary     : The Standard Kernel
Description :
The standard kernel for both uniprocessor and multiprocessor systems.

Source Timestamp: 2018-06-09 18:40:15 +0200
GIT Revision: 9bd4145978ed46e9481350f18e642555a85666ea
GIT Branch: openSUSE-42.3
Distribution: **home:Nemton** / openSUSE_Leap_42.3

To be honest, I don’t remember when I added this repo. I assume it’s where I pulled skype. Zypper shows some repos I’m not really aware of:

> zypper lr -E
Repository priorities are without effect. All enabled repositories share the same priority.

#  | Alias                               | Name                              | Enabled | GPG Check | Refresh
 1 | Packman                             | Packman                           | Yes     | (  ) No   | Yes    
 2 | google-chrome                       | google-chrome                     | Yes     | (  ) No   | Yes    
 3 | | home:winski                       | Yes     | (  ) No   | Yes    
 4 | | KDE:Extra                         | Yes     | (  ) No   | Yes    
 5 | | home:mrbadguy                     | Yes     | (  ) No   | Yes    
 6 | | KDE:Qt5                           | Yes     | (  ) No   | Yes    
 7 | | home:Nemton                       | Yes     | (  ) No   | Yes    
 8 |    | libdvdcss repository              | Yes     | (  ) No   | Yes    
 9 |      | Packman Repository                | Yes     | (  ) No   | Yes    
15 | repo-non-oss                        | openSUSE-Leap-42.3-Non-Oss        | Yes     | (  ) No   | Yes    
16 | repo-oss                            | openSUSE-Leap-42.3-Oss            | Yes     | (  ) No   | Yes    
19 | repo-update                         | openSUSE-Leap-42.3-Update         | Yes     | (  ) No   | Yes    
20 | repo-update-non-oss                 | openSUSE-Leap-42.3-Update-Non-Oss | Yes     | (  ) No   | Yes    
21 | teamviewer                          | TeamViewer - x86_64               | Yes     | (r ) Yes  | No     

But, disabling this repo won’t downgrade my kernel?

Where are you getting 4.4.136-4 from? Zypper and are showing me latest is still 4.4.132-53.1.

No, it won’t.

Best to disable (or remove) any repository that you do not know the reason for it being installed. Alien (non openSUSE signed) repositories tend to be “the usual suspects” when anything goes wrong.
If you use YaST to replace the bad kernel with one from updste/leap/42.3/ things should be fixed. But what did you do to update and add a kernel from another repository? I do not think that the use of “zypper patch” or “zypper update” should not have updated packages across different vendors (i.e. openSUSE to Nemton).

My (problematic) kernel is obviously from

I think, I’ve added the Nemton repo to install skype. I do remember vendor changes, but only related to vlc and related libraries/codecs. I do not remember a vendor change for the kernel, but it must have happened at sometime.
I’ll disable alien repos (excl. Packman) and try the downgrade via YaST this evening.

P.S.: I’m quite happy about the root cause. My first thought with the kernel panic was a hardware error. And yes, our backup was no as fresh as it should have been :slight_smile: But now I’ve a backup, can boot again and a fix in reach.

Your link is to kernel-default-base. Unless you are running a VM, you almost certainly should not be using kernel-default-base. Instead you most likely should be using the standard kernel, kernel-default, and version 4.4.132-53.1.

@mrmazda: Sorry, I’m not using exactly this kernel rpm. I just wanted to show from which source my system got the 4.4.136-5 kernel.
Using this kernel was not intended at all, I’m happy with the standard one.

I agree with this.

When I have used additional repos, my practice has been to disable them after installing whatever I wanted from them. Then I can occasionally re-enable to check if there is an update for the particular software. But otherwise best to leave disabled most of the time.

Today I found time to disable all “alien” repos, install the plain 42.3 kernel (4.4.132-53) and delete all newer ones. The system now again comes up without problems and without manually selecting a specific kernel. I’d expected at least one conflict going back to an older kernel, but everything worked smooth.

Many thanks for your help!



I’m glad to hear that it is now working as it should.