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 -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/desktop@xxxxxxxxxxxxxxxxxxxxxxx
