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

[Andrei Borzenkov]

В Thu, 28 Aug 2014 19:36:53 +0200
Jan Janssen <medhefgo at web.de> пишет:

> 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...

Hmm ... it is not systemd-fsck-root.service. Do you have
local-fs-pre.target installed in initrd? What units are there at all?

> 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
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel