I got the latest upgrade today (2018-06-18) for my opensuse LEAP 42.3, which contained a kernel upgrade to 4.4.136-56. However this doesn’t boot but produces a kernel panic and halts. Fortunately, I could boot into the previous 4.4.132 version.
This has happened to a colleague’s workstation, but OTOH mine upgraded and rebooted fine. The two setups differ in some major respects though. The one where the boot succeeded is a new-style default setup: the whole system (including /boot) is on a btrfs filesystem created on a primary partition, with a separate vfat-formatted partition for /boot/efi. The one that didn’t boot seems to be configured for a legacy (i.e. non-EFI) boot. It has a dedicated partition for /boot and the rest of / is on an LVM logical volume (both formatted ext4).
My system is also an EFI system where / includes the /boot and /boot/efi is on a separate filesystem which is vfat formatted. The root (including /boot) is an ext4 system and is a logical volume where the whole volume group is based on a s/w raid1. The first lines of the panic are
2.264548] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
2.264548]
2.264645] CPU: 0 PID: 1 Comm: init Not tainted 4.4.136-56-default #1
2.264709] Hardware name: System manufacturer System Product Name/Z170-P, BIOS 3301 02/10/2017
.
.
.
above typed from picture taken of screen, so maybe contains typos.
just a pretty standard install but choosing EXT4 as the default FS. After some frantic searching to see whether the hardware is still under warranty I did eventually think to check whether the older kernels would boot, and indeed I’m able to use this system once again with the older kernel.
I guess if not already done this should be put into bugzilla, unfortunately bugzilla.opensuse.org seems inaccessible at present.
Bugzilla seems to be working now, but I don’t know how to report this problem (never used bugzilla before). If it hasn’t reported yet (I think), could somebody do report this?
Another related question: after the update, it appears there is only 1 older kernel version still available. I am afraid that in case a correction would also fail, I will be stuck with 2 non-bootable kernels. Is there a way to retain the working kernel (by making it sticky, or to allow more than 2 kernels)?
thanks. I have modified my /etc/zypp/zypp.conf file to retain more kernels and to retain the current working 4.4.132 kernel. Will see if that works with the next upgrade.