Since I was using almost exclusively laptops since 2001, I failed to notice that in Linux, suspend-to-disk (hibernation) lost momentum, as everyone is using suspend-to-RAM (sleep). This is a huge regression, and not just in Linux, but in human intelligence altogether.

The good old times and the rationale

I don’t remember since when I decided that I can’t live without hibernation. What I remember for sure is that in 2006-2008 I was insisting on checking that every single Linux distro I tried was able to hibernate correctly.

Meanwhile, since “PC” nowadays means “laptop” (at Microsoft they even call their Surface shit a “PC”!), and since any laptop has a battery, the hibernation (suspend-to-disk) became less and less used, being replaced by sleep (suspend-to-RAM), although at some point the more intelligent hybrid sleep (suspend to RAM, but then also to disk, just in case the battery dies) was preferred.

I can understand why for a laptop most people would prefer to suspend-to-RAM: first, there’s a battery, and secondly, resuming from disk can be slow for those having 16 GB or 32 GB of RAM, even if the disk is a SSD.

But then, how about people who still want to use a “desktop” PC, being it a very small one (or even smaller, but please, not those based on Intel Celeron J4125)? Practically nobody has a UPS at home, but even if they had one: for a desktop/tower PC, the right solution isn’t a “warm” sleep, but a “cold” one, i.e. hibernation, or maybe a hybrid sleep!

In Windows 7 to 10, even if the “warm” sleep is the default, the hybrid sleep and the immediate hibernation can easily be enabled. 30 years into Linux, I’d have expected to be the same in most Linux distros.

Well, not anymore!

The worst surprise I ever had with Linux

The worst regression I’ve encountered in 26 years since I first met Linux was to notice that nowadays, most distro maintainers don’t give a shit about hibernation, and most users don’t care either! And that’s across MOST distros!

This is unthinkable. They assume the “personal usage” scenario to mean a laptop on which only suspend-to-RAM is of interest (although I used to hibernate on a laptop too), and all the other usages being “business” ones (servers, containers, etc.), no kind of suspend is needed. Fuck me sideways.

Watch this average retard in his MX Linux review (XFCE & KDE) saying:

[…] MX Linux does not have hibernation enabled by default. […] And I think this is very good, because hibernation often doesn’t work right in Linux, unfortunately. Some new users may hibernate their systems, and then they may encounter problems. But since this is disabled by default, new users are safe from those mistakes. But they can suspend their system, which is very similar to hibernate. […] I even recommended to disable hibernation in some of my videos, for example on Linux Mint. But in MX Linux, you have hibernation disabled by default. And this is very good.

But this cretinoid isn’t the only brain-dead Linux aficionado out there. Here’s a Manjaro forum thread on… [HowTo] Disable / Turn off Hibernate completely!

Hands-on experiences

What I tried these days was limited in scope.

1. Linux Mint

I couldn’t be bothered to install it, because it’s basically nothing more than:

  • Ubuntu 20.04 LTS, therefore with old versions of everything;
  • with some unnecessary themes, ugly customizations, and extra tools, some of which are great apps “Made by Mint”: Warpinator, Hypnotix, xed, xreader;
  • with the continuously updated “Made by Mint” desktop environment Cinnamon (which I can live without);
  • with, fortunately, an XFCE updated from Ubuntu’s 4.14 to the latest 4.16.

But I know they don’t help with configuring hibernation, so that people ask everywhere about how to enable it, even on Mint’s forums!

From outside their forums (written: Feb. 3, 2021; updated: April 19, 2021): How to enable Hibernate Mode on Linux Mint:

The hibernation feature support in Linux Mint is not out-of-the-box or an included default feature. You have to perform some technical maneuvers if you want to use it.

Indeed, installing Mint wouldn’t change the following logout screen in Mint XFCE, so no out-of-the-box hibernation:

Pathetic. Linux Mint was supposed to be “more user-friendly than Ubuntu”!

2. Ubuntu MATE

I reinstalled Ubuntu MATE 21.10 just to see whether the feeling of something well-known (GNOME2) could make me feel comfortable. Of course, back in the day the screens were 5:4 (1280×1024), not 16:9 (1920×1080), so using two panels would be crazy. I prefer the “Raymond” layout, which fortunately includes the Brisk menu (the old-style menu split in 3 menus isn’t practical, and a single menu without search capabilities isn’t good enough either).

The thing is, Ubuntu stopped caring about hibernation, and Ubuntu MATE is no exception: there’s no way to suspend other than to RAM!

Of course, searching about how to enable hibernation in Ubuntu would give gazillions of results, but most of them apply to the original (“non-flavored”) Ubuntu, and might include GNOME applets & stuff. For Ubuntu MATE, we have e.g.:

But… but… but… How can I add a “Hibernate” button somewhere? Whatever I tried, I wasn’t able to add a button anywhere: to the logout screen, to the Brisk menu, anywhere! Using sudo systemctl hibernate to hibernate is dumb, really dumb.

Fail.

3. MX Linux

OK, we already know MX doesn’t have the hibernation enabled by default, but MX Tweak, part of their MX Tools, has a nifty way of enabling it:

I had to look for it, though. And, of course, I had to have an appropriate swap partition.

Kinda winning for MX, hibernation-wise!

4. Fedora XFCE

First of all, Fedora enables all the buttons in XFCE’s logout screen, but the hibernation and the hybrid sleep don’t work.

The situation in Fedora is best summarized in a commentary from this reddit thread: Guide to configure Hibernation with Fedora 34:

Quite a bit of drama regarding the future of hibernation on Linux due to secureboot, zram, kernel support, system upgrades and “UX concerns”.

TLDR: Hibernation support is gone, for now.

This doesn’t mean hibernation can’t be made to work; what it means is that Fedora officially doesn’t care and won’t care about whoever wants, needs, or requires hibernation!

Someone wrote a relatively similar article here: Fedora34 hibernation. You might find some insights in the readers-added comments at the end! (ZRAM is one issue, but we’ll get to it later.)

Warning: should you follow exclusively the recommendation of some older articles such as this one, your system will hibernate, but it won’t resume! (initramfs won’t contain the resume module, that’s why.)

Digging a bit in the history, let’s find some references to the concept that “it’s better without hibernation” (the GNOME3 syndrome: the user needs fewer features!). Fedora Pagure #121 Support for hibernation?:

aday commented 2 years ago
On the UX side, we haven’t exposed a user-visible hibernate option for some time. The main reason for this is the profusion of end session options (log out, switch user, hibernate, suspend, power off) and the similarity of hibernate and suspend. This still feels like the correct decision.

We did recently have a very brief discussion about using hibernate in place of power off, and this is something I’m interested in as a way to improve the overall end/restart session experience. However, it’s still not clear exactly how feasible this would be or what would be involved.

catanzaro commented 2 years ago
I think it’s just not feasible, not unless we can convince the kernel developers to support hibernation on arbitrary hardware. They’re not going to want to do that, and it would probably be expensive to do.

OTOH, this is a bit of a PulseAudio chicken/egg situation, in which hibernation is never going to work reliably until some desktop decides to replace power off with hibernate. Then, suddenly people will hopefully be more interested in ensuring it works reliably.

Fothermuckers.

One more reference: How to enable hibernate mode in Fedora 33 with btrfs and zram/swap:

You need a physical swap partition for hibernation to work. I have both a swap partition and zram. Zram has higher priority for swap and the swap partition is only used for hibernation. Btrfs has nothing to do with this.

Yup. Look what I got for swap:

$ swapon
NAME TYPE SIZE USED PRIO
/dev/sda4 partition 8G 0B -2
/dev/zram0 partition 7.5G 0B 100

I don’t need the ZRAM shit, but it automatically enables itself on resume! Some zealot wanted SwapOnZRAM in Fedora 33, and so it was!

The zram device, typically /dev/zram0, has a size set at create time during early boot, by zram-generator per its configuration file. The memory used is not preallocated. It’s dynamically allocated and deallocated, on demand. Due to compression, a full /dev/zram0 uses half as much memory as its size.

The /dev/zram0 behaves like any other block device. It can be formatted with a file system, or mkswap, which is the intention with this change proposal.

The system will use RAM normally up until it’s full, and then start paging out to swap-on-zram, same as a conventional swap-on-drive. The zram driver starts to allocate memory at roughly 1/2 the rate of page outs, due to compression. But, there is no free lunch. This means swap-on-zram is not as effective at page eviction as swap-on-drive, the eviction rate is ~50% instead of 100%. But it is at least an order of magnitude faster than drive based swap.

While this seems to work, and, oversimplifying it, it tries to “double the memory” only when it’s becoming full, it has a familiar ring, un air de déjà vu for those who are old enough to remember these pieces of crap:

It’s a nightmare. They invent only garbage these days: Btrfs, ZRAM…

Hint: to disable the ZRAM:

sudo touch /etc/systemd/zram-generator.conf

If the file already exists, delete it first.

5. Manjaro Linux

This time it wasn’t a hands-on experience, as I deleted the Manjaro XFCE installation before being able to try it, but I feel like trusting this guy, so I’ll let this link to an article from January 2021 here: How To Enable Hibernation in Manjaro.

The real impediments to a universal hibernation in Linux

Sorry if I don’t seem to find other words, but the culprits are a bunch of highly-trained idiots. They might be good at programming, but they have zero common sense. Some other idiots are those who use some of the features that affect the hibernation.

