[PATCH] Allow resume from swap device during boot

Dear GUIX maintainers,

Current the GUIX SD boot process does not allow resuming from sleep,

even thought sleep options are available through loginctl, eg:

loginctl hybrid-sleep

loginctl hibernate

This is a very important feature for people like me using GUIX SD on a

laptop (yes, it is possible, mine is a corebooted X230 running

linux-libre!)

This patch is based on a patch floating around. The core functionality

has been isolated, the resume function isolated, the patch rebased and

tested. I'm not taking credit for it, even though tracing the exact

origin is hard.

The resume hook is called if the resume= kernel argument is provided,

which one can do during system configuration.

My scheme level is zero, so please bear with me. In particular, some

conditionals could maybe be moved within the function, or the function

itself called within some already-available hooks. Also it is not clear

if the commit log is adequate for such a change.

Please let me know how to improve this and get this merged; I can also

write some documentation (probably once the mechanism is in place) to

explain how the feature can be used.

Kind regards,

Jean-Baptiste

Hi Jean-Baptiste Note,

On Tue, 28 Apr 2020 07:26:15 +0000

Jean-Baptiste Note <jean-baptiste.note@m4x.org> wrote:

Should be linux-libre/Documentation/power/swsusp.txt .

Otherwise OK.

Please try to find the names of the actual authors so we can commit the parts

they wrote with them as author.

Who provides the "resume=" argument eventually?

Also, if we want to support this, what would the Guix installer have to do?

Add a swap partition? Does it have to be exactly as big as the amount of RAM

or does it need to be bigger because of overhead?

Jean-Baptiste,

Jean-Baptiste Note ???

Greetings, brother in hardware.

Note that hibernation and resumption already work fine if you rely

on the kernel's built-in support. I've been hibernating my X230T

for years without patches.

This explicit initramfs support is only needed if your storage

drivers aren't available when the kernel itself tries to resume,

and the initramfs has to retry later. That's slower but allows

things like ahci to be modular instead of built-in.

Heh. It's certainly very similar to a patch of mine that's ‘out

there’ although it's probably not the only one.

This patch ignores the ‘noresume’ flag, which is bad. If it's

present anywhere on the command line resumption should be skipped:

+ (when (and (not (member "noresume" args))

+ resume-device

+ (file-exists? resume-device)

+ (file-exists? "/sys/power/resume"))

+ (resume-from-device resume-device))

I'd like to see everything moved into a self-contained DTRT

[try-to-]resume procedure, except for the ‘noresume’ check (so

callers are free to explicitly resume if they so please):

+ (unless (member "noresume" args)

+ (resume-if-hibernated (find-long-option "resume"

args)))

This is what the last iteration of my patch does.

If (find-long-option "resume" args) is #f, fall back to

CONFIG_PM_STD_PARTITION. This is what the kernel does: even if

‘resume=’ is missing, it will try to resume from that device if

specified. We should match that behaviour if we can.

Problem is, I forgot how to get that value from user space, or if

it's even possible. I gave up on Linux's built-in hibernation

(swsusp) years ago. It's poorly written and maintained, and the

author fiercely defends it from all improvement.

Instead I use TuxOnIce, which exposes it under

/sys/power/tuxonice/…. That's obviously not an option here,

although it would be friendly to fall back to it for us ToI users

:-)

*user.

I think ToI even exposes the ‘last used hibernation device’

somewhere, so user space can just use that instead of

CONFIG_PM_STD_PARTITION. This is obviously the right thing to do.

Again, not sure if swsusp does.

We don't have a concept of ‘initramfs hooks’ and I think that's a

good thing. Gives me dracut flashbacks. Don't lets bother with

them until we need them, which is never.

It's all right :-) If anything, it's too long:

linux-boot: Add support for resuming from swap device.

* gnu/build/linux-boot.scm (resume-from-device): New procedure.

* gnu/build/linux-boot.scm (boot-system): Call it, unless

‘noresume’

is present on the kernel command line.

If this works properly no documentation is needed. The kernel by

default writes to the first swap device; we should magically

resume from it. Forcing users to know (or care) about part 2 is

asymmetrical and wrong.

Not sure if that's possible with vanilla Linux-Libre…

Will stop shilling ToI for now,

T G-R

Hullo again,

Tobias Geerinckx-Rice ???

I managed to find it! Long live dusty back-ups.

It uses native procedures to divine the device number, instead of

— clever! — /sys/blockery that supports only a subset of specs

(and reminds me too much of ‘look what I found lying around’ shell

scripting). If any are missing we can add them to

CANONICALIZE-DEVICE-SPEC to the benefit of all.

Tested with both built-in & modular ATA drivers × mainline swsusp

& TuxOnIce. More welcome.

These copyright dates are downright embarrassing. Let's Get

(something like) This Merged!

Kind regards,

T G-R

