Status of hibernation (suspend to disk) in Guix

Status of hibernation (suspend to disk) in Guix

[Ivan Vilata i Balaguer]

[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]

(I'm not subscribed to the list, please CC me in replies.  Thanks!)

Hi everyone!  As I had promised to myself and some guixers at Capitole du
Libre (salut les collègues !), I finally installed the Guix System in my
laptop (already time after 6+ years of using Guix packages!).  Although my
setup is still in need of some ironing, I was very impressed to see that most
things worked within just a few days of tweaking…  Everyone has done such a
great work! `:)`

In particular, I was very happy to see that hibernation was (nearly) working!
It was sure writing system state to swap then powering off, but then on boot
it routinely ignored the saved state and started a new OS run.  I didn't find
how to fix that in the docs, but by delving into `gnu/build/linux-boot.scm` I
found that I just had to set the kernel argument `resume=<SWAP-SPACE>`, then
resuming worked like a charm. `:)`

In <https://issues.guix.gnu.org/59746> I propose some documentation on how to
set the `resume` kernel argument for hibernation (under the Swap Space
section), so that people is at least able to find some useful indications if
they search for "hibernation" or "suspend to disk".

But then I wonder if I may have rushed to post the patch, as I don't know
whether hibernation is supposed to be more or less mature or supported in Guix
(we may not want to encourage people to use a feature which may easily cause
data loss)…  Though it works quite well for me!

(To be honest, I didn't yet test creating a new system generation with a new
kernel, hibernating, and trying to boot the new kernel.)

Also, since I installed the system manually from a custom `config.scm`, I'm
not sure whether this works out of the box with an installer-made setup, but
my impression was that such an installation on a VM didn't even create a swap
space.  Though installer support may be a whole different discussion. `:P`

So the TL;DR would be: Is it worth adding such documentation, given the
current state of hibernation support in Guix?

Thanks!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Status of hibernation (suspend to disk) in Guix

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

Ivan Vilata i Balaguer 写道：
> But then I wonder if I may have rushed to post the patch, as I 
> don't know
> whether hibernation is supposed to be more or less mature or 
> supported in Guix
> (we may not want to encourage people to use a feature which may 
> easily cause
> data loss)…  Though it works quite well for me!

OTOH, I deliberately hadn't documented ‘resume=’ so far.

OTOH, I have been hibernating multiple times a day for years now, 
only ever rebooting my laptop for kernel updates.

So the feature is probably safe, and we should probably consider 
it supported at this point.  Thanks for bringing it up!

> So the TL;DR would be: Is it worth adding such documentation, 
> given the
> current state of hibernation support in Guix?

I think documenting the current status quo in time for 1.4.0 is a 
good idea.

The next step is to automate things so ‘resume=’ becomes optional. 
This should have landed already, but hasn't for personal reasons. 
The code is basically ready, but won't be in the release.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Status of hibernation (suspend to disk) in Guix

[Ivan Vilata i Balaguer]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

Thanks for the update, Tobias!  More inline…

Tobias Geerinckx-Rice (2022-12-02 21:32:09 +0100) wrote:

> Ivan Vilata i Balaguer 写道：
> > So the TL;DR would be: Is it worth adding such documentation, given the
> > current state of hibernation support in Guix?
> 
> I think documenting the current status quo in time for 1.4.0 is a good idea.
> 
> The next step is to automate things so ‘resume=’ becomes optional. This
> should have landed already, but hasn't for personal reasons. The code is
> basically ready, but won't be in the release.

Regarding that, and in case it's useful for post-release work: in #59746 I
skipped documenting `resume_offset` with more detail, even if it's needed for
resuming from a swap file.  The reason is that according to [swsusp doc][1],
some specific tool may be needed to compute the swap file offset.  There is
[swap-offset][2] from the uswsusp suite, which is missing from Guix and no
longer shipped with Debian.  I guess that rewriting that small logic in Scheme
wouldn't be too difficult.

[1]: https://www.kernel.org/doc/html/latest/power/swsusp.html
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-utils.git/tree/swap-offset.c

Cheers,

-- 
Ivan Vilata i Balaguer -- https://elvil.net/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Status of hibernation (suspend to disk) in Guix

[Mekeor Melire]

2022-12-05 17:23 ivan@selidor.net:

> in #59746 I skipped documenting `resume_offset` with more detail, even
> if it's needed for resuming from a swap file. The reason is that
> according to [swsusp doc][1], some specific tool may be needed to
> compute the swap file offset. There is [swap-offset][2] from the
> uswsusp suite, which is missing from Guix and no longer shipped with
> Debian.

What about the "filefrag" executable from the "e2fsprogs" package.
According to this article, it can be used in place of the deprecated
uswsusp suite:

https://www.linuxuprising.com/2021/08/how-to-enable-hibernation-on-ubuntu.html

Re: Status of hibernation (suspend to disk) in Guix

[Mekeor Melire]

2022-12-09 23:10 mekeor@posteo.de:

> 2022-12-05 17:23 ivan@selidor.net:
>
> > in #59746 I skipped documenting `resume_offset` with more detail, even
> > if it's needed for resuming from a swap file. The reason is that
> > according to [swsusp doc][1], some specific tool may be needed to
> > compute the swap file offset. There is [swap-offset][2] from the
> > uswsusp suite, which is missing from Guix and no longer shipped with
> > Debian.
>
> What about the "filefrag" executable from the "e2fsprogs" package.
> According to this article, it can be used in place of the deprecated
> uswsusp suite:
>
> https://www.linuxuprising.com/2021/08/how-to-enable-hibernation-on-ubuntu.html

I just tried this out. And it worked like a charm! I have hibernated and
resumed successfully - first time with Guix System. I'm so happy :)

Would you like to add instructions for swap-files to your
patch-series #59746?

What I did: First, determine offset:

--8<---------------cut here---------------start------------->8---
$ sudo filefrag -v /swapfile
Filesystem type is: ef53
File size of /swapfile is 1717986918 (4194304 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       0:    5308416..   5308416:      1:
--8<---------------cut here---------------end--------------->8---

Then, use offset in operating-system declaration:

--8<---------------cut here---------------start------------->8---
  (kernel-arguments
    (cons*
      "resume=/dev/mapper/cryptroot"
      "resume_offset=5308416"
      %default-kernel-arguments))
--8<---------------cut here---------------end--------------->8---

Caveat: IIUC, this does not work with Btrfs.

Re: Status of hibernation (suspend to disk) in Guix

[Ivan Vilata i Balaguer]

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

Mekeor Melire (2022-12-10 01:00:24 +0000) wrote:

> 2022-12-09 23:10 mekeor@posteo.de:
> 
> > 2022-12-05 17:23 ivan@selidor.net:
> >
> > > in #59746 I skipped documenting `resume_offset` with more detail, even
> > > if it's needed for resuming from a swap file. The reason is that
> > > according to [swsusp doc][1], some specific tool may be needed to
> > > compute the swap file offset. There is [swap-offset][2] from the
> > > uswsusp suite, which is missing from Guix and no longer shipped with
> > > Debian.
> >
> > What about the "filefrag" executable from the "e2fsprogs" package.
> > According to this article, it can be used in place of the deprecated
> > uswsusp suite:
> >
> > https://www.linuxuprising.com/2021/08/how-to-enable-hibernation-on-ubuntu.html
> 
> I just tried this out. And it worked like a charm! I have hibernated and
> resumed successfully - first time with Guix System. I'm so happy :)
> 
> Would you like to add instructions for swap-files to your
> patch-series #59746?
> 
> What I did: First, determine offset:
> 
> --8<---------------cut here---------------start------------->8---
> $ sudo filefrag -v /swapfile
> Filesystem type is: ef53
> File size of /swapfile is 1717986918 (4194304 blocks of 4096 bytes)
>  ext:     logical_offset:        physical_offset: length:   expected: flags:
>    0:        0..       0:    5308416..   5308416:      1:
> --8<---------------cut here---------------end--------------->8---
> 
> Then, use offset in operating-system declaration:
> 
> --8<---------------cut here---------------start------------->8---
>   (kernel-arguments
>     (cons*
>       "resume=/dev/mapper/cryptroot"
>       "resume_offset=5308416"
>       %default-kernel-arguments))
> --8<---------------cut here---------------end--------------->8---
> 
> Caveat: IIUC, this does not work with Btrfs.

Good find!  Besides the issue of `filefrag` being ExtFS-specific, another
thing that worries me is [this check][1] that `swap-offset` does about the
swap header being physically contiguous on disk, which would need to be made
manually with `filefrag`.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-utils.git/tree/swap-offset.c#n114

I guess that swap header fragmentation won't happen in most cases, but I also
see that the instructions in "(guix)Keyboard Layout, Networking, and
Partitioning" to create a swap file use `dd` instead of something less prone
to fragmentation like `fallocate` (which then may or may not work depending on
the particular FS).

So I'm not completely at ease with extending the instructions for swap files,
but someone more versed in the topic may. `:)`

Cheers,

-- 
Ivan Vilata i Balaguer -- https://elvil.net/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Status of hibernation (suspend to disk) in Guix

[Ivan Vilata i Balaguer]

[-- Attachment #1: Type: text/plain, Size: 2140 bytes --]

Ivan Vilata i Balaguer (2022-12-12 21:11:53 +0100) wrote:

> Mekeor Melire (2022-12-10 01:00:24 +0000) wrote:
> 
> > > What about the "filefrag" executable from the "e2fsprogs" package.
> > > According to this article, it can be used in place of the deprecated
> > > uswsusp suite:
> > >
> > > https://www.linuxuprising.com/2021/08/how-to-enable-hibernation-on-ubuntu.html
> 
> Good find!  Besides the issue of `filefrag` being ExtFS-specific, another
> thing that worries me is [this check][1] that `swap-offset` does about the
> swap header being physically contiguous on disk, which would need to be made
> manually with `filefrag`.
> 
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-utils.git/tree/swap-offset.c#n114

I had a quick look to the [source code of mkswap][1] and it does take care of
checking whether the swap file has holes in it (look for the word "hole").  If
it has, it prints a warning (but it continues).  For instance:

```
$ dd if=/dev/zero of=swap bs=512 count=1 seek=1000
1+0 records in
1+0 records out
512 bytes copied, 0.000234313 s, 2.2 MB/s
$ mkswap swap

mkswap: swap contains holes or other unsupported extents.
        This swap file can be rejected by kernel on swap activation!
        Use --verbose for more details.

Setting up swapspace version 1, size = 496 KiB (507904 bytes)
no label, UUID=3c5920cb-04ee-4713-8008-c2c1bebc2f6f
```

[1]: https://github.com/util-linux/util-linux/blob/master/disk-utils/mkswap.c

Since it's unlikely that the file will change its block arrangement on disk,
and enlarging it requires another invocation of `mkswap`, it's probably enough
to tell the user to check for such warnings on `mkswap` invocation (in section
"(guix)Keyboard Layout, Networking, and Partitioning"), and then instructing
them to use `filefrag` in "(guix)Swap Space" should be ok.

I can work on an additional patch for that, but I can't ensure that it'll be
ready before 1.4.0 (I'm not in the dev team, so I don't know what the planning
for the release is 😉).

Cheers!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Status of hibernation (suspend to disk) in Guix

[Ivan Vilata i Balaguer]

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

Ivan Vilata i Balaguer (2022-12-14 10:43:46 +0100) wrote:

> Since it's unlikely that the file will change its block arrangement on disk,
> and enlarging it requires another invocation of `mkswap`, it's probably enough
> to tell the user to check for such warnings on `mkswap` invocation (in section
> "(guix)Keyboard Layout, Networking, and Partitioning"), and then instructing
> them to use `filefrag` in "(guix)Swap Space" should be ok.
> 
> I can work on an additional patch for that, but I can't ensure that it'll be
> ready before 1.4.0 (I'm not in the dev team, so I don't know what the planning
> for the release is 😉).

Ooops, too late anyway for 1.4.0 (congrats for the dev team BTW)! 😁

I sent an alternative, more elaborated patch to #59746.  Some notes:

- Both `mkswap` and `swapon` complain about swap files with holes, so I deemed
  it redundant to add notes about that (and besides, it should be rare enough
  when using the `dd`-based creation technique).

- `filefrag` does work on non-Ext2 filesystems (by falling back to an older
  ioctl), one just needs to force the extents output (`-e`) and run it as root
  in case the newer ioctl fails.  I used that in the swap file example.

- Yeah, there's a specific swap file example now with instructions on how to
  get the offset with `filefrag`.

I hope that the new patch is more complete and straightforward than the
previous one.

Thanks everyone for the extra info, cheers!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Status of hibernation (suspend to disk) in Guix

[Ivan Vilata i Balaguer]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

Ivan Vilata i Balaguer (2022-12-21 13:27:25 +0100) wrote:

> […] I sent an alternative, more elaborated patch to #59746. […]

Just a heads up for anyone following the thread but not the issue: the changes
got merged by Ludo in c9b383fb with a few fixes.

Thanks everyone for your help!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Status of hibernation (suspend to disk) in Guix

[Mekeor Melire]

2022-12-02 21:32 me@tobias.gr:

> Ivan Vilata i Balaguer 写道：

> > But then I wonder if I may have rushed to post the patch, as I don't
> > know whether hibernation is supposed to be more or less mature or
> > supported in Guix (we may not want to encourage people to use a
> > feature which may easily cause data loss)… Though it works quite
> > well for me!
>
> OTOH, I deliberately hadn't documented ‘resume=’ so far.
>
> OTOH, I have been hibernating multiple times a day for years now, only
> ever rebooting my laptop for kernel updates.
>
> So the feature is probably safe, and we should probably consider it
> supported at this point. Thanks for bringing it up!
>
> > So the TL;DR would be: Is it worth adding such documentation, given
> > the current state of hibernation support in Guix?
>
> I think documenting the current status quo in time for 1.4.0 is a good
> idea.
>
> The next step is to automate things so ‘resume=’ becomes optional.
> This should have landed already, but hasn't for personal reasons. The
> code is basically ready, but won't be in the release.

Thanks for making hibernation work and for bringing that up. I have two
questions:

  1. Does hibernation work in case of swap-partition inside an
     luks-encrypted device?

  2. Does hibernation work in case of a swap-file inside a
     root-partition inside a luks-encrypted device?

Also, I'm not sure if it makes sense to mark the hibernation-feature
stable and finished if the mentioned two cases are not supported.

Re: Status of hibernation (suspend to disk) in Guix

[Jack Hill]

On Fri, 9 Dec 2022, Mekeor Melire wrote:

> Thanks for making hibernation work and for bringing that up. I have two
> questions:
>
>  1. Does hibernation work in case of swap-partition inside an
>     luks-encrypted device?

Yes, this works for me (nested LVM in LUKS too)

>  2. Does hibernation work in case of a swap-file inside a
>     root-partition inside a luks-encrypted device?

I haven't personally tried this one.

Best,
Jack

Re: Status of hibernation (suspend to disk) in Guix

[Nathan Dehnel]

> 2. Does hibernation work in case of a swap-file inside a
     root-partition inside a luks-encrypted device?

Just posting to confirm that this does work (with BTRFS as well;
single drive only, not RAID).