GNOME Bugzilla – Bug 649193
No option to hibernate
Last modified: 2012-11-02 14:57:48 UTC
I can't find the option to hibernate my laptop; only suspend/restart/power off.
This is a known questionable design decision (see bug 643457 for example). A workaround is to install the alternative-status-menu extension. I don't know if this can be considered a duplicate, or hibernate functionality is orthogonal to power off.
*** Bug 650578 has been marked as a duplicate of this bug. ***
As far as I understand, the request is (at least mine on bug 650578 was) to have a fourth option in the dialog-box that pops-up after one clicks the Power-off item in the User menu. Currently it only shows 1) Cancel, 2) Restart, and 3) Power-off. It would be a big improvement, in my opinion, to offer a fourth option in this dialog-box (and not as a separate item in the user menu) to "hibernate". At present there is simply no way to manually hibernate the computer unless one configures power-manager to hibernate on pressing the "power" button, which is a setback as far as my desktop usage goes.
(In reply to comment #3) > As far as I understand, the request is (at least mine on bug 650578 was) to > have a fourth option in the dialog-box that pops-up after one clicks the > Power-off item in the User menu. Currently it only shows 1) Cancel, 2) Restart, > and 3) Power-off. It would be a big improvement, in my opinion, to offer a > fourth option in this dialog-box (and not as a separate item in the user menu) > to "hibernate". At present there is simply no way to manually hibernate the > computer unless one configures power-manager to hibernate on pressing the > "power" button, which is a setback as far as my desktop usage goes. Agreed, it's a good idea to add a new option in dialog-box.
I would quite definitely consider this a bug. Suspend-to-disk works flawlessly on most computers nowadays, and when I turn my laptop off in the evening I definitely do not wish it to stay in suspend-to-ram mode for the night, needlessly wasting battery life. With gnome-shell, what used to work just fine in all previous versions of GNOME and is an integral part of my daily workflow, has suddenly become almost completely inaccessible.
(In reply to comment #5) > I would quite definitely consider this a bug. Suspend-to-disk works flawlessly > on most computers nowadays, and when I turn my laptop off in the evening I > definitely do not wish it to stay in suspend-to-ram mode for the night, > needlessly wasting battery life. > > With gnome-shell, what used to work just fine in all previous versions of GNOME > and is an integral part of my daily workflow, has suddenly become almost > completely inaccessible. What has been suggested, and I believe what the current plan is, is to do a hybrid: suspend-to-ram for fifteen minutes for quick access, and then do a full suspend-to-disk after that time to save power.
(In reply to comment #6) > What has been suggested, and I believe what the current plan is, is to do a > hybrid: suspend-to-ram for fifteen minutes for quick access, and then do a full > suspend-to-disk after that time to save power. That may be a sensible default option (if it actually works, I haven't seen that working on Linux yet), but a user who /wants/ to use hibernate right away (which may also be the only sensible option on some systems, which do not support suspend-to-ram properly, including my desktop computer) should not be forced to switch to another desktop environment in order to achieve this. In fact I find this so annoying, I am considering to downgrade back to GNOME 2...
(In reply to comment #7) > (In reply to comment #6) > > > What has been suggested, and I believe what the current plan is, is to do a > > hybrid: suspend-to-ram for fifteen minutes for quick access, and then do a full > > suspend-to-disk after that time to save power. > > That may be a sensible default option (if it actually works, I haven't seen > that working on Linux yet), but a user who /wants/ to use hibernate right away > (which may also be the only sensible option on some systems, which do not > support suspend-to-ram properly, including my desktop computer) should not be > forced to switch to another desktop environment in order to achieve this. In > fact I find this so annoying, I am considering to downgrade back to GNOME 2... If suspend-to-ram doesn't work, we should detect it. We use pm-utils to check: pm-is-supported. File a bug with your distro if this is giving false positives. Also, the power-off dialog isn't currently in the shell, but that may be changing, I don't know.
(In reply to comment #8) > Also, the power-off dialog isn't currently in the shell, but that may be > changing, I don't know. It is, and has been since some time before 3.0.
Here's my use case: I suspend my laptop probably 10 or 20 times a day by closing the lid. This works fine and I like how fast it wakes up. This is what I expect to happen when I close the lid; anything else would be wrong. But I realized a while ago that when my laptop is suspended, and I put it in my backpack and walk/run/bike/whatever, sometimes when I take it out again it is simply off, and I lose all my unsaved data. This must be because the battery jiggles around, or something else disrupts the constant power it needs to stay in suspend mode and not die. Making it hibernated instead of suspended reliably solves this problem. Keeping my unsaved data and application states is totally worth the extra seconds it takes to wake up after I get to work or home. This means I hibernate my laptop usually twice a day, and I really do care that it's hibernating and not suspending. In GNOME 2 this worked fine - I would close the lid to suspend, and select "hibernate" from the menu to hibernate. In GNOME 3, what am I supposed to do? It's obvious that hibernate still exists. It's there in the power management settings. I can easily make my laptop hibernate when I close the lid. But I don't want that, I want it to suspend when I close the lid, and hibernate only on those twice-a-day occasions when I know it's going to be jiggling around in my backpack. Why can't I tell it to hibernate on command??
(In reply to comment #10) > In GNOME 3, what am I supposed to do? You can still assign Hibernate to the sleep or power buttons (or maybe the closing-lid option? I'm on a desktop ATM and don't see it here). Or run pm-hibernate as root.
Created attachment 202407 [details] Screenshot of the power settings dialog
I don't see how to do that. How can I "assign hibernate to the sleep or power buttons"? Here's what my power settings dialog looks like. The top two buttons don't allow hibernate as an option. The middle two buttons allow me to hibernate when I close the lid, but that's not what I want to happen. The bottom button allows me to hibernate when the battery is critically low, but then I have to sit there and wait for my battery to run out! It seems like the only possible way to hibernate on command (without installing modified software) is to "run pm-hibernate as root". Is that really intended?? Why must the simple hibernate command be absent from the GUI, even though the hibernate *action* is obviously still present?
Created attachment 202460 [details] gnome-control-center 3.0.2 power settings (In reply to comment #13) > I don't see how to do that. How can I "assign hibernate to the sleep or power > buttons"? Odd, here's my power settings dialog.
(Without wanting to turn this into a support forum...) check what 'upower --dump' prints on your system. At the end of the output you should see some data about what your system can do, and whether it has a power/sleep button; I believe that these options are hidden in the GUI if upower does not detect them on your system.
Here's my upower --dump: Device: /org/freedesktop/UPower/devices/line_power_AC native-path: /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC power supply: yes updated: Thu Dec 1 15:56:12 2011 (204 seconds ago) has history: no has statistics: no line-power online: no Device: /org/freedesktop/UPower/devices/battery_BAT0 native-path: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0 vendor: Sanyo model: DELL WK3799 serial: 414 power supply: yes updated: Thu Dec 1 15:59:17 2011 (19 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging energy: 14.6076 Wh energy-empty: 0 Wh energy-full: 86.58 Wh energy-full-design: 86.58 Wh energy-rate: 11.2887 W voltage: 11.889 V time to empty: 1.3 hours percentage: 16.8718% capacity: 18.3718% technology: lithium-ion History (charge): 1322783957 16.872 discharging 1322783927 16.987 discharging 1322783897 17.128 discharging 1322783867 17.244 discharging History (rate): 1322783957 11.289 discharging 1322783927 10.545 discharging 1322783897 11.522 discharging 1322783867 12.066 discharging Daemon: daemon-version: 0.9.13 can-suspend: yes can-hibernate yes on-battery: yes on-low-battery: no lid-is-closed: no lid-is-present: yes is-docked: no I don't see anything about a sleep button. So the problem remains - how am I supposed to hibernate on command without using the terminal or installing different software? It makes no sense not to allow me to hibernate on command when I can obviously make it hibernate on lid-close or battery depletion.
Any news on this? I would still really really like to be able to hibernate my laptop on command. (Or to have some other kind of workflow that doesn't risk losing all my open data every time I take my laptop in my backpack.)
The "Alternative Status menu" gnome-shell extension adds "hibernate" to the menu. Works fine so far, there is one caveat: I am missing a keyboard shortcut accessing that function. It is only accessible by mouse.
Hi, does this still happen with GNOME 3.6?
Yes, omitting hibernation from the user menu / power off dialog was a conscious design decision. Some controversial choices have been revisited in 3.6 (power off, *cough, cough*), but that does not affect the omission of hibernate.
Why is this "unconfirmed"? Shouldn't it be "wontfix"?
(In reply to comment #21) > Why is this "unconfirmed"? Shouldn't it be "wontfix"? Mainly to give people a place to discuss, but indeed, there are currently no plans to expose both suspend and hibernate - the design calls for what Jasper describes in comment #6 instead. It's not completely out of the question that this decision will be revisited at some point in the future, but that wouldn't require this bug to be kept open either ...
*** Bug 677311 has been marked as a duplicate of this bug. ***