Hi Danny,

Thanks for being so guix in answering the original report.

Your questions prompted me to take a bit of time before answering.

Regarding attribution, i've dug two instances of this patch:

Both instances of the patch are given by author Mark H Weaver <mhw@netris.org>

As you can see there's already an open issue in GUIX regarding resume;

i'm sorry i missed that. Maybe for attribution it would make sense for

me to resend the patch there; let me know how to proceed.

Regarding the patch itself and your questions:

- for comparison to the original patch: elogind currently has the

configurability required to make the second half of the original

patch moot, and I think it would be better to split the work

anyways;

- i've addressed the reference to swsusp.txt

- the resume argument is provided by (in my case) the system

definition, so I basically have something like that:

#+begin_src scheme

(operating-system

(kernel-arguments

(cons

(string-append "modprobe.blacklist="

(comma-separated

%redundant-linux-modules))

'("--resume=/dev/sdb3" "quiet"))))

#end_src

- in order to support this in the GUIX installer, I guess adding such

a line in the generated system definition, along with a swap

partition, would be sufficient. My knowledge of the workings of the

guix installer is null, tough :)

- please note that if you have a suspend signature on your swap

partition, and fail to resume from it (for instance because of a

missing kernel commandline argument...), then shepherd will fail

bringing up the swap device, and you will need to handle this

situation by hand currently;

- My knowledge of the details of swsusp is rather limited: I don't

know, for instance, how this would translate in case of a more

complex setup of multi-swap devices;

- However, it seems very clear from the documentation that a mere

resume= argument syntax can trigger specific initialization paths

within the kernel itself leading to a resume. I find it better

style, ultimately, to properly separate the responsibilities of

kernel and initrd, follow the GUIX conventions with a --resume

argument.

- therefore I propose the following, updated patch, with a more

GUIX-like --resume argument; I've tested it on my laptop, which

happens to have an encrypted /home partition (but only one swap

device).

- as far as I can understand the documentation, the swap partition

does not have to be as big as the RAM; by default the kernel will

strive to make the suspend image 2/5 of the physical RAM, but this

can be tuned more aggressively. There's actually less than overhead:

some parts of the memory can be discarded (shared MMAPd files, the

buffer cache); and even then you can hope compression will reduce

the needs. If the swap space is not large enough, suspend will

simply fail.

This probably raises more issues than it solves, however i'd rather you

have the whole picture. Let me know how to proceed; I'm willing to

follow-up with other patches to get the feature up to the required

standards of quality.

Kind regards,

Jean-Baptiste

Hi there,

As i'm not subscribed to the list, I completely missed on Tobias'

messages -- and my previous one must seem strange in hindsight. Sorry

about this.

I'm now subscribed, but still can't reply directly to his email.

Though I still won't be able to answer directly to Tobias' latest email,

I will test the patch, and /somehow/ report back on Thursday.

For now I must say that on my kernel -- official guix linux-libre-5.4 --

the built-in support does not seem to be working (I'm pretty sure i've

tested this); I will double-check however.

Kind regards,

Jean-Baptiste

Dear Tobias,

I hopefully found a way to reply to your message directly. I've checked

resume with your patch -- actually a slightly reworked version of it; a

few remarks:

- I've amended it as per Danny's suggestions regarding documentation location

- I've adjusted it to take the guixy --resume and --noresume options

rather than the kernel norm resume and noresume. In particular this

allows me to test the 'kernel' resume path and the 'initrd' resume

path with the same os definition quickly, only adjusting the GRUB

cmdline within GRUB.

- I find the added copyright years on top strange -- shouldn't it be

2020 ?

The results of my tests are attached as a separate file. In a nutshell:

- I can confirm that on my kernel (default guix linux-libre-5.4) the

resume= option by itself does not resume at all. This seems to have been

reported already:

https://lists.gnu.org/archive/html/bug-guix/2016-11/msg00060.html

- resume-by-uuid from userspace does not work

- resume-by-label from userspace does not work either

(as much as I'd like them to).

(please note that, on top of this, I found no way to specify the swap

devices in the os definition by UUID or LABEL either -- so the

limitation does not bother me in the current state).

Each time these loop for 20 seconds, waiting for the partition to appear

(the partition is there, from dmesg, but somehow is not in the database

looked for in (canonicalize-device-spec spec) -- weird).

Regarding the interface, I'm not sure we should feel bound by the

argument naming convention of the kernel for resume handling from

userspace -- we could leave its own namespace for the kernel to handle,

for those kernels that can, and separate the resume handling as done by

initrd in a separate, more guixy namespace.

Actually I don't really understand why we would want overlapping of

names for two different codepaths; I think separating the names brings

more flexibility (you can control from the GRUB commandline which resume

path you want to take) and less confusion (it is clearer from the

commandline where the resuming will/should be handled).

To summarize:

with the current software stack, but the default kernel won't resume,

leaving the system in a bad state (swap is not activated by shepherd,

see logs), and we need manual swapon to leave this bad state;

while it can't -- for reasons that i've not dug;

pointless, given the limited ways we have to specify swap devices in

the OS definition file.

I'd be in favor of doing the following:

clearly in some comment that the path is currently non-functional;

currently after a suspend.

ones

Please let me know how to proceed, and let me know how to handle the

copyright notice.

Kind regards,

Jean-Baptiste

# by device node -- does work

jb@guixrules ~$ sudo loginctl hibernate

jb@guixrules ~$ cat /proc/cmdline

BOOT_IMAGE=/gnu/store/bkpkbms3mp8s45kpir4f2cnvxvgdvssp-linux-libre-5.4.39/bzImage --root=ed73cc09-aff3-41e4-90b6-51fb41a7d225 --system=/gnu/store/xcdn9naivwxhr4x0cq669zzn9f02x706-system --load=/gnu/store/xcdn9naivwxhr4x0cq669zzn9f02x706-system/boot modprobe.blacklist=pcspkr,snd_pcsp --resume=/dev/sda3 quiet

# by UUID -- does not work

jb@guixrules ~$ sudo swaplabel /dev/sdb3

swaplabel: /dev/sdb3: not a valid swap partition

jb@guixrules ~$ sudo swapon /dev/sdb3

swapon: /dev/sdb3: software suspend data detected. Rewriting the swap signature.

jb@guixrules ~$ sudo swaplabel /dev/sdb3

LABEL: resume_device

UUID: 446c81d4-efcf-4508-a9ab-bb38f74ff77d

jb@guixrules ~$ cat /proc/cmdline

BOOT_IMAGE=/gnu/store/bkpkbms3mp8s45kpir4f2cnvxvgdvssp-linux-libre-5.4.39/bzImage --root=ed73cc09-aff3-41e4-90b6-51fb41a7d225 --system=/gnu/store/xcdn9naivwxhr4x0cq669zzn9f02x706-system --load=/gnu/store/xcdn9naivwxhr4x0cq669zzn9f02x706-system/boot modprobe.blacklist=pcspkr,snd_pcsp --resume=446c81d4-efcf-4508-a9ab-bb38f74ff77d quiet

jb@guixrules ~$ diff <(echo 446c81d4-efcf-4508-a9ab-bb38f74ff77d) <(echo 446c81d4-efcf-4508-a9ab-bb38f74ff77d)

jb@guixrules ~$ echo $?

0

# by LABEL -- does not work

jb@guixrules ~$ sudo swaplabel /dev/sdb3

swaplabel: /dev/sdb3: not a valid swap partition

jb@guixrules ~$ sudo swapon /dev/sdb3

swapon: /dev/sdb3: software suspend data detected. Rewriting the swap signature.

jb@guixrules ~$ sudo swaplabel

swaplabel: no device specified

Try 'swaplabel --help' for more information.

jb@guixrules ~$ sudo swaplabel /dev/sdb3

LABEL: resume_device

UUID: 446c81d4-efcf-4508-a9ab-bb38f74ff77d

jb@guixrules ~$ cat /proc/cmdline

BOOT_IMAGE=/gnu/store/bkpkbms3mp8s45kpir4f2cnvxvgdvssp-linux-libre-5.4.39/bzImage --root=ed73cc09-aff3-41e4-90b6-51fb41a7d225 --system=/gnu/store/xcdn9naivwxhr4x0cq669zzn9f02x706-system --load=/gnu/store/xcdn9naivwxhr4x0cq669zzn9f02x706-system/boot modprobe.blacklist=pcspkr,snd_pcsp --resume=resume_device quiet

# leaving it to the kernel -- does not work

jb@guixrules ~$ sudo swaplabel /dev/sdb3

swaplabel: /dev/sdb3: not a valid swap partition

jb@guixrules ~$ sudo swapon /dev/sdb3

swapon: /dev/sdb3: software suspend data detected. Rewriting the swap signature.

jb@guixrules ~$ cat /proc/cmdline

BOOT_IMAGE=/gnu/store/bkpkbms3mp8s45kpir4f2cnvxvgdvssp-linux-libre-5.4.39/bzImage --root=ed73cc09-aff3-41e4-90b6-51fb41a7d225 --system=/gnu/store/xcdn9naivwxhr4x0cq669zzn9f02x706-system --load=/gnu/store/xcdn9naivwxhr4x0cq669zzn9f02x706-system/boot modprobe.blacklist=pcspkr,snd_pcsp resume=/dev/sdb3 quiet

Hibernation has been supported on Guix Systems for a very long

time now.

I'm not aware of any, but any failures to hibernate are probably

configuration or hardware-specific and should be reported as new

bugs.

Kind regards,

T G-R