LWN: Comments on "Fedora reawakens the hibernation debate"

And what about when a notebook is encrypted?

m_a_s — Thu, 22 Nov 2018 12:36:04 +0000

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

Fedora reawakens the hibernation debate

mcortese — Wed, 17 Oct 2018 06:47:06 +0000

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.

Fedora reawakens the hibernation debate

cortana — Tue, 16 Oct 2018 08:32:23 +0000

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

Fedora reawakens the hibernation debate

ssmith32 — Sat, 13 Oct 2018 21:47:50 +0000

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

mcortese — Sat, 13 Oct 2018 19:18:43 +0000

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

mcortese — Sat, 13 Oct 2018 18:05:47 +0000

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

Cyberax — Thu, 11 Oct 2018 21:21:22 +0000

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

mcortese — Thu, 11 Oct 2018 21:17:33 +0000

> 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

cortana — Wed, 10 Oct 2018 15:30:47 +0000

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

Cyberax — Tue, 09 Oct 2018 17:12:59 +0000

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

mcortese — Tue, 09 Oct 2018 16:22:09 +0000

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

Cyberax — Mon, 08 Oct 2018 21:56:30 +0000

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

mcortese — Mon, 08 Oct 2018 21:18:41 +0000

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

Cyberax — Mon, 08 Oct 2018 19:01:24 +0000

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

Fedora reawakens the hibernation debate

mcortese — Mon, 08 Oct 2018 18:59:28 +0000

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

Fedora reawakens the hibernation debate

Cyberax — Mon, 08 Oct 2018 17:46:10 +0000

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

mcortese — Mon, 08 Oct 2018 17:15:14 +0000

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

rjw@sisk.pl — Mon, 08 Oct 2018 08:51:54 +0000

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.

And what about when a notebook is encrypted?

mstone_ — Mon, 24 Sep 2018 22:42:30 +0000

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?

cavok — Mon, 24 Sep 2018 16:45:47 +0000

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?

rra — Sun, 23 Sep 2018 22:27:18 +0000

> 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?

nix — Sun, 23 Sep 2018 18:29:42 +0000

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?

wtanksleyjr — Sat, 22 Sep 2018 14:20:06 +0000

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?

ThinkRob — Fri, 21 Sep 2018 16:50:24 +0000

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

ejona86 — Fri, 21 Sep 2018 15:14:44 +0000

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.

Fedora reawakens the hibernation debate

cortana — Fri, 21 Sep 2018 08:04:50 +0000

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

flussence — Fri, 21 Sep 2018 02:55:11 +0000

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.

How to avoid hibernating when battery is low

zlynx — Fri, 21 Sep 2018 00:48:59 +0000

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

mchapman — Thu, 20 Sep 2018 23:42:02 +0000

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

gerdesj — Thu, 20 Sep 2018 23:30:09 +0000

$ 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

yaap — Thu, 20 Sep 2018 14:37:16 +0000

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.

How to avoid hibernating when battery is low

ededu — Thu, 20 Sep 2018 10:20:45 +0000

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.

And what about when a notebook is encrypted?

nix — Wed, 19 Sep 2018 18:00:34 +0000

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?

zlynx — Wed, 19 Sep 2018 16:22:39 +0000

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.

Fedora reawakens the hibernation debate

farnz — Wed, 19 Sep 2018 12:37:18 +0000

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

jpnp — Wed, 19 Sep 2018 12:03:42 +0000

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.

And what about when a notebook is encrypted?

nix — Wed, 19 Sep 2018 11:26:17 +0000

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.)

Fedora reawakens the hibernation debate

oever — Wed, 19 Sep 2018 07:17:14 +0000

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

zblaxell — Wed, 19 Sep 2018 04:35:15 +0000

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

Cyberax — Wed, 19 Sep 2018 04:20:07 +0000

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