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

[Jan Janssen]

On 2014-08-29 04:28, Andrei Borzenkov wrote:
> В 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?

never mind, I failed to update the system-fsk at .service that had the new 
dependency.

Jan