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: http://www.ingoreise.de/panic-s.jpg
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.
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).
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 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.
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.
Solved!
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.
But now I’ve a backup, can boot again and a fix in reach.