hibernation support on the desktop
This bug is proposed as a Fedora 24 blocker, anaconda component:
Laptop does not resume from hibernate, boots instead
https://bugzilla.redhat.com/show_bug.cgi?id=1206936
That bug is already 45 comments long and goes back over a year.
Hibernation as a subject involves the DE, upower, systemd, kernel,
firmware, and the OS installer so a full discussion is massive. I
tried to narrow the scope of this to just one central argument which
is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1206936#c46
The gist is:
If a hibernation image exists, there probably should be a best effort
to resume that image to avoid data loss. Right now there is no resume=
boot parameter option so if a hibernation image exists it will not be
resumed. Should the lack of resume= boot parameter be considered a
release blocking bug?
This intentionally doesn't answer myriad other questions: when is
there a hibernation image; why can that fail; what happens if the
hibernation image is there, is resumed, but still fails; whether swap
is of sufficient size; whether swap can be on an LVM2 logical volume;
the fact Secure Boot enabled currently means hibernation image
creation is disabled, etc. I'm considering those out of scope for
sanity sake for this particular bug. Quite honestly I'd like to see
all the DE's drop hibernation from their GUIs since it's grossly
misleading to the user at best, but that too is set aside.
The central question is: does the existence of resume= cause more
problems than it solves? i.e. is it possible a hibernation image gets
loaded, is not invalidated by the kernel, but is somehow
non-deterministically unstable such that subsequent corruption or data
loss is still decently possible? If that's a yes then I'd say this is
not an anaconda blocker but places a significant burden on DE's to
disable and hide hibernation UI elements. If hibernation resumption is
safer than not resuming, then this is probably a legitimate blocker
but I think ultimately that's a judgment call for the folks who turn
up to vote at blocker review :-)
Thanks,
--
Chris Murphy