[systemd-devel] systemd hibernator generator does not function on default Fedora install

[Andrei Borzenkov]

15.05.2016 06:36, Chris Murphy пишет:
> On Thu, May 12, 2016 at 12:38 PM, James Hogarth <james.hogarth at gmail.com> wrote:
>>
>> On 2 May 2016 18:58, "James Hogarth" <james.hogarth at gmail.com> wrote:
>>>
>>>
>>> On 24 Apr 2016 21:31, "poma" <pomidorabelisima at gmail.com> wrote:
>>>>
>>>> On 20.04.2016 22:42, Chris Murphy wrote:
>>>>> On Wed, Apr 20, 2016 at 1:50 PM, Tobias Hunger
>>>>> <tobias.hunger at gmail.com> wrote:
>>>>
>>>> [...]
>>>>
>>>>> Anyway, the most complete solution for BIOS, UEFI, and UEFI Secure
>>>>> Boot systems, is fast startups as possible (which helps all kinds of
>>>>> use cases not just desktops), and then encourage DE's and app makers
>>>>> to support apps that save their own state without users having to
>>>>> manually save files, and default to power off in low battery cases.
>>>>>
>>>>> I guess opensuse has some patches that aren't upstream yet that
>>>>> support signed hibernation images for UEFI Secure Boot?  Maybe there's
>>>>> a way forward at some point. But right now I'm just not seeing it.
>>>>> There's some kind of brick wall in every direction with hibernation.
>>>>>
>>>>
>>>> :)
>>>> "Lacus Hiemalis Edictum" patch-set actually existed for several years.
>>>>
>>>> ...
>>>
>>> <snip>
>>>
>>> There is something that can be done in systemd to avoid the data loss
>>> issue without having to add complexity to the generator.
>>>
>>> Add to the logind conditions for suspend-to-disk an additional one to the
>>> existing ones to ensure resume= is in the kernel cmdline.
>>>
>>> If it's not there refuse the hibernate and shutdown instead. At least then
>>> the processes would get shutdown properly with a TERM and not have a power
>>> cord pull situation (with sync) on them.
>>>
>>> That would be minimal change from present but avoid writing a resume image
>>> that will never be read.
>>
>> Since this seemed a nice solution to the problem, and it appeared to make
>> sense to validate the kernel argument would be there ready for the generator
>> for the resume before allowing the hibernate through logind there's patches
>> for Fedora and upstream systemd on this bug:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1332266
>>
>> I've tested the F23 build with the patch on my laptop and it behaves as I'd
>> expect for an invalid resume=, no resume= and as valid resume=
> 
> Seems like resume= should be checked to make sure the specified device
> exists/is-valid for holding a hibernation image; just as important as
> checking /sys/power/state and /sys/power/disk.
> 

Both dracut and initramfs-tools can embed resume device information into
initrd and do not require resume= on kernel command line. Refusing
hibernation in this case will break these configurations.