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

[Harald Hoyer]

On 20.04.2016 06:47, Chris Murphy wrote:
> On Tue, Apr 19, 2016 at 4:10 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
> 
>>
>> So what precisely are you proposing? That we actively search for the
>> swap partition in the hibernate-resume generator?
> 
> I think the main thing James is after, I know I'm in this camp, is
> understanding all the parts and how they interrelate. Fedora doesn't
> support it at all, and James it trying to figure out why not, and
> needs sufficient understanding of hibernation in order to determine
> which groups need to do what to make it work reliably or at least fail
> safe, neither of which appear to be true right now.
> 
> The bottom line is there are more questions than answers.
> 
> In some ancient bug or lkml I'd read a kernel maintainer say that the
> hibernation image size isn't fixed, and might be less than RAM size
> but could be a little more than RAM size, especially if some swap is
> being used. So what should swap partition size be to support
> hibernation? 1x RAM? 1.5x? 2x? Other?
> 
> Does the swap device need to be a "standard" (MBR/GPT) partition? Or
> can it be on dmcrypt, lvm LV, a file on a file system, on md/mdadm?
> Harold's message suggests to me it should be a plain partition only,
> as does comment 16/17 in this bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1224151#c17
> 
> I kinda have to agree, if it can't be encrypted, then I think linux
> hibernation is almost pointless, and maybe just give up. Intel Rapid
> Start (firmware managed) hibernation with SSDs and the proper GPT
> partition type GUID is faster and more reliable, but also not
> encrypted. So if we're stuck with something not encrypted anyway, I
> don't see why we don't just throw in the towl and only support
> firmware hibernation which has the added benefit of automatically
> switching from sleep to hibernate when the battery gets too low, which
> software hibernation can't do.

Yeah, I think dm-crypt/luks does not change metadata on disk while opening it, so no problems here.

> 
> https://mjg59.dreamwidth.org/26022.html
> 
> 
> And further we avoid the nasty little problem we end up with
> combination hibernation with dual boot Linux systems with competing
> bootloaders, which makes me think eating roadkill for breakfast might
> be safer.
> 
> Does anyone want to make dracut into a daemon? (small joke) That way
> it always automatically updates the initramfs anytime relevant
> configuration change happens?

Not daemon, but with a kind of Makefile, we could detect changes and rebuild the initramfs on shutdown, if wanted.

> 
> Anyway, I think the first step is to understand things better. Figure
> out where the land mines are. Make sure it can be sanely supported, is
> fail safe, doesn't cause more problems than it solves, and there's
> some way for DE's to discover whether or not they should even present
> hibernation UI to the user. And then assess if what remains is even
> worth the trouble, in particular compared to firmware hibernation. And
> then make a proposal.
> 
>