I recently performed a system update which included a kernel update. The system has full hard disk encryption using LUKS, so when I boot up I need to enter a decryption password once before accessing grub and once after choosing a boot entry. Now when I try and boot my computer it get to the grub prompt (i.e. I enter the passoword once) but after that the system hangs after displaying
EFI stub: UEFI Secure Boot is enabled
Loading Linux 4.12.14-lp151.28.52-default ...
Loading initial ramdisk ...
The decryption password is not requested a second time. The system just hangs indefinitely.
The computer is a Lenovo X260 laptop.
The old kernel version was 4.12.14-lp151.28.52
The new kernel version is 4.12.14-lp151.28.52
I am using UEFI secure boot.
I have tried choosing the previous kernel from grub, but get the same hang.
The root partition uses btrfs and so I have also tried the grub option starting from a read-only snappshot from before the update. This also hangs in the same way.
I’ve managed to boot into the Live Suse rescue disk. From there I can decrypt and mount the hard disk, so I don’t the partition is damaged. Is there a way for me to roll back the system from the rescue disk? I can’t seem to find a guide that covers this. Is there any other information I should include that could be helpful?
First thing to try is to disable secure boot in BIOS setup. Do you still observe the same issue?
When was the last update before this one? Because there was grub2 update recently and if you see the same issue with different kernel versions, next suspect is bootloader. So reverting to one of previous versions makes sense as the next test.
The old kernel should be “4.12.14-lp151.28.48-default”.
I have tried choosing the previous kernel from grub, but get the same hang.
Did you really try the previous kernel – the one with “.48” as its version?
There’s a bug report for the latest kernel Bug 1172886
It shows a kernel panic during boot. That would give the symptoms that you describe. But the previous kernel should work. So maybe that again, and use the kernel version ending in “.48”.
If that works, consider adding yourself to the bug report (just add a comment that you are having the same problem).
There’s also a suggestion in that bug report that it could be the ucode-intel causing the problem, and in that case you could also have a problem with the older kernel. The bug report indicates how to test for that.
The old kernel is indeed “4.12.14-lp151.28.48-default”. I mistyped,sorry.
Arvidjaar, turning off UEFI sadly did not help.
However, booting “*.48” with the boot option that is supposed to sidestep the ucode-intel problem did! Thank you very much, Nrickert. Well thank you both actually.
I’ll put my name on the bug report you linked to. Booting *.48 without the specifal boot option (unsurprisingly) still does not work.
So how do I proceed from here? Do I blacklist the *.52 kernel in Yast and update my grub config so that it always adds the new boot option to the *.48 kernel and hope for a bug fix?
One choice would be to boot to an older snapshot with “btrfs”. And then rollback to that snapshot. However, I think it is easier to just revert to the earlier version of ucode-intel.
Boot to the kernel that works with the boot option that works. Then use Yast Software Management.
Search for “ucode-intel”.
Click the “Versions” tab. That should show you the versions that are in the repos. Then select the earlier version. It looks as if that is “20191115-lp151.2.21.1”. Click “Accept” to install that version.
Then reboot. Again, go with the kernel that works. But you should not need to do anything else at this point.
If that works well, then go back into Yast Software Manager, again find “ucode-intel” and lock it. Right click and mark as “Protected - Do Not Modify”. That will prevent it from being automatically updated.
Then report this on that bug report. They might want you to attach the output from “hwinfo” (run as root).