Suspend-to-Disk vs Suspend-to-RAM (was: Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default)
(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(a)splentity.com>
> 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