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,
On Fri, 2016-04-22 at 13:14 -0600, Chris Murphy wrote:
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
My answer is that we do not support hibernation in Fedora Workstation, so I really do not care. We do not even expose it except as the action to perform on critical battery. It's partly because we have enough confusing power off options, but partly because hibernation is unreliable, hardware-dependent, and frequently broken.
The other release-blocking desktops are KDE and Xfce (on ARM); I guess they might care about hibernation. But they don't use this list, so I think this isn't a good place for this discussion.
Michael
On Fri, Apr 22, 2016 at 2:24 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Fri, 2016-04-22 at 13:14 -0600, Chris Murphy wrote:
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
My answer is that we do not support hibernation in Fedora Workstation, so I really do not care. We do not even expose it except as the action to perform on critical battery. It's partly because we have enough confusing power off options, but partly because hibernation is unreliable, hardware-dependent, and frequently broken.
Well this came up in #fedora-qa right after blocker review and someone, maybe mcclasen (?), showed a screen shot where there was definitely hibernation in the Power panel under Suspend & Power Off (I know that's the 3.18 term, it's different in 3.20 but there were two options under there, the lower one had a drop down menu that included hibernation).
In any case, the question isn't whether hibernation is supported. It's whether a.) it's offered by the DE by default and b.) does data loss resulting from the failure to resume violate the data loss/corruption release criterion and c.) is it reasonable to burden anaconda with adding resume= to boot parameters?
The other release-blocking desktops are KDE and Xfce (on ARM); I guess they might care about hibernation. But they don't use this list, so I think this isn't a good place for this discussion.
Fair enough.
On Fri, 2016-04-22 at 15:28 -0600, Chris Murphy wrote:
Well this came up in #fedora-qa right after blocker review and someone, maybe mcclasen (?), showed a screen shot where there was definitely hibernation in the Power panel under Suspend & Power Off
Yeah, that's the "except" here:
On Fri, 2016-04-22 at 15:24 -0500, Michael Catanzaro wrote:
We do not even expose it except as the action to perform on critical battery.
The only way to hibernate is to use the command line (unsupported) or let your battery drain to critical. And if you have no remaining battery, I would expect data loss anyway, as hibernate fails more often than not in my experience... and that's if I'm lucky and the computer does not power off during the attempt to hibernate....
Running out of power is an edge case, and it's never worked reliably anyway.
Michael
On Fri, Apr 22, 2016 at 3:47 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Fri, 2016-04-22 at 15:28 -0600, Chris Murphy wrote:
Well this came up in #fedora-qa right after blocker review and someone, maybe mcclasen (?), showed a screen shot where there was definitely hibernation in the Power panel under Suspend & Power Off
Yeah, that's the "except" here:
On Fri, 2016-04-22 at 15:24 -0500, Michael Catanzaro wrote:
We do not even expose it except as the action to perform on critical battery.
OH I missed that somehow. OK I'm looking at this on Fedora 23 and Suspend & Power Off is set to Automatic suspend Off, there is nothing else. I do have sufficient swap, and 'systemctl hibernate' does hibernate the system, and does produce a hibernation file. So I don't follow why some machines have this exposed hibernation option. But in any case if it's exposed at all by even some machines by default rather than proscribed across the board, I'd say the desktop environment is saying it supports hibernation on that configuration and it should work. But it can't work if resume= isn't a boot parameter.
Where I'm lost is, the disconnect between "we do not support hibernation in Fedora Workstation" but then there's this exception for action to perform on critical battery. So it is supported in the case of critical battery.
I'm really terribly biased toward if you offer something in a GUI, it should work. If it doesn't work it's a bug, fix the bug or remove the UI access to it.
The only way to hibernate is to use the command line (unsupported) or let your battery drain to critical. And if you have no remaining battery, I would expect data loss anyway, as hibernate fails more often than not in my experience... and that's if I'm lucky and the computer does not power off during the attempt to hibernate....
Running out of power is an edge case, and it's never worked reliably anyway.
It is an edge case based on what data? Every traveling user I know routinely runs into this "edge case" and it's just short of completely reliable on Windows and OS X.
If it can't be made almost completely reliable, fine, proscribe it from the GUI in every case. I don't see the logic at all in offering it in exception cases where current configuration guarantees it will silently fail resulting in data loss. I see no positive to this situation.
On Fri, Apr 22, 2016, 4:25 PM Michael Catanzaro mcatanzaro@gnome.org wrote: On Fri, 2016-04-22 at 13:14 -0600, Chris Murphy wrote:
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
My answer is that we do not support hibernation in Fedora Workstation, so I really do not care. We do not even expose it except as the action to perform on critical battery. It's partly because we have enough confusing power off options, but partly because hibernation is unreliable, hardware-dependent, and frequently broken.
The other release-blocking desktops are KDE and Xfce (on ARM); I guess they might care about hibernation. But they don't use this list, so I think this isn't a good place for this discussion.
First, suspending on Linux isn't reliable and hardware dependent. I'm only replying to this thread because I've had a long-standing issue with my current laptop (here's the bug reported by Florian: https://bugzilla.redhat.com/show_bug.cgi?id=1329047). Second, are three power off options too many? It's not as though average users aren't well aware of all these options.
In general, I'd love to see data supporting people's preference for either: 1) not being able to choose and having an unpredictable resume experience, or 2) exposing the three options so they can determine what trade-off they are willing to make given their usage.
On Fri, Apr 22, 2016 at 4:02 PM, Liam liam.bulkley@gmail.com wrote:
First, suspending on Linux isn't reliable and hardware dependent. I'm only replying to this thread because I've had a long-standing issue with my current laptop (here's the bug reported by Florian: https://bugzilla.redhat.com/show_bug.cgi?id=1329047).
OK?
Second, are three power off options too many? It's not as though average users aren't well aware of all these options.
In my opinion, yes it's too many for the average user if we're sampling a global audience. The options should be sleep and poweroff. When sleep initiates first generation a hibernation file and then actually do suspend to RAM. If sufficient battery remains, resume happens from RAM and if not from the hibernation file. Oops, except we can't resume from the hibernation file due to misconfiguration by default.
In general, I'd love to see data supporting people's preference for either:
- not being able to choose and having an unpredictable resume experience,
or 2) exposing the three options so they can determine what trade-off they are willing to make given their usage.
I disagree. The user is at least as unreliable as any party in the discussion except when it comes to their consternation at data loss as a result of being tricked into hibernating when the system is configured out of the box to never ever recover properly from hibernation. It's silly.
The OS is obligated to try to resume the hibernation file, or to not provide options to ever create a hibernation file in the first place and instead produce whatever sensible warnings come with an impending poweroff.
On Fri, Apr 22, 2016, 6:48 PM Chris Murphy lists@colorremedies.com wrote:
On Fri, Apr 22, 2016 at 4:02 PM, Liam liam.bulkley@gmail.com wrote:
First, suspending on Linux isn't reliable and hardware dependent. I'm
only
replying to this thread because I've had a long-standing issue with my current laptop (here's the bug reported by Florian: https://bugzilla.redhat.com/show_bug.cgi?id=1329047).
OK?
The point is that having less options in order to make code more maintainable is smart but there's no point to having nice maintainable code that isn't useful.
Second, are three power off options too many? It's not as though average users aren't well aware of all these options.
In my opinion, yes it's too many for the average user if we're sampling a global audience. The options should be sleep and poweroff. When sleep initiates first generation a hibernation file and then actually do suspend to RAM. If sufficient battery remains, resume happens from RAM and if not from the hibernation file. Oops, except we can't resume from the hibernation file due to misconfiguration by default.
In your opinion, there shouldn't be a restart option either?
To keep this on track I'm only going to say one more thing: opinion and feelings are fine until they result in systems becoming less reliable. At that point, supporting data seems like a minimum requirement.
I certainly agree that s3 should work as you say. In fact, the dracut conf in f22 includes the resume module so obviously the intention was that hibernation wouldn't be such an esoteric option. And as I commented in the bug report, it's better to at least have the chance of recovering your session with hibernation than a guarantee of lost state with s3 completely draining the battery.
In general, I'd love to see data supporting people's preference for either:
- not being able to choose and having an unpredictable resume
experience,
or 2) exposing the three options so they can determine what trade-off
they
are willing to make given their usage.
I disagree. The user is at least as unreliable as any party in the discussion except when it comes to their consternation at data loss as a result of being tricked into hibernating when the system is configured out of the box to never ever recover properly from hibernation. It's silly.
The user is an expert in their own use cases and priorities. Data—not from a single user, but from many—allows you to validate, or invalidate, your assumptions. Regardless, the real problem here is not hibernation itself but bad OOB configuration - which is fixable.
The OS is obligated to try to resume the hibernation file, or to not provide options to ever create a hibernation file in the first place and instead produce whatever sensible warnings come with an impending poweroff.
Warnings are useless for an unattended or emergency poweroff. Hibernation isn't.
On 04/22/2016 09:14 PM, Chris Murphy wrote:
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?
Resume has to be disabled anyway to comply with Microsoft's Secure Boot requirements, so I'm not sure if adding the command line parameter changes things for most users.
Florian
On Sat, Apr 23, 2016 at 8:46 AM, Florian Weimer fweimer@redhat.com wrote:
On 04/22/2016 09:14 PM, Chris Murphy wrote:
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?
Resume has to be disabled anyway to comply with Microsoft's Secure Boot requirements, so I'm not sure if adding the command line parameter changes things for most users.
Fedora imposes that limitation in the kernel by choice, and I think it's a good one. This has nothing to do with Microsoft requirements; Windows in fact does do hibernation with Secure Boot enabled. So does openSUSE, using their own patches for signing hibernation images. These patches aren't upstream yet, so Fedora isn't using them, and it's uncertain whether that will happen. I'd expect GNOME doesn't offer hibernation as an option for critical battery power on these systems and so they're out of scope anyway.
It's not a good argument that we should do nothing because most users can't be helped. This bug is about helping the users who can be helped, and are injured in the meantime.
This bug isn't about the dreadful state of power management on Fedora where laptops are hot, have remarkably less battery life, don't have fan controls, thermald isn't in the Fedora repository let alone installed by default, and is objectively worse than literally every body else: Windows, OS X, openSUSE, Chrombooks, Ubuntu, tablets, mobile devices. At some point Workstation needs to get serious about power management. The world has already moved past the desktop, the laptop/ultrabook should be the dominant reference for Workstation with desktop secondary rather than the other way around where laptops are a distant second. I haven't used or owned a desktop in a decade, and won't in the future. They're relics.
desktop@lists.fedoraproject.org
-
Chris Murphy -
Florian Weimer -
Liam -
Michael Catanzaro