Using noresume on the kernel command line ?

English Install/Boot/Login
1

OK… What have I missed and/or failed to do?

I’ve removed the “resume=‘UUID’” from the kernel command line and replaced it with “noresume”, (using YaST2 -> Boot Loader).

“/boot/grub2/grub.cfg” has been recreated and the kernel command line is correct there.

After reboot, out of curiosity I looked through the journal for “resume”


paul@Orion-15:~$ sudo journalctl -b | grep -i resume
[sudo] password for root: 
Apr 25 12:02:21 Orion-15 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=ea5c2b1b-ac33-497d-b286-2c06a23623a2 noresume libata.force=noncq showopts
Apr 25 12:02:21 Orion-15 kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=ea5c2b1b-ac33-497d-b286-2c06a23623a2 noresume libata.force=noncq showopts
Apr 25 12:02:21 Orion-15 systemd-hibernate-resume-generator[177]: Found "noresume" on the kernel command line, quitting.
Apr 25 12:02:21 Orion-15 dracut-cmdline[229]: Using kernel command line parameters: resume=UUID=8595c8af-adce-47f8-b9e4-9f46348154ac root=UUID=ea5c2b1b-ac33-497d-b286-2c06a23623a2 rootfstype=ext4 rootflags=rw,noatime BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=ea5c2b1b-ac33-497d-b286-2c06a23623a2 noresume libata.force=noncq showopts
Apr 25 12:02:24 Orion-15 systemd-hibernate-resume-generator[372]: Found "noresume" on the kernel command line, quitting.
paul@Orion-15:~$

All appears OK except for the rather strange line which commences “dracut-cmdline[229]: Using kernel command line parameters:” which (still) contains the original “resume=‘UUID’” at the start of the line.

I later noticed, following a “zypper dup” that when mkinitrd runs that also still has the “resume=‘UUID’”. Relevant fragment of “/var/log/YaST2/mkinitrd.log”


I: *** Store current command line parameters ***
I: Stored kernel commandline:
I:  resume=UUID=8595c8af-adce-47f8-b9e4-9f46348154ac
I:  root=UUID=ea5c2b1b-ac33-497d-b286-2c06a23623a2 rootfstype=ext4 rootflags=rw,noatime
I: *** Creating image file '/boot/initrd-5.0.8-1-default' ***
I: *** Creating initramfs image file '/boot/initrd-5.0.8-1-default' done ***

So… Any ideas where this “resume=UUID=8595c8af-adce-47f8-b9e4-9f46348154ac” is still lingering, or being picked up from ? … :\

2

maybe mkinitrd

3

When mkinitrd runs that indicates that it has:

I: Stored kernel commandline:
I:  resume=UUID=8595c8af-adce-47f8-b9e4-9f46348154ac

as shown in the slightly longer fragment I posted, although that wasn’t as a result of me explicitly running mkinitrd.

Running mkinitrd again gives the same output.

I don’t know where that’s getting the resume=UUID from…

4

That seems to be coming from the running system.

I tried:


swapoff -a
mkinitrd

and it looks as if the “resume” line is no longer getting into the “initrd”.

5

Yes… that does appear to be the case.

The journal for a boot after

swapoff -a
mkinitrd

now show this

paul@Orion-15:~$ sudo journalctl -b | grep -i resume
[sudo] password for root: 
Apr 25 17:45:48 Orion-15 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=ea5c2b1b-ac33-497d-b286-2c06a23623a2 noresume libata.force=noncq showopts
Apr 25 17:45:48 Orion-15 kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=ea5c2b1b-ac33-497d-b286-2c06a23623a2 noresume libata.force=noncq showopts
Apr 25 17:45:48 Orion-15 dracut-cmdline[227]: Using kernel command line parameters: root=UUID=ea5c2b1b-ac33-497d-b286-2c06a23623a2 rootfstype=ext4 rootflags=rw,noatime BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=ea5c2b1b-ac33-497d-b286-2c06a23623a2 noresume libata.force=noncq showopts
paul@Orion-15:~$

Not sure if that’s a bug or a feature…

Either way it doesn’t really seem to matter, even when there is a resume=UUID the noresume takes precedence.

Background:
This machine never has played nicely when it resumes, black screen and unusable. I’ve already removed the hibernate/suspend options from KDE by adding a polkit rule

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.login1.suspend" ||
        action.id == "org.freedesktop.login1.suspend-multiple-sessions" ||
        action.id == "org.freedesktop.login1.hibernate" ||
        action.id == "org.freedesktop.login1.hibernate-multiple-sessions")
    {
        return polkit.Result.NO;
    }
});

