Hibernation, ZRAM and mental retardation in Linux
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!
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!
- Enabling hibernation in Linux Mint 20.2
- How to enable hibernation with swap partition on Linux Mint 19
- [GUIDE] How to hibernate to a swap file in Linux Mint 19.x
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.:
- On their forum: Hibernate, resume stopped working, which gives links to 3 external articles for an answer!
- One of them is on Ask Ubuntu (StackExchange): How to enable the hibernate option in Ubuntu 20.04? This one applies to Ubuntu MATE 21.10 too.
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.
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!
- Actually, I made hibernation work by following “The Golden Book of Hibernation in Fedora” on CTRL blog: How to enable hibernation on Fedora. Case closed? Not so fast!
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.
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:
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/zram0uses half as much memory as its size.
/dev/zram0behaves 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:
- 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.
- 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!)
- 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.
- 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.
- 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:
powersavefor Intel CPUs using the
intel_pstatedriver (Sandy Bridge and newer).
powersave(for Linux < 5.10) or
schedutil(since Linux 5.10) for CPUs using the
intel_pstatedriver supports only two governors:
performance. Although they share the name with the generic governors, they do not work in the same way as the generic governors. Both
intel_pstategovernors provide dynamic scaling similar to the
ondemandgeneric governors. The
performancegovernor provided by
intel_pstateshould give better power saving functionality than the old
Here’s the incorrect (absurd? crazy?) part: the “new” governors called
performance (used by
intel_pstate) are behaving differently than the “old” governors called
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
schedutilgovernor by default in Fedora.
- Indeed, my previous knowledge is that
ondemandis 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
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:
powersavewould 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!)
performancewould 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
performance, but only
schedutil). In practice, what I noticed with the latest kernel (5.14.18 something) in Fedora 35 was this:
powersavekeeps 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!)
performancekeeps 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
schedutil are not available with
intel_pstate, but only with
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:
$ 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
$ 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
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
, 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.
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:
To enable and use hibernation with Xubuntu, do the following:
• Install the
pm-utilspackage from Gnome Software.
• From the command line, enter:
• 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: