On 20.04.2016 06:47, Chris Murphy wrote: > 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.
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. > > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
