Bugzilla – Bug 1215826
kernel-default-6.5.4 won't boot; can't activate swap
Last modified: 2023-10-04 07:50:29 UTC
Created attachment 869836 [details] Output of hwinfo (with 6.4.12) I upgraded from Tumbleweed 20230908 to 20230921, which included an upgrade from kernel-default-6.4.12 to kernel-default-6.5.4. The new kernel has problems booting or resuming from suspend. In particular, when booting, about half the time the kernel is unable to activate the swap device. The last message printed to the console is "a start job is running for /dev/sda2" (the device in question being my swap partition) and a timer that counts up. I've let it run for as long as 10 hours but it never finishes. Resuming from suspend also doesn't work. In this case the computer simply locks up or powers off. (I haven't tested hibernate.) I had a similar problem (only with resuming from suspend, not with activating swap space) with kernel-default-5.19.1; not sure if this is related. See Bug 1202571. Downgrading to the 6.4.12 kernel works around the issue. I am attaching the output of hwinfo (using the 6.4.12 kernel).
Something to try: Remove resume=/dev/sda2 from /etc/default/grub and /boot/grub2/grub.cfg entirely, or replacing it with resume=UUID=<swapUUID> or resume=LABEL=<swapLABEL> (using the actual UUID or LABEL from lsblk -f or blkid). To test whether this is the right track, strike the E key at the Grub menu and change resume=/dev/sda2 to noresume before proceeding with boot. Noresume means what it spells, but it should boot straight away if I'm right.
(In reply to Felix Miata from comment #1) > Something to try: Remove resume=/dev/sda2 from /etc/default/grub and > /boot/grub2/grub.cfg entirely, or replacing it with resume=UUID=<swapUUID> > or resume=LABEL=<swapLABEL> (using the actual UUID or LABEL from lsblk -f or > blkid). To test whether this is the right track, strike the E key at the > Grub menu and change resume=/dev/sda2 to noresume before proceeding with > boot. Noresume means what it spells, but it should boot straight away if I'm > right. Yes, using noresume or resume=UUID=<swapUUID> seems to solve the problem. I noticed when looking up the UUID of the swap device that it was always /dev/sdb2 when booting from the 6.4.12 kernel, whereas when booting from the 6.5.4 kernel it was sometimes /dev/sda2 and sometimes /dev/sdb2. So I think the real problem here is that the 6.5.4 kernel doesn't assign device names in the same consistent manner than 6.4.12 did, so you can't rely on these names in the bootloader. I think that nowadays a fresh install of Tumbleweed will always use the device's UUID, but my system was first installed back in 2014 and so was still using the old /dev/sdXY-style identifiers.
(In reply to Tristan Miller from comment #2) > I noticed when looking up the UUID of the swap device that it was always > /dev/sdb2 when booting from the 6.4.12 kernel, whereas when booting from the > 6.5.4 kernel it was sometimes /dev/sda2 and sometimes /dev/sdb2. So I think > the real problem here is that the 6.5.4 kernel doesn't assign device names > in the same consistent manner than 6.4.12 did, so you can't rely on these > names in the bootloader. This has been an on-again off-again problem for decades, and one of the reasons for the long ago switch to using using more reliable descriptors than kernel names. > I think that nowadays a fresh install of Tumbleweed will always use the > device's UUID, but my system was first installed back in 2014 and so was > still using the old /dev/sdXY-style identifiers. Back around 10.3 or 11.0 a switch from kernel device names to /dev/disk/by-id/* was made. I think the switch from those to UUIDs by default was made in 13.2, which Tumbleweed inherited, or possibly the other way around, when instead of a 13.3 we got Leap and the initial Tumbleweed. My own installations have long been using primarily LABEL=, IIRC since my initial use of SUSE, 8.0. Note that resume= is an /option/ on Grub's linu lines. It overrides the resume= that initrds include by default in openSUSE.
Simply changing the resume option in Grub has not completely solved this problem: with the new kernel, my computer still can't resume from suspend in certain situations. I'm not sure how related that problem is so I've raised it as a new issue: Bug 1215927