В Thu, 28 Aug 2014 19:36:53 +0200 Jan Janssen <medhe...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel