Unable to boot with 5.8 kernels

English Install/Boot/Login
1

Dear community,

I cannot boot with the 5.8 kernels in Tumbleweed while the 5.7 kernels work fine. I’m currently still running 5.7.12 - which I originally stuck to because of the VirtualBox issues. The below output is all with the latest kernel version 5.8.7 in TW.

The text displayed is:


  OK  ] Started Show Plymouth Boot Screen.
  OK  ] Started Forward Password Requests to Plymouth Directory Watch.
  OK  ] Reached target Paths.

Then it enters the emergency mode.

I found no functionality to upload files here, so I pasted the rdsosreport here: https://paste.ubuntuusers.de/raw/423976/
And this is the journal of the boot (journalctl -b): https://paste.ubuntuusers.de/raw/423977/

Has anyone an idea what is going wrong?

Thank you in advance

2

For future reference, you can upload to “susepaste.org”.

I suggest that you file a bug report on this.

https://en.opensuse.org/openSUSE:Submitting_bug_reports

3

Thanks for your suggestion. I opened https://bugzilla.opensuse.org/show_bug.cgi?id=1176465 after I found no similar bugs.

As I was unsure if this may be an error on user-side or is already known, I opted to ask for help here first.

4

It looks to me as if it is a kernel problem.

Yes, asking here before you post a bug report is usually a good practice.

I think I have seen another bug report where the user is not prompted for LUKS key on newer kernels. I haven’t been following that bug report, but I think it was related to the use of an NVME drive, and apparently the newer kernel treats that differently. I don’t know whether that is your situation.

5

Yes, I use both NVMe and LUKS. Maybe it was 1175271 – latest kernel installation's initrd results in booting into emergency shell - dracut-initqueue timeout - starting timeout scripts ? That one has been closed as resolved in mid of August.

6

Yes, that was probably the one that I remembered. And I now see that was for a 5.7 kernel.

It seems that how to manage NVME devices is evolving, and leading to issues such as the one that you are having.

In my experience, the kernel maintainers are pretty good at investigating these problems. So be patient. And continue to use the 5.7 kernel until it is resolved.

If you have not already done so, then edit “/etc/zypp/zypp.conf”. Look for the line:

multiversion.kernels = latest,latest-1,running

and change it to

multiversion.kernels = oldest,latest,latest-1,running

That’s to make sure that the 5.7 kernel does not get removed. You can change it back when everything is working again.

7

Hi
FWIW I use an nvme device, no encryption though, I do boot from a SSD since I don’t have nvme boot support on this motherboard. Zero boot issues since the nvme was added, I did have to add nvme_core.default_ps_max_latency_us=0 to my boot options else it would freeze on boot. I suggest disable plymouth from grub with plymouth.enable=0 added to the linuxefi boot line and see if that helps. For this single boot system, I don’t even see grub and plymouth is gone from the system…

8

Thanks for your kind reply.

Thanks! When I discovered the problem initially I added a lock in zypper on the kernel packages I want to keep and disabled the purge-kernels service. I guess this also works as the old kernels haven’t been removed since then (and there were quite a few new kernel releases in the mean time).

9

Hi,

Thanks for your suggestions. I will add the kernel options the next time I boot!

10

You did not provide any details except “it does not boot”, so how can you find similarities?

How do you expect anyone reading your bug report to know it?

At the very least provide “journalctl -b” after booting with working kernel to show your system configuration.

11

I tried both options (together and separately) but it made not difference unfortunately. Thanks for the suggestion though.

By comparing the reported problem - at which stage the boot process stopped and the kernel version (which is roughly equivalent to date of bug creation).

The logs contain much more details than I am able to provide and even identify as relevant.

Thanks for the suggestion: SUSE Paste

I further saw some output on the screen today (before the emergency mode starts and after the dracut-initqueue messages) which is apparently not part of the logs:

Warning: /dev/disk/by-uuid/1d371b45-a81f-4250-a182-2813b56ed85c does not exist
Warning: /dev/disk/by-uuid/DB08-0F00 does not exist
Warning: crypto LUKS UUID 0a77e4b4-ecfe-495f-b66b-2554bcd320f8 not found
Warning: crypto LUKS UUID 767692ec-d630-4b20-8377-01f5605076bf not found

This is my /etc/crypttab:

cr_root  UUID=767692ec-d630-4b20-8377-01f5605076bf
cr_swap  UUID=0a77e4b4-ecfe-495f-b66b-2554bcd320f8

So it doesn’t find by disk at all (from which the kernel is already loaded?)