(New thread since this is unrelated to the original subject.) On Fri, Dec 6, 2019, at 9:44 PM, John M. Harris Jr wrote: > On Friday, December 6, 2019 11:22:34 AM MST Chris Murphy wrote: > > On Fri, Dec 6, 2019 at 7:46 AM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> > > wrote: [...] > It's simply false to say that hibernation is not supported. Not only is it > supported, there's a big button for it in the major DEs. I have not tested > GNOME, but I'd be willing to be it's there, unless something has changed with > the shutdown menu since the version of GNOME 3 used in RHEL 7. Please do let > me know if GNOME is missing that button in Fedora, so that I may open a > feature request on behalf of GNOME users in Fedora. I couldn't find the hibernate button in Gnome, but I'm still on F29. Suspend is unreliable on my system, so I manually type `sudo systemctl hibernate` when I need to put my laptop in the bag, and it's very reliable in my 2018 ThinkPad. (Apparently, it's hard to get the button to hibernate w/in Gnome Shell: https://askubuntu.com/questions/61138/how-can-i-hibernate-from-gnome-shell ) > > It doesn't work out of the box with sufficient consistency or > > predictability to consider it supported or supportable. You'll find > > myriad upstream and downstream bug reports about hibernation that > > languish indefinitely. Some do get fixed. Whether it works depends on > > make/model, the firmware revision, and kernel version. > > See above. It works out of box. I will take that further to say that it works > consistently, so long as you don't select a different kernel image to resume. > On some hardware, you would be correct that hibernation does not work, but > that is not the case with most systems, and is irrelevant of the degree to > which Fedora supports it, which is that the option is available for use in the > major DEs and on the command line. My experience is that hibernate is more reliable than suspend. Just this afternoon, I performed a suspend-to-ram, and during the 6 or so hours since then, the system dropped from 51% charge to 11% charge... it seems like something is not being put in its lowest possible power state. With hibernate, the system does not drain the battery while not in active use. Indeed, the primary hibernate issue I've seen is when a newer kernel has been installed and I accidentally boot into that one instead of the one that was hibernated... Seems like this should be easy to fix by having the hibernate process auto-select the current kernel as default for the next boot. The other issue is that the machine sometimes does not poweroff on its own upon hibernation. This seems to happen when I have or just had an external display attached prior to hibernation. I know to make sure the machine is off before putting it in my bag, and the four-second poweroff works fine in this case. It always boots up to just where I left off when I get to my destination. > > > The only time it wouldn't work seems to be in one of those special UEFI + > > > Secure Boot cases. > > > > It's not special. It happens to be the default firmware and > > configuration of most new x86_64 hardware, and the default policy upon > > installation by Fedora. > > That is simply not the case. While most new consumer x86_64 hardware comes > with UEFI on by default, unless it came with Windows installed, Secure Boot is > normally disabled. This reflects my experience. When buying a Dell tower workstation with RHEL pre-installed, Secure Boot was turned off in the BIOS out-of-the box. > > And that means hibernation is not presently possible by default on those > > systems. > > Simply because somebody decided to disable the feature, as a "security" > measure. > Indeed, I did turn off Secure Boot on my ThinkPad where hibernate is rock solid but suspend quickly drains the battery. > > There is no agreement by distributions how to handle hibernation image > > signing that upstream will accept and Fedora isn't likely to carry out of > > tree patches for such a thing. > > There's no need to sign the hibernation image to begin with. That is an > arbitrary requirement that has been thrown in for absolutely no reason that I > can think of. You're not booting from the hibernation image. It doesn't need > to be signed to comply with the absurd requirements of "Secure Boot". > Disabling hibernation seems like an unreasonable loss of functionality in exchange for Secure Boot to me. How hard would it be to standardize on a signature/verification method? Is this a signature we could delegate to a TPM? Is it more palatable to enable it for MOK-signed kernels/modules, kind of like can be done for proprietary drivers? (Not sure if any nVidia distro package does this by MOK-signing by default, though...) V/r, James Cassell _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
