Fedora reawakens the hibernation debate [LWN.net]

By Jonathan Corbet
September 17, 2018

Behavioral changes can make desktop users grumpy; that is doubly true for changes that arrive without notice and possibly risk data loss. Such a situation recently arose in the Fedora 29 development branch in the form of a new "suspend-then-hibernate" feature. This feature will almost certainly be turned off before Fedora 29 reaches an official release, but the discussion and finger-pointing it inspired reveal some significant differences of opinion about how this kind of change should be managed.

Unexpected hibernation

Fedora tester Kamil Paral recently noticed a change in laptop power-management behavior in the bleeding-edge Fedora repository. A laptop that had been suspended in the evening would turn out to be hibernated the following morning. "Suspended", in this context, means that the system as a whole has been powered down, but power to memory remains active so that its contents are preserved. Such a system can be quickly restored to an operational state by powering up the rest of the hardware; all applications that were running before will still be there. "Hibernated", instead, means that the contents of main memory have been written to persistent storage so that the entire system can be powered down. Restoring the system requires reading the hibernation image back into memory from storage.

The new suspend-then-hibernate feature attempts to provide the best of both worlds by suspending the system initially, then automatically hibernating three hours after suspension. The motivation for this feature is clear: a suspended system continues to drain its battery (albeit slowly), while a hibernated system does not. A hibernated system left without power for weeks can be expected to resume properly; a suspended system will typically lose everything after a handful of days. This behavior has some clear advantages, but it also raises a number of concerns, especially as an unannounced change with no easy way for the user to change it.

One reason why many users may dislike this change was expressed by Adam Williamson. A suspended system is almost immediately ready for work upon resume; a hibernated system, instead, may require a significant amount of time to read the image back into memory, followed by a period of relatively sluggish behavior as the kernel's page cache is repopulated. For users who are not concerned about the extra power used by suspend — because the system is left plugged in or because they know they will be resuming it before the battery gets low — this extra resume latency can be bothersome while providing no real advantages.

That, on its own, would be a good argument for giving users control over whether a system uses suspend-then-hibernate or simply suspends. But there is a more compelling reason as well: this feature depends on hibernation working correctly, and hibernation is not one of the best-supported features in the Linux kernel.

Hibernation, initially called "software suspend" or "suspend to disk" in kernel circles, was once a hot topic in kernel development — back in 2004. A lot of effort went into making it work, and heated battles were fought over which of two competing implementations should be in the mainline. That discussion slowed considerably around ten years ago, though, when modern suspend-to-RAM functionality became reliable. For many of us, hibernation was only something we used because suspending was not available; once the latter worked, many people never looked back.

As a result, work on hibernation dropped off, to the point that almost nothing has happened in that area in the last decade and few people test it. Some kernel features can survive years of neglect and still work well; hibernation is not one of them. It is a low-level feature that can be defeated by quirks in almost any part of the system, and there are a lot of quirky systems out there. Hibernation is the sort of feature that has to be made to work separately on every new machine. So, while hibernation works on many well-behaved machines, it is rather less reliable on many others. The only way to know for sure is to try it and see if the system resumes reliably over time. Even if hibernation generally works on a particular system, the use of other features, such as UEFI secure boot or encrypted disks, is likely to break it.

What now?

The Linux community is full of users who are happy to experiment with this kind of feature and know how to avoid losing data if something explodes. Silently hibernating all systems after three hours of suspension, though, will widely expand the group performing such experiments, bringing in users who are rather less adventurous and who are not prepared for things to fail when they open their laptops in the morning. It is, in other words, the kind of feature that seems likely to swell the ranks of former desktop Linux users.

Most of the participants in the discussion were fairly quick to reach the conclusion that suspend-then-hibernate is not an appropriate feature to silently add to every user's system with no option to turn it off. Some, such as Matthias Clasen disagreed, though, saying: "If it works, why should we make it configurable? I don't think anybody wants their battery drained". But from there opinions diverged somewhat.

The addition of this feature to Fedora came about in two steps. The first was addition of a suspend-to-hibernate command (later renamed suspend-then-hibernate) to systemd. The GNOME developers noticed this feature, and added a patch to automatically use it, instead of ordinary suspend, when it is available. Since GNOME chose to start using this feature, and since GNOME provides the control interface that users see, it seems natural to think that GNOME's interface should provide control over whether suspend-then-hibernate is used. But, it appears, the GNOME developers disagree with that idea.

In particular, two GNOME developers, Bastien Nocera and Clasen, argued that if this particular systemd feature does not work reliably, it should be disabled in systemd rather than in GNOME. Neither seems to see any other reason why users might want to disable its use or have any control over it in general. Nocera seems to have a longer-term grudge against Fedora's handling of power management that isn't helping here. Matthew Miller, meanwhile, has argued for some sort of easy user control that "ideally does not involve the command line", which would suggest that something needs to be made available in the GNOME interface somewhere if the feature is not to be disabled altogether.

As of this writing, what will happen next is not entirely clear. The opposition from the GNOME developers makes it relatively unlikely that control over suspend-then-hibernate will be provided at that level. In the short term, that may not matter, as few people who have looked at the situation seem to think that this feature is ready to inflict on users. So the right answer for Fedora 29 may be to just turn it off entirely.

For the longer term, a few different approaches have been suggested. Lennart Poettering posted a list of changes that, he thinks, might make the feature safe to turn on. Chris Murphy, instead, has proposed that GNOME adopt an API allowing applications to save and restore their state; he pointed out that systems like Android do not use hibernation, and suggested that GNOME-based systems should take a similar approach. That, however, would require a lot of work and is clearly not a short-term solution. Williamson suggested looking at "hybrid sleep" (where the system writes the hibernation image immediately, then suspends indefinitely) instead. Hybrid sleep would retain the resume latency of suspend, while only using the hibernation image as a last resort should the battery run out. Which of these ideas, if any, will gain traction is unclear at this point.