A quick list:

  1. Some idiots are encrypting their partitions (they do it in Windows too). Unless they are terrorists or pedophiles, they’re just paranoid. Or maybe they feel so important that they believe the NSA and the MOSSAD are trying to retrieve the oh, so precious personal data they have on their laptops or PCs. Now, resuming from an encrypted partition brings some difficulties.
  2. There is also the philosophical argument that saving the RAM to an unencrypted swap partition would violate the … uh … idea of security. (Of course, every single computer on Earth stores in its RAM the most awesomely guarded secrets in the world. Except that WD-40’s formula isn’t such a big secret, anyway. Heck, we’re in the mRNA age!)
  3. Microsoft invented the Secure Boot. The Debian guys are kind and pretend, “UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run.” Nay, all this is crap. I want to run whatever software I want to run, full stop! Also, to prevent things such as the BIOS being overwritten with malware, we should adopt what worked 30 years ago: physical jumpers on the motherboard. Back then, you didn’t have everything self-updating like rabid rabbits; and it was excellent that way. This being said, I don’t know whether hibernation works with UEFI Secure Boot enabled in the BIOS (it probably doesn’t), because I always keep it disabled.
  4. On a related note, a kernel_lockdown feature was added in Linux 5.4: “The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorized modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded. […] On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled if the system boots in EFI Secure Boot mode.” Well, this also prevents resuming from hibernation, I reckon.
  5. The swap partition is increasingly seen as obsolete. (And it’s not encrypted, see above.) The swap file makes the hibernation more difficult (especially with encrypted partitions, and especially with filesystems such as Btrfs), although not impossible (I never understood why it has to be contiguous, and why there’s an offset to care about, and so on. It’s like the suspend-to-disk is so dumb that it doesn’t write to a file, but it writes to a portion of the disk, without using any filesystem API! If someone wrote it so moronically in the past, nobody’s going to fix it, now that hibernation is a moot topic.) And both concepts are phased-out by the famous ZRAM!

I’m pretty sure that Amazon failed to protect your data because they had PCs and laptops with secure boot disabled, with unencrypted partitions, and with the bad habit of suspending to disk. Hibernation is our worst enemy after the CO2!

Collateral damage, or What’s in a Name?

There is a thing called CPU frequency governor in the Linux kernel; here’s a quick summary of the governors from ArchWiki, consistent with the official documentation, but is in my opinion partially incorrect, if not absurd:

  • performance: Runs the CPU at the maximum frequency.
  • powersave: Runs the CPU at the minimum frequency.
  • userspace: Runs the CPU at user specified frequencies.
  • ondemand: Scales the frequency dynamically according to current load. Jumps to the highest frequency and then possibly back off as the idle time increases.
  • conservative: Scales the frequency dynamically according to current load. Scales the frequency more gradually than ondemand.
  • schedutil: Scheduler-driven CPU frequency selection.

Of high importance are these not from the same ArchWiki page:

Depending on the scaling driver, one of these governors will be loaded by default:

■ powersave for Intel CPUs using the intel_pstate driver (Sandy Bridge and newer).

■ powersave (for Linux < 5.10) or schedutil (since Linux 5.10) for CPUs using the acpi-cpufreq driver.

Note: The intel_pstate driver supports only two governors: powersave and performance. Although they share the name with the generic governors, they do not work in the same way as the generic governors. Both intel_pstate governors provide dynamic scaling similar to the schedutil or ondemand generic governors. The performance governor provided by intel_pstate should give better power saving functionality than the old ondemand governor.

Here’s the incorrect (absurd? crazy?) part: the “new” governors called powersave and performance (used by intel_pstate) are behaving differently than the “old” governors called powersave and performance (used by acpi-cpufreq). If you find this confusing, ask Linus Torvalds why and how was he able to accept such a mess!

Before giving an example, I’d like to confirm something mentioned in this Note: Fedora CPU Frequency Scaling using cpupower:

  • Indeed, I used to have the schedutil governor by default in Fedora.
  • Indeed, my previous knowledge is that ondemand is what I should aim for.
  • Indeed, I noticed that now the default governor in Fedora is powersave, and that the only other available option is performance (because intel_pstate is used).

At first, I freaked out, but then I discovered the crazy thing about “in the Linux kernel, a name is not identical to an identical name used for something that does the same thing”!

My example involves the CPU from my new HP mini-PC, Intel i5-10400T. (I could have opted for the slightest faster Intel i5-10500T, but I preferred to stick to the psychological price of €499.00 for the PC instead of €524.99. I’d have preferred an Intel i5-1135G7, which is in 10nm instead of 14nm, and with TDP 12W-28W instead of 25W-35W, but in wasn’t available in this HP line.)

So let’s take the i5-10400T: base frequency 2 GHz, max. turbo frequency 3.6 GHz. (For i5-10500T: 2.3 and 3.8 Ghz. For i5-1135G7: 2.4 and 4.2 GHz.) The lowest possible frequency is 0.8 GHz.

At first, I thought they “laptopified” the CPU governors to work this way:

  • powersave would keep my CPU at 800 MHz, to save the (battery?) power, which would be ridiculous!
    If I were to design a power-saving governor, I’d make it use in this case the range 0.8-2.0 GHz (min-to-nominal), with 0.8 GHz only on very low system load, and no “turbo” clocking at all! In the case of laptops and micro-PCs, this should also help with the cooling. (Long time ago, the mobile CPUs only had step-down frequency, not step-up/turbo ones!)
  • performance would keep my CPU at 3.6 GHz, which would be absurd, as this is the “turbo” frequency, i.e. it cannot be sustained all the time, especially with a modest fan! Should the CPU get too hot for running overclocked even without reason, it might need to reduce its frequency when I’d mostly needed it!
    If I were to design a performance-enabling governor, I’d make it use in this case the range 2.0-3.6 GHz (nominal-to-max), with 2.0 GHz as the default frequency!

The “old” governors would have behaved this way, i.e. forcing the minimum and maximum frequencies (and that was why nobody would have normally used powersave and performance, but only ondemand or schedutil). In practice, what I noticed with the latest kernel (5.14.18 something) in Fedora 35 was this:

  • powersave keeps my CPU in the range 0.8-3.6 GHz, but in X11, it rarely goes under 1 GHz! (In Ubuntu MATE 20.10, it seems to try to stay put on 1 GHz as much as possible!)
  • performance keeps my CPU in the range 0.8-3.6 GHz, but in X11, it would rarely go below 2 GHz, most of the time staying in the range 3.2-3.6 GHz if the system isn’t idle!

Well, this almost makes sense, although the turbo frequencies are used excessively. But this new behavior makes powersave quite usable and a decent default (especially as ondemand and schedutil are not available with intel_pstate, but only with acpi-cpufreq).

I noticed however a strange bug in MX-21_x64 XFCE “AHS” RC3. Let’s compare the output in Fedora vs. the output in MX:

Fedora 35:

$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: Cannot determine or is not supported.
  hardware limits: 800 MHz - 3.60 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 3.60 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 3.37 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

MX-21:

$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: Cannot determine or is not supported.
  hardware limits: 800 MHz - 3.60 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 3.60 GHz and 3.60 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 3.37 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

Umm… WHAT?! Within 3.6 GHz and 3.6 GHz? This is a 2 GHz CPU, dammit! That’s the old behavior, which shouldn’t exist in intel_pstate! Oh well, MX-21 XFCE “AHS” is still unreleased, but still. And yes, it defaulted to powersave, but I switched to performance just to see what gives. My bad.

In Ubuntu MATE 20.10 (kernel 5.13.0), if I switch from powersave to performance, even if the policy reads “within 800 MHz and 3.60 GHz” (or I can set different values via cpupower-gui, say between 1.20 and 3.20 GHz), the system will practically stay on 3.60 GHz or whatever is the maximum configured frequency! This is insane. Reverting to powersave, it will practically stay on 1 GHz (not 800 MHz) most of the idle time (I can set a higher minimum frequency via cpupower-gui, say 1.60 GHz). The Debian/Ubuntu family seems to be broken when it comes to CPU governors.

Finale

Nay, there’s very little I could add, and no relevant conclusion whatsoever. The Linux world is fucked-up, but it’s still manageable. At least, there’s enough really progress in Linux, unlike in the *BSD (the other day I examined NetBSD, which I loved 25 years ago, and I wanted to cry: the *BSDs are in an incredibly sorry state!).

It’s not like Linux has been brought forward by well-targeted enthusiasm, but rather by:

  • The business interests of some corporate names (not only Red IBM, I mean Red Hat), but they’re mostly interested in servers, containers, embedded devices.
  • The public’s interests in games on Linux.
  • Some enthusiasts’ passion to create apps and publish them on GitHub.

The last part isn’t about Linux per se. But nobody should be surprised that the Year of Linux on the Business Desktop will never come, despite living in the Age of Linux on the Gaming Desktop!

Now you will excuse me, I have to hibernate a bit.

BONUS: They have guts in Xubuntu!

I just noticed this in Xubuntu’s official documentation: Chapter 12. Hardware devices » Suspending and Hibernating:

Enabling hibernation

To enable and use hibernation with Xubuntu, do the following:

• Install the pm-utils package from Gnome Software.

• From the command line, enter: sudo pm-hibernate.

• Enter your password.

• To resume from hibernation, press the power button.

They must be kidding, right? Anyway, they don’t show the Hybernate and Hybrid Sleep buttons: