On 2014-08-29 04:28, Andrei Borzenkov wrote:
В 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?
never mind, I failed to update the system-fsk@.service that had the new
dependency.
Jan
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