One of Fedora's goals is to be the first with useful new features, but this particular one appears to not be ready even for many early adopters. Indeed, unless priorities change and some serious effort goes into developing and testing hibernation, it may never truly be safe for the user community as a whole. But there is clearly an appetite for better desktop power management, so it is good that developers are starting to explore this space again.

to post comments

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 13:03 UTC (Mon) by cuboci (subscriber, #9641) [Link] (5 responses)

It seems to have found its way into Debian/unstable, as well. I had to turn it off by masking the appropriate systemd target (systemctl mask suspend-then-hibernate.target) because it was annoying me to no end to have to wait in the morning for the machine to be ready to use.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 18:16 UTC (Mon) by devil (guest, #99595) [Link] (4 responses)

Debian has it because it is a systemd.target. But it is inactive per default. You can check with 'systemctl show suspend-then-hibernate.target | grep -i activestate' on a freshly installed debian, no matter if sid, testing or stable. Debian's systemd maintainers are quite sensible in what they activate.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 7:40 UTC (Tue) by smcv (subscriber, #53363) [Link]

The systemd target is not normally used by systemd itself (all of the HandleWhatever options in /etc/systemd/logind.conf support "suspend-then-hibernate", but none of them have that as their default).

However, while a GNOME session is running, gnome-settings-daemon takes over responsibility for power policy (to make it configurable per-user), and gnome-settings-daemon 3.29/3.30 uses suspend-then-hibernate (if supported) in situations where previous versions would have used suspend: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issu...

Fedora reawakens the hibernation debate

Posted Sep 20, 2018 23:30 UTC (Thu) by gerdesj (subscriber, #5446) [Link] (2 responses)

$ cat /etc/os-release
NAME="Arch Linux"
...
$ systemctl show suspend-then-hibernate.target | grep -i activestate
ActiveState=inactive

Arch generally leaves things at upstream defaults but I have done no further research on this particular issue.

Fedora reawakens the hibernation debate

Posted Sep 20, 2018 23:42 UTC (Thu) by mchapman (subscriber, #66589) [Link]

Looking at the ActiveState for suspend-then-hibernate.target isn't particularly insightful. It will only be active when something chooses to actually start it, and after the system has been resumed and all of the units that it pulled in are stopped again it will become inactive again (since it has StopWhenUnneeded=yes). It's not the kind of target that is activated at boot.

So the command you've run there will produce the same output even on Linux distributions that have chosen to try it out.

Fedora reawakens the hibernation debate

Posted Sep 21, 2018 15:14 UTC (Fri) by ejona86 (subscriber, #43349) [Link]

I'm on Arch and noticed the change, probably due to the GNOME 3.30 update. I was a bit amazed that hibernate worked as I had configured a resume= partition on my kernel command line years ago when setting up my system but had never tested it. My only worry is about kernel updates preventing resume due to runtime vs /boot version mismatch.

But due to the longer resume time I almost immediately changed sleep.conf so that HibernateMode=suspend-to-both. My laptop drains power very slowly with suspend-to-mem such that in two years I've yet to run out of battery while suspended. So I might even disable hibernate completely. But it is a bit of a shame that I'd have to disable hibernate for the entire system via systemd just because of GNOME's behavior.

I'd probably be more likely to use it if it was based on battery level instead of time. But I believe that's generally infeasible.

And what about when a notebook is encrypted?

Posted Sep 17, 2018 13:11 UTC (Mon) by pbryan (guest, #3438) [Link] (19 responses)

When using encryption (incl. swap encryption), I wonder what happens. Writing the entire contents of memory (including volume encryption keys for currently mounted volumes) is not a good idea.

And what about when a notebook is encrypted?

Posted Sep 17, 2018 13:44 UTC (Mon) by mageta (subscriber, #89696) [Link] (14 responses)

Encrypt swap as well (on a laptop, something like: one boot-partition (unencrypted) and on big crypt-partition that contains a LVM PV, which contains multiple LVs, of which one is the swap; so you only have to enter one key). You'll need some form of InitRD to handle the decryption of swap (dracut can do this), before the kernel can use it to load the old memory-image, but that actually works reasonable well; tested it myself on my laptop.

And what about when a notebook is encrypted?

Posted Sep 17, 2018 14:20 UTC (Mon) by cesarb (subscriber, #6266) [Link] (8 responses)

> so you only have to enter one key

But you have to enter one key, potentially in public. With suspend-to-RAM you can enter the key once at home and suspend, it won't ask for the key again until it's turned off.

And what about when a notebook is encrypted?

Posted Sep 17, 2018 22:21 UTC (Mon) by ThinkRob (guest, #64513) [Link] (7 responses)

One man's feature is another's bug. At least with suspend to disk you still have to know one key. Suspend-to-RAM makes DMA-enabled attacks trivial (provided you can actually access a DMA-capable port with the machine intact, naturally.)

And what about when a notebook is encrypted?

Posted Sep 18, 2018 12:10 UTC (Tue) by farnz (subscriber, #17727) [Link] (6 responses)

You don't necessarily need the machine to be intact - cold boot attacks work against machines that you've disassembled, as long as the RAM has not lost power for "too long" since the key was last known to be present.

Thus, the truly paranoid disable suspend to RAM - they shut down and power off RAM themselves before letting the machine out of their sight.

And what about when a notebook is encrypted?

Posted Sep 18, 2018 17:53 UTC (Tue) by drag (guest, #31333) [Link] (5 responses)

Well they just run 'shutdown -h now' when they are finished and are going to use their device in a situation were they could lose physical control of it. They only would disable it if they think they could forget about it and want their system to shut off by default to avoid mistakes.

But because of all of this the whole 'having to type key in public situation' is a bit of a red herring. Encrypted drives are only really useful as a security measure when those drives are offline.

And what about when a notebook is encrypted?

Posted Sep 19, 2018 11:26 UTC (Wed) by nix (subscriber, #2304) [Link] (4 responses)

Quite. I'm still wondering about ways to make my encrypted backup drives invulnerable to an untargetted attacker who just decides to blat zeroes over every accessible block device. Is there some way to turn the USB port off, then on again? (It's connected to a hub, and I don't want to turn off the whole hub, so this gets a bit trickier... some way to make the blockdev vanish. I guess a simple rm or mv-out-of-sight-to-somewhere-not-in-/dev and then mknod or mv-back later on would do it, but that feels really disgusting.)

And what about when a notebook is encrypted?

Posted Sep 19, 2018 16:22 UTC (Wed) by zlynx (guest, #2285) [Link] (1 responses)

I was feeling paranoid about ransomware so I created a maze of automount directories with 999h timeouts for device UUIDs that don't exist.

It wouldn't help against direct block access though. Just scripts doing blind directory traversal.

And what about when a notebook is encrypted?

Posted Sep 19, 2018 18:00 UTC (Wed) by nix (subscriber, #2304) [Link]

I defended against *that* by mounting the backups in a separate filesystem namespace in which the backup server-side program (and bup-fsck etc) runs :)

And what about when a notebook is encrypted?

Posted Sep 22, 2018 14:20 UTC (Sat) by wtanksleyjr (subscriber, #74601) [Link] (1 responses)

This kind of attack is what Qubes-OS was designed to mitigate. It's not worth installing if that's the _only_ attack you're worried about, but then I doubt that's the case.

And what about when a notebook is encrypted?

Posted Sep 23, 2018 18:29 UTC (Sun) by nix (subscriber, #2304) [Link]

My impression of Qubes is that it's more or less designed for high-end desktops. Servers that run heaps of virtual machines and also run the backups and do network file storage are... probably not really something Qubes would be good at for other reasons entirely. (Not that I've ever had a machine capable of *running* Qubes.)

And what about when a notebook is encrypted?

Posted Sep 18, 2018 18:40 UTC (Tue) by derobert (subscriber, #89569) [Link] (4 responses)

You don't even need an unencrypted /boot; just Grub. Grub gets updated a lot less frequently than the kernel, so if you need to do something special (e.g., sign it so you can use secure boot with your own keys), much less work.

So you can have:

/dev/sda1 EFI system partition / BIOS boot area (depending on if using EFI boot)
/dev/sda2 LUKS → LVM → /boot, /, swap, etc.

and Grub knows how to ask for the LUKS passphrase, decrypt it, find the LV for / or /boot and load the kernel and initramfs from that. It then boots the initramfs, which can have a keyscript or file on it (since, remember, the initramfs is encrypted) which lets the initramfs open the LUKS volume, set up LVM and (at least on Debian) resume from hibernate to that encrypted swap. This setup does require a little bit of config file editing; Debian-Installer will not set it up for you (mainly, it doesn't know the set the flag in the Grub config to enable LUKS) — other than that, it leaves you with an enter-passphrase-twice setup, then you set up a keyscript or file to fix that.

My experience with hibernation is it just works, though that's on Debian. Which, as noted, uses a different initramfs system.

And what about when a notebook is encrypted?

Posted Sep 23, 2018 22:27 UTC (Sun) by rra (subscriber, #99804) [Link] (3 responses)

> My experience with hibernation is it just works, though that's on Debian. Which, as noted, uses a different initramfs system.

Yeah, same here. I was very surprised by the assertion in the article that hibernate is largely unsupported and unreliable, since it just works for me and has for years on various different laptops. But this is with Debian.

That said, it's good to know that the kernel upstream is focusing primarily on suspend, since I was only using hibernate on a mild general principle of not using up power that I didn't need to use up. Maybe I'll experiment with using suspend instead for a while.

And what about when a notebook is encrypted?

Posted Sep 24, 2018 16:45 UTC (Mon) by cavok (subscriber, #33216) [Link]

I am a very happy user of s2both, provided by swsusp if I'm not wrong. It writes the state to ram and disk. It even warns if you pickup the wrong kernel after a power interruption while suspended-hibernates. It resists to corruption/loss even in case of "different machine" (my Debian 9 lives/suspends/hibernates on an external usb3 ssd).

And what about when a notebook is encrypted?

Posted Sep 24, 2018 22:42 UTC (Mon) by mstone_ (subscriber, #66309) [Link] (1 responses)

it's basically luck of the hardware. it's been years since I successfully hibernated a debian system.

And what about when a notebook is encrypted?

Posted Nov 22, 2018 12:36 UTC (Thu) by m_a_s (guest, #128777) [Link]

Same here. I eventually migrated to Fedora because of this.

And what about when a notebook is encrypted?

Posted Sep 17, 2018 22:27 UTC (Mon) by ThinkRob (guest, #64513) [Link] (3 responses)

For the paranoid (properly, or otherwise) among us, the idea of RAM being written out in whole to disk is a scary one even if it is -- in theory -- done safely. You're only one configuration bug or one non-public exploit away from someone getting a complete memory image.

Plus it -- again in theory -- opens you up to known-plaintext attacks. If you know a box is running $OS_VERSION then you know the contents of a ton of stuff that's going to be in memory. Shared libs alone would give you hundreds of megs of known plaintext on your standard Fedora/GNOME install. And while AES-256 in XTS mode isn't vulnerable to known plaintext attacks at the moment (as far as I know), I would venture a guess that some folks might not want to tempt fate.

Personally the security angle doesn't bother me much, provided Fedora implements it right. My only main concern is that it's bloody useless for me, hence I hope it's made (and stays!) configurable. My laptop loses ≤ 1% of battery when left off overnight, and with some 75+Wh of charge available, this is solving a non-issue... at the cost of a rather annoying wait time when I do want to start using my laptop. So here's hoping that it can be turned off!

And what about when a notebook is encrypted?

Posted Sep 18, 2018 16:01 UTC (Tue) by epa (subscriber, #39769) [Link] (2 responses)

Presumably a known-plaintext attack could be mitigated a bit if you compress the memory dump before writing it to disk. A sliding-window compressor could be seeded with a fairly random initial window, or some small nondeterminism could be added to the construction of frequency tables for Huffman coding. Or do these ideas fall under the category of "please don't roll your own crypto"?

And what about when a notebook is encrypted?

Posted Sep 18, 2018 16:32 UTC (Tue) by hkario (subscriber, #94864) [Link]

CRIME showed that compression is not a workaround for leaky encryption

And what about when a notebook is encrypted?

Posted Sep 21, 2018 16:50 UTC (Fri) by ThinkRob (guest, #64513) [Link]

Or do these ideas fall under the category of "please don't roll your own crypto"?

I'd say so.

There probably are ways to defend against this though. Plus, AFAIK there aren't any significant known plaintext attacks against AES256 in XTS mode. And since this isn't a long-term storage situation but rather a short term one it's not like we have to worry about an exploit twenty years from now putting our data at risk.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 13:40 UTC (Mon) by cortana (subscriber, #24596) [Link] (4 responses)

Enabling Secure Boot should have the desirable side-effect of disabling hibernation... :)

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 13:48 UTC (Mon) by bandrami (guest, #94229) [Link]

IDK. The line between hibernation and session persistence is a fuzzy one, and people seem to like session persistence.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 17:24 UTC (Mon) by pkern (subscriber, #32883) [Link]

Windows does this just fine on a Secure Boot system. In fact it exactly does suspend then hibernate if you wait too long.

Fedora reawakens the hibernation debate

Posted Sep 20, 2018 14:37 UTC (Thu) by yaap (subscriber, #71398) [Link] (1 responses)

Secure boot disabling hibernation is something I find frustrating. I understand the rationale to do this by default, as it's difficult to know if the location where the RAM is saved is secured.

But with Debian at least, it's not a problem to have the swap (used for hibernation) on a LUKS partition. The Debian initrd just ask for the key at boot, and resume works perfectly fine. So the hibernation data is as safe as the OS itself. In this case, it would be nice to be able to say "don't disable hibernation" while using secure boot, with some kernel parameter for example (if such way exists, I missed it). So keep the current default, but offer a way to bypass it if needed.

As it is, I have to keep secure boot disabled to use hibernate.

Fedora reawakens the hibernation debate

Posted Sep 21, 2018 8:04 UTC (Fri) by cortana (subscriber, #24596) [Link]

I wonder how Windows does it. Also whether, upon hibernation a new key can be generated for the hibernation data, and then stored in the TPM to be used to recover on the next boot without human intervention.

OTOH, maybe this is all pointless given the increasing accessibility of cold boot attacks... after reading e.g., <https://thehackernews.com/2018/09/cold-boot-attack-encryp...> I wonder if the days of having the encryption key ever stored in RAM need to come to a close.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 13:48 UTC (Mon) by ptman (subscriber, #57271) [Link]

What kind of flexibility does a suspended system have? Is there just a timer that wakes up after three hours and suspends? Or can it monitor battery status and suspend if it drops below a threshold?

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 14:38 UTC (Mon) by smurf (subscriber, #17840) [Link] (11 responses)

The GNOME developers in question should perhaps explain how systemd is supposed to discover whether hibernation works reliably.

There are enough laptops out there where hibernation works 95% of the time.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 17:03 UTC (Mon) by MarcB (subscriber, #101804) [Link]

Yes, or systems where it works exactly once per power-cycle. Or where it only works when using either the free or the proprietary graphics driver - with the possibility of reversing the roles upon updating both drivers.

I always wondered, whether "works" - "works not" could be used to feed an RNG with some strong entropy.

SSDs + Systemd + "crash safe" applications(*) have now mostly "solved" the problem for me .

(*) IDE and Browser handle it fine. Good enough for me.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 20:37 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

> There are enough laptops out there where hibernation works 95% of the time.

So in your experience, suspend-to-RAM work more reliably than suspend-to-disk ?

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 22:02 UTC (Mon) by ncm (guest, #165) [Link]

Of course. It has been quite some years since suspend-to-RAM has failed, for me. And as long since I last tried to get hibernation to work.

That said, I usually could get hibernation working, with enough effort. I had learned to avoid Nvidia, and the i915 driver was getting pretty OK (meaning it would wake up from suspend-to-RAM as often as from hibernation).

Even when both worked, I never got it to switch reliably from suspended to hibernating when the battery got low. But I don't doubt somebody did.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 22:47 UTC (Mon) by ebassi (subscriber, #54855) [Link] (6 responses)

how systemd is supposed to discover whether hibernation works reliably

systemd includes a hardware quirks database (hwdb) and a kernel/userspace device matching system (udev), so it's perfectly positioned to know if some hardware supports hibernation reliably or not.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 23:34 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (3 responses)

Based on the combination of hardware, firmware version and kernel version?

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 10:25 UTC (Tue) by ebassi (subscriber, #54855) [Link] (2 responses)

I mean: if the kernel wants to detect that, since it has access to all those three items, then it's also fine by me.

It's unlikely that GNOME, or any other high level user space UI, would be able to access those three things without building a huge quirks database anyway, so might as well defer to components that already have that database.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 16:12 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

No component has the necessary information to determine that hibernation will work reliably.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 20:27 UTC (Tue) by madscientist (subscriber, #16861) [Link]

Great if there's some component on the system that can provide a best-guess as to whether it would work or not.

But, how about deferring to ME for the final decision, rather than some probably-out-of-date and not-quite-complete static database, regardless of where it lives?

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 17:29 UTC (Tue) by mbiebl (subscriber, #41876) [Link] (1 responses)

We had such a quirks database with hal. I don't want to go back there.

Imho this is rather simple: GNOME should default to suspend-to-ram and only offer suspend-then-hibernate as an option.

Fedora reawakens the hibernation debate

Posted Sep 21, 2018 2:55 UTC (Fri) by flussence (guest, #85566) [Link]

udev having a quirks database isn't “going back to HAL” — it's keeping us out of the 2.4 dark ages where everyone had to hand-roll their modprobe script, xfree86.conf and asound.conf if they wanted hardware from $overpriced-PC-brand to work sanely.

Take an actual look in /lib/udev/hwdb.d/ (or /usr/share/{libinput,alsa,X11}/) sometime and marvel at how many $1000+ laptops have broken input and output devices that you haven't had to know about in 10 years or more, because someone else has gone through the pain for you (and BSD users!)

And this is just the userspace side of it; the kernel has its *own* quirks lists for really bad hardware like those self-bricking Intel NICs.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 1:24 UTC (Tue) by hp (guest, #5220) [Link]

The API GNOME is using appears to have two methods, "CanSuspendThenHibernate" and "SuspendThenHibernate"
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/comm...

In that code it looks like GNOME does "if (CanSuspendThenHibernate) { SuspendThenHibernate }" which, you know, seems reasonable.

If the implementation doesn't know whether it can SuspendThenHibernate (without crashing, to some degree of certainty), I'd say CanSuspendThenHibernate should return false.

If the only way to know whether CanSuspendThenHibernate is for a user to try to hibernate a bunch of times themselves and see if it fails, then the SuspendThenHibernate feature doesn't exist for all practical purposes - better for CanSuspendThenHibernate to always return false, or maybe always return false unless it's been manually enabled through some system-level configuration file.

If CanSuspendThenHibernate can't be trusted then it becomes impossible to ever enable the feature through system-level config or hardware quirks, because GNOME and others would have to ignore that API entirely. Better for everyone to use the API, and then fix the API (even if the fix is a config option, the option should configure the canonical API, rather than configuring only certain apps or certain desktops).

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 15:47 UTC (Mon) by ncm (guest, #165) [Link] (8 responses)

If I needed another reason to stop using Gnome, this would do it.

The degree of contempt that Gnome developers exhibit toward their users is breathtaking, and not a little boggling, but rather reminiscent of Apple. Fortunately, when we cannot turn off their "features", we can turn off Gnome itself.

The question that remains is why anybody stays on Gnome. Maybe for the same reasons people stay on Apple, that also escape me. I speculate that people stay with Apple because they know it cannot be made to do what they want, no matter how they try, but that they can learn to live with what it does; and that saves them from spending time trying. Some Apple users I have quizzed agreed.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 15:59 UTC (Mon) by epa (subscriber, #39769) [Link]

Apple at least have known hardware to work with. They can tune the settings on Mac OS for a particular laptop model (of which they have only about 50 to support) and it will work reliably. In the PC world, and especially with Linux, you have to have more configuration settings because hardware is much more variable. Even though many users would prefer not to have to mess with so many buttons and levers.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 17:08 UTC (Mon) by johannbg (guest, #65743) [Link]

The reason for that is simple for whatever reasons wayback then distributions decided to use Gnome as their default desktop environment and that decision afaik has never been proparly re-evaluated in distributions since.

That strikes me as bit odd since Gnome has been continious beta stage since it's inception and god forbid that they add knobs to toggle for their only ever existing user base which are advanced users (One would have thought that an existance of an application like GNOME Tweak Tool would have sent a clear message to the community that they were doing it wrong but apparently thats not enough ) since the entire community lacks the necessary development discipline to be able to produce a product that is usable for a novice end users or just users in general that dont want to be fighting their DE just to have a functional environment to do their work in.

Computers are supposed to make users work easier not harder.

Anyway it serves no purpose bothering with any DE on linux other than those that run on android and provide a WIMP interface on top of that ( like samsungs dex etc ) because that what the consumer wants thus that's where the future is and has been heading.

Fedora reawakens the hibernation debate

Posted Sep 17, 2018 17:35 UTC (Mon) by yuuyuu (guest, #127230) [Link] (5 responses)

GNOME has always been against the spirit of empowering the user anyway, in the real sense. Instead of giving the user tools to compose a workflow that suits them best, and the "features" like these they'd like to turn on or off, they seem to be more focused on imposing a certain workflow, focusing on their brand, a certain way of doing things, in that you need to adapt to the way they envision GNOME to work.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 8:48 UTC (Tue) by mjthayer (guest, #39183) [Link] (3 responses)

> GNOME has always been against the spirit of empowering the user anyway, in the real sense. Instead of giving the user tools to compose a workflow that suits them best, and the "features" like these they'd like to turn on or off, they seem to be more focused on imposing a certain workflow, focusing on their brand, a certain way of doing things, in that you need to adapt to the way they envision GNOME to work.

Devil's advocate: someone who can look after themself can easily install what they need to make their system configurable to their heart's content, so they haven't lost much. Someone who cannot is probably better served by a simpler, less configurable system, even if it is not quite optimal for their needs. The standard system is also much better tested, which is a big plus for less capable users. So much the theory, I realise that the practice is probably far away.

I am in neither group: I am a capable user, but I do not want to waste time fiddling with my system or running into strange bugs because I tried out interesting options. I like being able to take a new system and be up and running in a couple of hours, and for that I am willing to adapt to the system rather than adapting it to me. So I am probably one of the small group who appreciates the way GNOME do things.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 9:45 UTC (Tue) by chris.sykes (guest, #54374) [Link]

I'm in the same camp - but I am starting to question if I might be better off running with the defaults of some other DE...

Stripping out configurability in favour of "sensible defaults" is one thing, but enabling a default behaviour that could result in data loss for their users is quite another. Logs filling with JavaScript stack traces every time I hit Alt-Tab is another motivator.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 16:13 UTC (Tue) by yuuyuu (guest, #127230) [Link] (1 responses)

To each their own ;-)

Fedora reawakens the hibernation debate

Posted Oct 13, 2018 21:47 UTC (Sat) by ssmith32 (subscriber, #72404) [Link]

Exactly :)

For me, it will even vary depending on the year.

Some years, like this one, I really don't want to be empowered on my desktop - as far as decisions, I have enough to be made elsewhere. I have a little cheat sheet with the gnome tweaks needed for alt-tab, etc, and then I move on.

And, yeah, Apple, because learning a bunch of random finger waving motions that you throw at some little touch pad is intuitive.. but some people love it.

And, on some years, I have installed Enlightenment (remember that?). KDE, I've even had to work in *C*DE (Solaris). I have Cinnamon in some places... Yeah, it varies.

At least we can chose our masters! ;)

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 22:35 UTC (Tue) by sorpigal (subscriber, #36106) [Link]

Not always, only recently (2.x and later). Sawfish was nice and configurable, for example.

suspend-to-disk not dead

Posted Sep 17, 2018 18:38 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

For what it is worth, I use suspend-to-disk exclusively since 1998 (yes before Linux kernel support. It was done directly by the BIOS). I never had any problem on high-quality hardware, and I do quite a lot of wake up (but then I do not use DE).
With a SSD the wake up time is quite acceptable.

Hybrid sleep is called s2both by uswsusp. This is not someting new either.

suspend-to-disk not dead

Posted Sep 17, 2018 20:05 UTC (Mon) by roblucid (guest, #48964) [Link]

I had to provide some info on a system, which had a Linux validation. IIRC it was an issue after BIOS updates and some kind of id's needed updating.

So systemd adds yet another option and feature, whilst GNOME supposed UI, refuses to let the User Interact, but decides systemd knows best .. meh

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 9:48 UTC (Tue) by mjthayer (guest, #39183) [Link] (3 responses)

> Chris Murphy, instead, has proposed that GNOME adopt an API allowing applications to save and restore their state; he pointed out that systems like Android do not use hibernation, and suggested that GNOME-based systems should take a similar approach. That, however, would require a lot of work and is clearly not a short-term solution.

A nice thing about save and restore though is that it does not have to be supported by every little thing to be useful. It is enough if the tools you use most often support it well enough, where doing auto-save and remembering which documents were open may be well enough in many cases (as a bonus the code paths can be shared with crash restore). And it is much more of a stable equilibrium: with hibernation countless small problems can make the whole thing useless, whereas problems with save and restore are more likely to only loose a little bit of state. The downside is that it needs fast boot times to be most useful.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 10:57 UTC (Tue) by jpnp (guest, #63341) [Link] (2 responses)

> The downside is that it needs fast boot times to be most useful.

But even then, you end up with a load of cold caches. It might be fine for the "I'm shutting down this laptop until I need it tomorrow" use case (even here note that Fedora users for whom hibernation works, but who were used to resuming a sleeping system in the morning were disappointed with the speed of unhibernating instead), but it's not necessarily so good for the "shut the laptop while I walk from my desk to the meeting room" use case.

Android is in a fundamentally different position, with its API having been designed for that model from the beginning. That said, I'd love to see more work on save/restore in linux DEs.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 19:08 UTC (Tue) by mjthayer (guest, #39183) [Link] (1 responses)

Could we agree that save and restore as a back-up for when the battery runs out during sleep would be a good thing?

Fedora reawakens the hibernation debate

Posted Sep 19, 2018 12:03 UTC (Wed) by jpnp (guest, #63341) [Link]

Absolutely. Save and restore is a good thing all round. Posix systems can't do what Android Apps do by default, but there's no reason why they can't individually support session restore, and indicate to the DE that they do. If enough do then it would be feasible for the OS/DE to respond to system memory pressure by closing such opted-in applications which are not showing. I would love to see progress here. Even teach bash to restore itself and the processes its running (a hard task in general no doubt). It's all a great insurance against system crashes of various sorts; I can't imagine using a text editor which doesn't keep recovery information.

I just don't think it's a replacement for system suspend. When I hit the power button and put my Android phone in my pocket, it's not actually closing apps never mind powering down the system, it's just putting them in a lower power state until I switch the screen back on.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 10:49 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (4 responses)

Even if hibernate works, I still want to have an option to control it. As was already pointed out in the comments above, hibernation requires to enter the disk encryption password and one may or may not want to do that depending on the situation. I prefer not to enter the strong password in a cafe or other places that may have high-resolution surveillance cameras, but it is OK to do it at home or in the office.

The only automatic behavior that is probably OK is to hibernate on a low battery. But even then I prefer to have an option to keep the ram powered on after the hibernation image is written until the battery runs out.

Fedora reawakens the hibernation debate

Posted Sep 19, 2018 3:10 UTC (Wed) by zblaxell (subscriber, #26385) [Link] (3 responses)

> The only automatic behavior that is probably OK is to hibernate on a low battery.

Bad idea. You don't know the operating environment in that situation. The laptop could be embedded in luggage with no possibility of cooling. If the laptop wakes up and hibernation hangs (e.g. because the CPU overheats itself compressing and encrypting hibernation data), the resulting confined heat will damage the hardware until the battery gives up. Usually nothing as spectacular as a fire happens, but each incident typically wipes a few percent off the battery capacity. I once had a Macbook wipe out 80% of its battery capacity in one day doing that (Linux has no monopoly on hibernate bugs).

Back in the days of spinning rust in laptops you could break the hard drives with surprise hibernations too. Even today a hot SSD is not a happy SSD, and severe data loss can be expected.

Current laptops can sit for days in suspend state. Heck, some of them now run 24+ hours while displaying a login prompt. I hardly use suspend for anything less than international travel, and I only use hibernation for dual-booting tool when a VM won't do the job.

Fedora reawakens the hibernation debate

Posted Sep 19, 2018 4:20 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

If your battery is down to 5% then your laptop probably won't have enough energy to overheat.

Fedora reawakens the hibernation debate

Posted Sep 19, 2018 4:35 UTC (Wed) by zblaxell (subscriber, #26385) [Link]

It's enough energy to run at full power for six minutes. With no cooling it'll easily push the air temperature in the case up to the 60C+ battery-life-shortening zone.

Fedora reawakens the hibernation debate

Posted Sep 19, 2018 12:37 UTC (Wed) by farnz (subscriber, #17727) [Link]

5% of a 50 Wh battery is still 10 kJ of energy that has to go somewhere. That's enough to push a laptop's temperature up by at least 10°C, if not more (depending on what the laptop is made of).

And note that a 50 Wh battery is not large, nor is it likely that a bag squeezed against someone's back is a cool place to begin with.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 15:16 UTC (Tue) by oever (guest, #987) [Link] (2 responses)

> Chris Murphy, instead, has proposed that GNOME adopt an API allowing applications to save and restore their state

This would be very valuable for applications, not just for resuming from suspend or hibernate.

X and Wayland still cannot handle dynamic DPI changes in applications. The problem is in the applications: there is no way to tell an application that a window has moved to a screen with higher DPI and that it should adopt the font-size and layout. If an application can save state and be restarted from that state, but with a different DPI, then the application can adapt to a changing DPI.

A use-case is a setup with a 1920x1080 laptop screen and a 4K (3840x2160) desktop screen. On 4K a 24px font is reasonable. But when the screen is unplugged, the font size stays 24px which is far too large for a 1920x1080 screen.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 20:49 UTC (Tue) by zlynx (guest, #2285) [Link] (1 responses)

Wayland apps, specifically gnome-terminal, seem to adapt to DPI changes just fine.

It is the XWayland apps that seem to have the problem. For pure X sessions I've seen people recommend running at 4K all the time even on 1080p screens, using xrandr to scale the 4K to 1080p. That way everything is ready to jump to 4K on demand.

Fedora reawakens the hibernation debate

Posted Sep 19, 2018 7:17 UTC (Wed) by oever (guest, #987) [Link]

How does gnome-terminal adapt to DPI?

To adapt to a DPI change safely in font rendering would require that the font data structures get reinitialized.

I've thought about setting everything to 4K all the time but have not figured out how to do that yet. It would of course use a lot of unneeded CPU/GPU.

My current idea for a workable approach is to use a compromise font size for the UI, write a script to restart apps that have good session management and another script that changes the font-size in konsole via dbus.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 16:13 UTC (Tue) by flussence (guest, #85566) [Link] (3 responses)

It seems like the cause of complaint is the fixed 3 hour delay before hibernating. Given that Fedora runs the full udev/upower/whatever stack of clever code, couldn't that just learn the battery discharge curve and then set an alarm to do the hibernation when it's down to 5 minutes remaining? For most people it'll go back to the normal behaviour, while providing an actually useful safety net, plus people would be able to associate “no blinking standby light” with “time to plug in”.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 18:27 UTC (Tue) by ocrete (subscriber, #107180) [Link] (1 responses)

That behaviour would be amazing, I'd even be ready to pay the penalty of waking up the laptop once in a while, checking the battery status and re-suspending..

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 19:42 UTC (Tue) by k8to (guest, #15413) [Link]

For reference, I had a mac that behaved this way. It was pretty irritating.

When I went to work in the morning, the laptop would invariably be 5 minutes from auto-shutdown, and suspended too, eating up 2 of those 5 minutes to do the launch from disk. I couldn't even check email during the commute.

Obviously this could be mitigated with configuration, but I'm not sure it would make most people happy.

Fedora reawakens the hibernation debate

Posted Sep 18, 2018 19:43 UTC (Tue) by mageta (subscriber, #89696) [Link]

Thats a pretty good idea actually, if workable.

How to avoid hibernating when battery is low

Posted Sep 20, 2018 10:20 UTC (Thu) by ededu (guest, #64107) [Link] (1 responses)

I am a happy user using exclusively suspend-to-RAM, and use it very often (going to lunch, moving in a different office, during night). The problem I have is that, even if in suspend state, my Lenovo system with debian wakes up when the battery is exactly 7% and tries hibernation, which I have never configured (and do not want it either) and a few minutes later it runs out of energy. May I ask how can I remove this "functionality" so that it never wakes up? I looked at numerous files and Web pages without finding the answer.

How to avoid hibernating when battery is low

Posted Sep 21, 2018 0:48 UTC (Fri) by zlynx (guest, #2285) [Link]

If it wakes up at a certain battery level, it is almost certainly the UEFI / BIOS doing it. There is probably a setting in there somewhere. My Dell XPS has 20 pages of UEFI settings for various things.

If you don't like hibernate then I'd recommend that you set it to forcefully power down. Because you don't want your battery actually going to 0%. It is very bad for a lithium ion battery to fully discharge.

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 8:51 UTC (Mon) by rjw@sisk.pl (subscriber, #39252) [Link]

While it is true that distributions did not care much about hibernation in general until relatively recently, I can't agree with the statement that it has been neglected for the last few years. In fact, it is actively maintained and under active development too, at least at the kernel level.

For example, in 2016 LWN.net ran an article regarding it (https://lwn.net/Articles/701639/) and two hibernation-specific patch sets have been posted recently (https://patchwork.kernel.org/project/linux-pm/list/?serie... and https://patchwork.kernel.org/project/linux-pm/list/?serie... - the most recent version of the former is in linux-next now). ARM64 support for hibernation was added in 2016 too.

Apart from that, many changes related to system-wide suspend also affect hibernation, since they both share the core code for handling devices. Moreover, the helper macros for setting PM callbacks used by device drivers are designed to cover hibernation too, so driver changes made to support system-wide suspend often cover hibernation automatically and no more hibernation-specific work is needed in the given driver.

Admittedly, image encryption is only supported via the user-space tools (suspend-utils) which is somewhat cumbersome to set up, but it's been there for the last 7 years at least. While hibernation as implemented in the mainline kernel doesn't work with UEFI secure boot at this time, SUSE has been carrying an out-of-the-tree set of patches to implement that for a couple of years (as far as I can say) and work on adding that support to the mainline is in progress.

Given a typical swap configuration, hibernation should work on all systems where system-wide suspend works and it may work on some systems where system-wide suspend doesn't work too (one of them is under my desk right now, actually). I use it on a daily basis with no problems at all.

Generally, hibernation is regarded as a supported feature of the Linux kernel. Problems with it should be reported (either to linux-pm@vger.kernel.org or through the kernel Bugzilla) and they will be taken care of, subject to prioritization.

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 17:15 UTC (Mon) by mcortese (guest, #52099) [Link] (14 responses)

I'm confused. Doesn't resuming from hibernation require a resume= parameter passed to the kernel at boot? How is GNOME or systemd supposed to set (or check) that parameter before enabling hibernation?

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 17:46 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

There's an ioctl() that allows to set this parameter on the running kernel.

It's been broken for ages for hibernation files, though.

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 18:59 UTC (Mon) by mcortese (guest, #52099) [Link] (8 responses)

But when in the boot process is that ioctl() called?

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 19:01 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

I would expect in initrd. It then will load the old kernel and replace the running image.

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 21:18 UTC (Mon) by mcortese (guest, #52099) [Link] (6 responses)

Then I need to rephrase my original question: how can GNOME or systemd set (or check) initrd to include the resume part?

Fedora reawakens the hibernation debate

Posted Oct 8, 2018 21:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

The way I would do it - create a flag file on the root partition of the system, so during the boot up the initramfs mounts the root volume as RO and checks for this flag. If it can find it, it reads the suspend image and checks for the presence of the suspend signature.

If it's present, attempt the resume (via another IOCTL). The kernel reads the saved image, does the CRC check and if everything is OK the control is transferred to the saved image.

Fedora reawakens the hibernation debate

Posted Oct 9, 2018 16:22 UTC (Tue) by mcortese (guest, #52099) [Link] (4 responses)

I see so many ways this approach can fail.

Mounting root... But root could be in a non-clean state.

Initramfs... So now systemd or GNOME depends on Initramfs? Last time I checked, Debian packages had no dependence on a specific version of the kernel. Or on the existence of a boot partition or of a specific bootloader.

In fact I have run a Debian system for years (systemd & GNOME) with no initramfs, no boot partition except EFI, and no bootloader. I guess I'd better think twice before upgrading to GNOME 3.30... :)

Fedora reawakens the hibernation debate

Posted Oct 9, 2018 17:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

If root is a non-clean state then you can’t use it for resume anyway, so no problem here.

Fedora reawakens the hibernation debate

Posted Oct 11, 2018 21:17 UTC (Thu) by mcortese (guest, #52099) [Link] (2 responses)

> If root is a non-clean state then you can’t use it for resume anyway, so no problem here

Why? At any time the fs on disk can be non-clean while the vfs has pending changes not landed on disk yet. If the system is suspended in that moment, it's frozen in that precise state. If it's then hibernated, that state is written to swap.

For resume to work in such case, neither the kernel nor the initramfs must reside in the root fs.

This is just an example of the several conditions systemd should check before asserting that the system is ready for hibernation. Now, after reading the whole Fedora thread, I understand that systemd does nothing more than checking if the free swap is equal or greater than the used RAM. So when it says "CanHibernate" it actually means: this system *could* be configured to hibernate but I have no idea if it really is.

My opinion is that GNOME should not silently default to use hibernation only based on systemd's CanHibernate flag.

Fedora reawakens the hibernation debate

Posted Oct 11, 2018 21:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

As a part of the hibernation process the pending writes are flushed and the IO is quiesced. So if you have a dirty FS then you can be sure that it's not been used for hibernation.

Fedora reawakens the hibernation debate

Posted Oct 13, 2018 19:18 UTC (Sat) by mcortese (guest, #52099) [Link]

I didn't know that. Thanks for pointing it out.

So, while suspend & resume is nearly transparent for the running processes, hibernate & resume heavily changes the system's internal state.

I wonder if hibernation can stall in case of big IO backlog?

Fedora reawakens the hibernation debate

Posted Oct 10, 2018 15:30 UTC (Wed) by cortana (subscriber, #24596) [Link] (3 responses)

It's not done by GNOME/systemd but by the installation process. You mention you're on a Debian system. In your case, the installer would have set RESUME= in /etc/initramfs-tools/conf.d/resume to point to a swap device. This is copied into the initramfs when it is generated. At boot time, /usr/share/initramfs-tools/scripts/local-premount/resume makes that device available and then uses klibc's resume command to actaully perform the resume by writing the swap devices's major:minor:offset to /sys/power/resume.

Fedora reawakens the hibernation debate

Posted Oct 13, 2018 18:05 UTC (Sat) by mcortese (guest, #52099) [Link] (2 responses)

Thank you for your explanation.

I still think it's fragile. This behavior of GNOME implicitly depends on initramfs. I think it should be made evident with a Depends-type relationship between the relative packages, otherwise a user could be tempted to use a kernel that doesn't need any initramfs and lose her unsaved data the first time she suspends her laptop for 3 hours after upgrading GNOME!

Fedora reawakens the hibernation debate

Posted Oct 16, 2018 8:32 UTC (Tue) by cortana (subscriber, #24596) [Link] (1 responses)

I'm sure the systemd folks would welcome patches to make logind's CanHibernate logic more robust!

Fedora reawakens the hibernation debate

Posted Oct 17, 2018 6:47 UTC (Wed) by mcortese (guest, #52099) [Link]

No automatic tool can detect if all the pieces are in place for a successful resume. The only sane choice would be to default to No unless the user explicitly opts in.