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

[Chris Murphy]

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.

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?

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.


-- 
Chris Murphy