[systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation

[Jan Janssen]

On Thursday 28 August 2014 11:33:44 Ivan Shapovalov wrote:
> On Thursday 28 August 2014 at 06:25:51, Jan Janssen wrote:
> > Ivan Shapovalov <intelfx100 <at> gmail.com> writes:
> > > On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote:
> > > > On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote:
> > > > > On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 <at> gmail.com) wrote:
> > > > > > This patchset allows systemd to parse resume= kernel command line
> > 
> > parameter
> > 
> > > > > > and initiate resume from the specified device.
> > > > 
> > > > What about swap files with the resume_offset= parameter? Are they
> > > > still
> > > > being used?
> > > 
> > > I don't know if somebody uses that, but for now it's missing
> > > functionality.
> > > 
> > > After a cursory search, I could not find a mechanism to initiate a
> > > resume with offset from userspace. In Arch, it was never implemented
> > > even if possible.> 
> > I'm a heavy user of this myself. It's especially useful because you can
> > just have a single luks encrypted ext4 without a lvm in between for a
> > swap partition or (even more yuck) using a separate (encrypted) swap
> > partition.
> > 
> > Arch does support this, mostly because as far as I know, the
> > resume_offset=
> > is consumed by the kernel, while resume= has to refer to the (unencrypted)
> > filesystem (/dev/mapper/root in my case). So, as long as this solution
> > waits for the device to show up in /dev/ (and especially /dev/mapper/ for
> > my case), this should work out.
> > 
> > Here's information to set this up. Imho more people should be aware this
> > is
> > possible:
> > https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file
> > 
> > Jan
> 
> Hmm, so is resume_offset= parsed independently of resume=? If that's the
> case, and resume_offset= can be parsed by kernel while resume= is parsed
> by userspace, then yes, I was wrong and this should work.
> 
> Actually, it should work _just like before_, sans tuxonice support.

I gave it a try and resume works for me with that sd-resume hook in arch. But I'm not too sure whether fsck is delayed properly:

systemd[1]: Started Cryptography Setup for luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
systemd[1]: Found device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
systemd[1]: Starting File System Check on /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78...
systemd[1]: Starting Resume from hibernation using device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78...
systemd-fsck[135]: fsck.ext4 doesn't exist, not checking file system on /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78
systemd[1]: Starting Encrypted Volumes.
systemd[1]: Reached target Encrypted Volumes.
systemd[1]: Starting System Initialization.
systemd[1]: Reached target System Initialization.
systemd[1]: Starting Basic System.
systemd[1]: Reached target Basic System.
systemd[1]: Started File System Check on /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
kernel: PM: Starting manual resume from disk
kernel: PM: Hibernation image partition 254:0 present
kernel: PM: Looking for hibernation image.
systemd-hibernate-resume[137]: Could not resume from '/dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78' (254:0).
systemd[1]: Started Resume from hibernation using device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.

If I read this correctly, the moment the plaintext device appears, the resume and fsck are racing each other. And in this case,
fsck won (good thing my fsck binaries are not in the systemd initrd for now).

Jan