On Tue, Apr 19, 2016 at 4:10 AM, Lennart Poettering <lenn...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