but thought I’d make a “complete” job of it by adding the noresume option…

6

Running “dracut --force” helps here:

linux:~ # grep root=UUID /boot/grub2/grub.cfg
        linux   /boot/vmlinuz-5.0.8-1-default root=UUID=526e2128-0a16-4246-b08f-91160007fc26  splash=silent quiet showopts
                linux   /boot/vmlinuz-5.0.8-1-default root=UUID=526e2128-0a16-4246-b08f-91160007fc26  splash=silent quiet showopts
                linux   /boot/vmlinuz-5.0.8-1-default root=UUID=526e2128-0a16-4246-b08f-91160007fc26  
                linux   /boot/vmlinuz-5.0.7-1-default root=UUID=526e2128-0a16-4246-b08f-91160007fc26  splash=silent quiet showopts
                linux   /boot/vmlinuz-5.0.7-1-default root=UUID=526e2128-0a16-4246-b08f-91160007fc26  
...
linux:~ # 

linux:~ # journalctl -b|grep root=
Apr 26 08:33:41 linux kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=526e2128-0a16-4246-b08f-91160007fc26 splash=silent quiet showopts
Apr 26 08:33:41 linux kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=526e2128-0a16-4246-b08f-91160007fc26 splash=silent quiet showopts
Apr 26 08:33:41 linux dracut-cmdline[248]: Using kernel command line parameters: root=UUID=526e2128-0a16-4246-b08f-91160007fc26 rootfstype=ext4 rootflags=rw,relatime BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=526e2128-0a16-4246-b08f-91160007fc26 splash=silent quiet showopts
linux:~ #

It helped also when converting to UEFI: Frühjahrsputz | Karl Mistelberger

7

?? But that’s passed to dracut anyway when it’s invoked by mkinitrd … from the log file:

Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-5.0.8-1-default 5.0.8-1-default

The “problem” was "resume=UUID= … " was being included even though the kernel command line had an explicit “noresume”

But as I wrote earlier, the noresume takes precedence.

8

I changed the command line options using YaST2 bootloader from:

GRUB_CMDLINE_LINUX_DEFAULT=“splash=silent quiet showopts resume=/dev/disk/by-uuid/17795bce-b153-47bf-b60c-2a6d431553e7” to
GRUB_CMDLINE_LINUX_DEFAULT=“splash=silent quiet showopts”
.
Changes from journal dracut-cmdline were from:

root=UUID=526e2128-0a16-4246-b08f-91160007fc26 rootfstype=ext4 rootflags=rw,relatime BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=526e2128-0a16-4246-b08f-91160007fc26 splash=silent quiet showopts resume=/dev/disk/by-uuid/f6e38c6d-9ca2-4827-95af-c562916958d4f

to:

resume=UUID=f6e38c6d-9ca2-4827-95af-c562916958d4 root=UUID=526e2128-0a16-4246-b08f-91160007fc26 rootfstype=ext4 rootflags=rw,relatime BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=526e2128-0a16-4246-b08f-91160007fc26 splash=silent quiet showopts

Running dracut --force again without changing anything and booting again changed the above to:

root=UUID=526e2128-0a16-4246-b08f-91160007fc26 rootfstype=ext4 rootflags=rw,relatime BOOT_IMAGE=/boot/vmlinuz-5.0.8-1-default root=UUID=526e2128-0a16-4246-b08f-91160007fc26 splash=silent quiet showopts

Running dracut twice works better.:wink: This is quite puzzling.

9

Indeed :\

I’m quite happy to rely upon “noresume” on the kernel command line, I don’t really want to keep regenerating the initramfs image.

10

I agree with that. But better still would be to prevent hibernation from happening, rather than prevent resuming.

I currently have Tumbleweed in two different VMs. And they are similar, as far as I can tell.

In the first image, I always get a hibernate option on shutdown (from KDE), unless I do a “swapoff -a” first.

In the second image, I never get a hibernate option on shutdown from KDE (X11), but I do get that option if I shutdown from KDE (Wayland). And I’ve tried with a new user account, and that works the same way. I suppose that there’s a reason for the difference between the systems, but I have no idea what that is.

Note, however, that I’m not seriously concerned about it. Rather, it is more of a curiosity.

11

Yes, I had already gone some way towards that by creating a polkit rule to disable hibernate/suspend options from appearing on the KDE desktop. (See post #5), and by appropriate setting of the power management options in (KDE’s) setup.

However, I never underestimate the ingenuity of my partner, if she’s able to accidentally find a way to hibernate/suspend, then she will! rotfl! …