Ask HN: Why is the Linux community struggling to implement hibernation?
Today I have found out that hibernation is by default disabled in my Ubuntu 18.04 distribution. After this, I found this 11 month old post https://discourse.ubuntu.com/t/re-visiting-hibernate-on-ubun... where I realized that the Linux community does not seem to be able to implement a working implementation of hibernate. Is there any reason why this is a difficult problem? I would like to have an option in my OS like VM's have where everything that is currently running is saved on disk and can be resumed later without issues.
340 comments
[ 319 ms ] story [ 6630 ms ] threadDiscussed in HN: https://news.ycombinator.com/item?id=26285683 (113 points, 39 days ago, 64 comments)
Add to that difficulty the fact that many hardware (peripheral) vendors provide incomplete documentation making it difficult or impossible to implement "off-nominal" situations like hardware state reading/writing-restoring.
VMs have an advantage that the peripherals are limited in types and numbers and the state is "virtual" so the state is directly accessible (r/w) in the virtualizing driver software, not buried in physical hardware. When you "hibernate" a VM, no physical device actually powers down and no (buried in hardware) state is lost.
Hardware device vendors don't always write or maintain Linux drivers there's no stable driver ABI for binary drivers to be built and distributed for Linux. Instead, vendors are encouraged to write drivers that follow the conventions of the Linux kernel with no hardware abstraction layers and submit them for inclusion in the upstream Linux kernel under the GPLv2. Not every vendor is willing to do that (NVIDIA for example), but some do (AMD, Intel).
[1]https://en.wikipedia.org/wiki/NDISwrapper
"Ok, there are at least three versions of the Linksco WG8211, all with different wireless chipsets. The box is identical except for the UPC sub-label - you want the one ending in -02. Some of the -01 boxes might work, but no guarantees, and the -03 definitely doesn't have support yet. You can't tell by the PCI ID, but if you poke this particular register, you can get the sub-version, which should tell you which chipset they're using - if they haven't changed it again."
Wireless cards on Linux, back in the early days of 802.11, were brutal to get working properly, mostly due to lack of drivers. The NDISwrapper was gross and sometimes hard to configure, but it also meant you had a snowball's chance in hell of getting a random wireless adapter working on Linux.
This has a lot of advantages of this approach over binary drivers in that:
- The driver can be updated so it survives architectural changes (say from x86 -> amd64 -> armv7 -> aarch64 -> riscv).
- The kernel can be changed freely without worrying about supporting drivers that cannot be updated because they only exist as binaries.
- Bugs in the drivers can be identified and fixed by anyone (most importantly, critical security bugs).
Also, good ABIs are hard to get right. Windows had to completely rewrite their audio subsystem and the associated driver interfaces around the time of Vista to get low-latency right, for example.
But that said, the use of binary blobs exists even today (CPU microcode, various driver firmware blobs that people don't have time to reverse engineer, etc.).
Someone else also mentioned ndiswrapper, which reimplements the binary interface for supporting Windows network drivers on Linux.
So you can pick any Windows driver interface and write a Linux kernel module or a combination of a kernel module and some userspace framework that can host and utilize that driver. You might have to emulate or paravirtualize some hardware access or instructions to avoid causing conflicts, but there's nothing technical stopping you, other than it just being hard. It can also never be included in the upstream Linux kernel for the ideological reasons I already mentioned.
I use my desktop OSes for my job, but could be perfectly happy with a Chromebook for most of what else I do in my life.
Yes, your type of grandma exists, but I don't know her.
Who (outside of HN readership) wants this?
There are a lot of old computers in research laboratories running Windows XP because some proprietary driver for some important piece of equipment (like a mass spectrometer) doesn't have a 64-bit version.
I hardly doubt you are kernel developer yet you "know better". Such people always do.
By the way, Linux did well on Android because it is made there with "grandma" in mind.
Linux did well on Android because it does not suck. Mainline kernel boots hundred of models (postmarketOS). Another part mostly unchanged — browser. ChromeOS is Linux kernel and browser.
You've said hibernation is a matter ideological purity, no, it is a matter of practicality. You have to be kernel developer to understand practicality.
I've never said that.
I think this conversation is going nowhere, no reason to continue it.
The closest examples so far with Linux are System76 and Purism:
https://system76.com/
https://puri.sm/products/librem-14/
This is also what makes the Surface tablets and Surface Book so great. There's a top to bottom alignment of interest in creating the best user experience and making sure the product works.
The closest thing to computing hell is when a commodity operating system is slapped onto the cheapest commodity hardware by someone who isn't concerned at all about using it, but has a list a mile long of systems to configure. There are plenty of enterprise IT-managed work laptops with no display or chipset drivers that can't hibernate, but at least they have McAfee virus scanner installed and the corporate group policy enabled.
Nice theory. It is just, that writing drivers is hard and not many people are capable of it. So for most existing driver issues, it will be much cheaper to buy new expensive hardware that might actually be somewhat supported for a while - than hiring someone to write a reliable open-source driver for it. (oh and of course, you also cannot buy the latest hardware as then there is mostly no support there yet)
I would love my whole system to be fully open source and working.
But since hardware is very closed anyway, I would rather have a couple more binary blobs on my system, that work reliable - instead of a bunch of open, but very faulty drivers. So I very much would prefer a stable Linux ABI.
Because without - I am forced to use Windows on my new Laptop, as everything runs much slower and buggier on linux - and I would like to use my laptop to work on other things - and not on the laptop itself.
I think Hibernation has been impractical since 2013 or so.
I have an Alienware that runs rings around any Mac and can do ML dev work with NVIDIA if it is on the plug but on battery I count on it to keep running as I move it to another plug and for the battery to maintain sleep mode for 48 hrs or so.
I don't have lots of RAM (but rather on the low side for present day), but hibernation takes maybe 15 seconds on a SATA SSD.
Hibernation was definitely a lot slower 10 years ago on a desktop with less RAM and a slow spinning disk.
My HP Pavillon with windows hibernates reliable today, my very old netbook acer with Ubuntu/LXDE did so, too (but that was years ago).
Nowdays I gave up with linux laptops to even enable it, as it is quite complicated to set it up when you dual boot and use encryption. And after I did set it up, it failed over 50% of times on various devices so I did not bother anymore.
Windows makes the hardware vendors implement it in the their device drivers, and the "system integrator" (laptop manufacturer) is responsible to verify that it works. The laptop manufactures (a) have a limited and known set of hardware to verify works and (b) have "leverage" (i.e. promises to purchase large quantities of peripherals) to ensure the hardware vendors fix any problems found.
Linux drivers don't get much hardware vendor love.
But damn the number of issues I have on linux in 2021 outweighs the amount I’ve had on Windows, ever.
Still prefer linux over windows tho.
And those are mostly highly-integrated, full-intel computers.
I have a small HP with a thunderbolt / usb-c port. Thunderbolt kinda sorta works. Sometimes. But even if the display goes to sleep, it's game over.
I also have a usb-c monitor. I've only ever seen it work one (1) time in windows. On linux it mostly works. Sometimes it doesn't detect the correct refresh rate for some reason. But in the BIOS it always works. I could actually even install Windows with it. And it sometimes gets to the login page. But once the session launches, it turns off.
That's part of where the whole "Have you tried turning it off and back on again?" piece of wisdom comes in. You never know what might have flipped out from under agter a hibernate. When you turn it Off off. You know.
Unless...you dual boot linux. I have an Envy 47 something whose wireless still can't get it right. So I just ran an ethernet cable to it. Traced it down to being because Ubuntu wouldn't clean out the hardware registers between hot reboots. It would be fine after a cold shutdown, but once the card got stuck in a bad state, not even a switch to windows could save you. I'd have to pull the plug to get all the registers clear, and start anew.
And that was how I learned it's never the hardware until it is.
But for example, I threw Kubuntu (21.04 beta) on my Lenovo Thinkpad X1 Extreme 3 days ago. I'm already running Ubuntu 20.04 on a different partition and it runs fine.
Kubuntu + Wayland, omg, clean install, firefox wont run properly at all, if you change to any other theme the menu bars disappear. Running X11, mad screen tearing and makes the fans spin up like crazy. Wont detect BT so can't use headphones. It's a headache :(
Have a Dell XPS for work. Sleep used to work fine, and the machine would barely touch its battery if I put it to sleep over a weekend.
It doesn't work any more: the machine never sleeps properly and drains its battery very quickly, barely making it from Friday night to Monday morning (and not making it at all if I don't plug the power in before I plug anything else in).
Note that this isn't a fault with the battery that I can see: battery life is still fine when the machine is being used. I can only assume that at some point over the past couple of years an OS or firmware/driver update broke sleep... which is annoying.
(It's one of many reasons I prefer OSX to Windows: sleep always works.)
Modern standby is turning on my XPS so much it can actually get dangerously hot in my backpack.
TLDR: "enables the system to stay connected to the network while in a low power mode" [...] "with the added benefit of allowing value-added software activities to run periodically" [...] "When a system service or background task requires network access, Windows automatically transitions the networking device to an active mode" [...] "longer active intervals occur for a variety of reasons, for example, processing incoming email or downloading critical Windows updates."
Details about what can temporarily activate Windows in Modern Standby at https://docs.microsoft.com/en-us/windows-hardware/design/dev...
Don't you have a way to disable it and go back to what Microsoft calls Traditional Sleep?
Yes, on some laptops, such as Lenovo, you can switch from "Windows" to "Linux" sleep mode in BIOS (yes, they are really named after the OS).
Here's the rub: you have to reinstall Windows. There used to be registry edit you could do but that seems to no longer work. At least it didn't for me.
No OP, but most of Dell's current lineup no longer has support for any other modes in the firmware. So no, I can't disable it.
So often what happens is nothing: the battery often drains completely overnight and it's guaranteed to be dead on Monday morning if I let it "sleep" on Friday.
Also, snrk:
> Symptoms
> Microsoft introduced Modern Standby in 2012 to improve battery life and the transition between power states, allowing Windows PCs to transition between on/off states faster, like your smartphone does.
It's a knowledgebase article using a standard Support/Resolution template (that might not be changeable). The irony is thoroughly amusing and IMO appropriate.
I recommend the powercfg command line approach instead of the UI.
What is totally annoying is my monitor, which has USB C power delivery, won't charge the laptop if its battery is completely flat. So now I have to carry the XPS's power adapter too.
I have been an XPS fan for years. But I am so close to sending this one back.
(If anyone from Dell reads this, pass back the message that you've lots of really unhappy customers from this)
Do not expect the issue to be fixed. People bought XPS's years ago thinking Dell would release a patch in some reasonable amount of time, but it never came.
If your use case involves a lot of time away from a charger, I would send it back. Maybe splurge a bit more for a Surface Book, assuming Microsoft cares a little more about putting out a well finished product.
S3 = traditional "suspend to ram"
S1 = new fangled "kind of sleep, instant on mode"
At least, thats what I found on a System76 Lemur Pro, which has the same cpu as the XPS13 (and System76 had to restore the IME, whereas before they used to disable it, just to get some semblence of sleep working)
Solution: get an AMD 4800 - powered laptop instead. Same price, double the cores (8 vs 4), much (much) faster and yet runs cooler.
And S3 sleep works!
* I raised a service ticket with Dell.
* They asked me to install the latest firmware for the XPS13 9310, dated 8 April 2021.
* That solved the problem: now I can close the lid and the laptop properly sleeps; I can put it in my bag without it getting noticeably warm; battery loses just a couple of % overnight, not 75% as it did before.
So irrespective of whether this 11th gen does S3 sleep or not, my laptop is now performing in line with what I expected.
Thus: thank you Dell.
http://rachelbythebay.com/w/2020/10/03/repro/
We've also had pretty awful state issues with Filevaulted Intel Macs from 2014 to present. While more consistent in their quirks than the myriad models and configurations of PCs, Macs haven't really done much to impress anyone but shareholders this past half decade or so.
Once the machine went back sleep, I could not get the video signal back. All the other hardware would wake up fine, but I’d have to fully reboot to get video back.
Both my 2015 and 2018 MBPs probably once every 2 days, sometimes multiple times in a single day will resume from sleep to a hard reboot and a kernel panic message or "Your computer restarted because of a problem" message.
My windows desktop workstation manages just fine, but maybe I won the hardware combination lottery.
The board vendor knows what they put on the board, they have support from the suppliers, etc... So it's a tractable problem for them even if the solutions are often ugly ad hoc hackery.
The community has none of that. They need to figure out all this stuff by reverse engineering in most cases.
But the point is it's not an "OS" problem. "Windows" doesn't do anything different from Linux. The difference is that if you ship hardware and people only pay for windows, then you only make windows work.
The hal (hardware abstraction layer) is always a hard problem that takes years to get right. Write the code, write the tests, fix insane little bugs, get market momentum. Once it is solved it kinda runs itself and is a massive moat.
(Apple tried this... 95? StarTrek project, os 8?)
This collection of issues is why i run windows as a host os and above that run wsl (far better than mac's weird port of bsd + homebrew), local vms, and cloud servers.
Unless you want to talk about the difficulty that is high dpi monitors? That has taken 5 years for 'the windows community' to shake out and i don't think linux ever will. Windows is the best solution right now for this very important problem, unless you like fuzzy text fonts.
I am not a windows fanboi. Far from it. I have all the ecosystems in my house, and have professionally gone back and forth as the winds have shifted. It is amazing to me that windows has come back, credit vmware, docker, wsl, and microsoft's new openness to being a sensible first stop for developers.
In my particular case, I have a HP Elitedesk 800 G4 mini (a small form-factor desktop) that sleeps, hibernates, etc perfectly on linux. Worked ever since it was brand new.
On windows, for some reason, it randomly turns on at night. I've tried deactivating pretty much all I could, including the option to wake up to install updates (and I usually install the updates fairly quickly anyway).
This also happens on an older custom-built PC. Random screen problems (AMD RX card) and / or previously unused USB ports don't work. Everything goes back to normal after a reboot. As this computer doesn't have a TPM, bonus points for the screen turning on bright blue in the middle of the night for bitlocker unlock.
Linux sleeps and hibernates perfectly on all my PCs (all some form of HP elitedesk or probook - I haven't tried those on the custom-built PC).
Also if you don’t implement it or you implement it poorly and you’re not the size of Nvidia your drivers will not pass the checks and will not be signed, so your customers won’t be able to load them.
I've seen companies run shelves full of sleep-wake machines. sleeping and waking. sleeping and... yawn... waking.
Basically, you develop against that device, and it's upto hardware manufacturers to try and match the reference device to make their laptops/desktops compatible.
If you could get a couple of distro owners such as Red Hat, Ubuntu, Arch, etc. to agree upon such a device it would go a long way to resolving a lot of the issues that the desktop community faces.
Disclaimer: I have no expertise in this on either the hardware or software end so this idea might be completely nonsensical for all I know.
So, the market is really rather less than that 1%...
The way to convince the mainstream vendors would be what's attracting them to release Linux support right now. The popularity of Linux devices for people who want to work on the same machines they run their servers on.
Like I said though, I'm not sure whether this idea is workable or even makes sense.
Linux needs to have similar certification. The rest would be to have customers look for it and prefer hardware that's certified.
https://certification.ubuntu.com/make/Lenovo
Or this:
https://support.lenovo.com/il/en/solutions/pd031426-linux-fo...
It's all really very nice, but even on certified machines, some hardware parts are not working on Linux (X1 fingerprint reader, for example).
But then I guess they aren't really doing their job when certifying things that don't work.
But if I want to differentiate, commanding a higher price, then I'll probably be different.
I think I would rather (it'd be easier) to wrangle cats.
Currently, as it stands, you'd need 10,000+ 'reference' devices to match what's in use and to wait several years for them to fall out of use if you want that to be a lower number.
Even Chromebooks, which are largely based on specific boards for several models, have a few hundred reference boards that would need to be specifically supported.
Apple computers are some of the worst documented computers out there. Also, niche components, one-off chips, secret registers and unidentifiable chips on the logic board, the T2 chip alone is a nightmare for linux (and the T2 is on every Apple laptop since 2018). The M1 isn't even minimally documented yet, and reverse engineering it will probably take a decade.
Do you have any source? (Even if those are opinion based)
Ubuntu also tried to do a bunch of their own stuff, but not very well and without this apparent overall strategy that Red Hat has. They seemed to just be trying to differentiate themselves, not to also drive everyone else nuts as they’re forced to try to keep up.
Same question regarding to Wayland, from a shorter check I see that it is developed by the freedesktop.org which was founded by Havoc Pennington from Red Hat 21 years ago but it is seems that it isn't really under Red Hat control nowadays.
The really funny part is that people think there is some metaphorical gun to developers heads to use this technology. There is a choice, there always has been.
Of course, but when the choices are "support A and B for C" or "support A and B for C but now it'll be a ton of extra work to package and maintain because C deliberately cut out A (and every other alternative that's not B)... or drop A and only support B for C, which is becoming popular fast anyway because it has lots of money behind it" then those two sets of choices aren't exactly the same.
"There's a choice" doesn't mean the choices & options aren't being nudged pretty hard.
> You're bringing logic into this, please stop. The propaganda narrative is to just bash Red Hat for any work done. Of course the company that employs many opensource people across the world is going to have some effect on the ecosystem.
I used to like them a lot, but at some point noticed I dislike an awful lot of the ways they influence the Linux desktop, and the tech they push, often by intertwining the projects they have influence over and driving them in ways that practically exclude and marginalize alternatives. If they changed I'd change my opinion. But yeah, I'm probably just some sort of simpleton.
I get that you feel excluded and marginalized but those may be misplaced emotions, if you were never a paying customer or a developer then you were probably never part of the club. It's just some company posting free stuff online, and you're welcome to take it or leave it.
Were my terms too abstract? Systemd is written such that it's a pain in the ass to keep the multiple options for the several systems it replaces around, if a piece of software that's very important decides to go all-in on Systemd. Gnome did exactly this. Before that happened this problem did not exist. Systemd + Gnome created the problem, for any distros that wants to package them, forcing them to choose between a bunch of extra work or marginalizing anything that's not systemd. I'm not talking about "side projects on GH" but the ability to, practically, not theoretically, replace important parts a Linux system at all, or to write a new implementation that does things usefully-different from existing options because the spec is reasonably broad and the system loosely-coupled. Those are on their way out, and that's on purpose. Side projects on GH indeed. Haha. I think I see where the disconnect is, yeah. Maybe we're talking about totally different things?
> I get that you feel excluded and marginalized but those may be misplaced emotions, if you were never a paying customer or a developer then you were probably never part of the club.
Rad, I'll stop having an opinion or even noticing things that are happening because I'm not part of... what club is this? HN posters couching insults in armchair psychology to try to evade downvotes? Is that the club?
The "club" is people who were invested in that particular project. If you're just a free user and you didn't have an active investment in pushing the project forward, then you're not in that club. Sorry, I don't mean to be blunt and I'm not trying to insult you, but the honest truth is that your opinion doesn't really matter unless you have the resources or the clout to push it forward. And if you did, then you'd be the one running the company, and then people would be complaining about how you're marginalizing them. Again I don't meant to be rude here or shut down your opinions or anything but let's just be real. Someone's got to foot the bill eventually, and when you're that person you get to be the one who says no, and then everyone else gets to be mad at you.
So, we are talking about different things? Because most of the things I'm talking about pre-date Github.
> The "club" is people who were invested in that particular project. If you're just a free user and you didn't have an active investment in pushing the project forward, then you're not in that club. Sorry, I don't mean to be blunt and I'm not trying to insult you, but the honest truth is that your opinion doesn't really matter unless you have the resources or the clout to push it forward. And if you did, then you'd be the one running the company, and then people would be complaining about how you're marginalizing them. Again I don't meant to be rude here or shut down your opinions or anything but let's just be real. Someone's got to foot the bill eventually, and when you're that person you get to be the one who says no, and then everyone else gets to be mad at you.
Sweet, so I'm the everyone else who gets to be mad. Glad we agree I get to. For fuck's sake, I'm just pointing out a pattern of behavior a corporation is engaging in, which may be used to predict other things they may do. This is bizarre.
Red Hat didn’t force it on any other distro. A majority of major distro makers chose it because it works really well for their purposes.
Kinda like gnome, even though kde is more customizable and has more features.
System76 manufactures computers exclusively for Linux. Dell XPS laptops are also pretty popular with Linux users. Thinkpads were historically, as well.
I would think you could get financial support for a few base models and enough widespread support for at least half a dozen hardware configurations.
https://www8.hp.com/us/en/workstations/z8.html
The question is, who is going to make this reference device? Intel? AMD? ARM?
Good luck with that.
On most hardware I buy, I can read "compatible with Mac and Windows" on the package, but nobody seems to bother if it's compatible with Linux or not ...
I'm pretty certain ACPI is supposed to be at least one part of such a "hardware state layer" already, but as far as I know broken implementations are more common than functional ones.
It's like savegames - I think it's hard and bug-ridden so some folks just add checkpoints and don't bother with complex restores in the middle of the bossfight with rockets in the air.
The Linux kernel is huge, complex and particularly messy in terms of internal structure. This makes even otherwise trivial modifications hard, and complex modifications extremely hard. The development overhead is brutal.
And hibernation just happens to be a scenario that's a nightmare to implement with such a design.
I wonder how such a messy base offers such stability ...
By not solving problems like hibernation.
I have been running primarily Linux for longer (over two decades) and I am to some extent fond of it. But it is what it is.
Honestly, it would probably be easier to just run everything off a VM if having persistent states matters to you.
If you boot into an initramfs and make additional swap partitions visible, eg via losetup, you can then write the device major:minor into /sys/power/resume and kaboom the kernel will freeze userspace, read the hibernation image out of there, then jump to it.
https://wiki.archlinux.org/index.php/Swap#Swap_file
Still, with the current implementation one must disable secure boot to enable hibernation (which I do). Having hibernation and secure boot is the (complex) missing part, see [1] for why.
[1] https://mjg59.dreamwidth.org/55845.html
A thing that I do often is that I forget my desktop PC in sleep mode but still powered, and since I know that hibernation works I can simply cut power to the whole power strip to save energy without having to wake up the PC just to shut it down correctly and then remove power safely.
By the way, you can also have a swap file, but it's not as simple to configure (and still the file size is kind of fixed and that removes the point).
I have about a thousand browser tabs and 20 terminals open at any given time. Re-setting all that up would be a pain. I haven't shut down my laptop in 6 months, but I hibernate and resume it regularly.
Also every device driver needs to handle suspend/resume for the device, which is very hard to implement without documentation. And the only way is to reverse engineer some windows driver...
I switched the SSD of my MBP 2 years ago and since then everything is out of control. Sometimes the thing keeps running when I close the lit and when I open it again the battery is empty. Sometimes it simply shuts down entirely and has to boot from scratch when I open it again.
I tried reinstalling the OS and whatnot, nothing worked.
A module working for everything except hibernate is ridiculous.
I have just accepted it, on a personal computer I am less likely to need to keep a ton of things open so it's okay if I lose all my windows on crash.
On a work computer I would not be able to accept this - thankfully my work 2018 MBP on Catalina handles this fine.
I previously had an Ubuntu Dell XPS at work with a similar problem and it was horrible losing my tabs and terminal windows 4-5x per work day
I had similar issues with my Surface Book 2, though it wasn't as pronounced as my mac.
Regarding your troubles, I'm not really surprised that it's not working with a third-party SSD, and it definitely sounds like a hibernation glitch. Have you tried disabling hibernation altogether?
disable: `sudo pmset -a hibernatemode 0`
re-enable: `sudo pmset -a hibernatemode 3`
(in fact, if my admittedly poor memory serves, I think I busted hibernation mode on my old 2009 17" MBP doing the same thing, and this trick fixed sleep…)
OpenBSD hibernate, and power management in general, works great on Thinkpads but the developers specifically like and use them regulary, at least so I've heard.
So I don't think it's any one OS that works well or badly or better than another; it comes down to the combination of the OS and the hardware and the compatibility between the two...
- it does not work on encrypted partitions since there is no way to unwrap any key at all
- with an active state originating from an encrypted partition gives any attacker the opportunity to manipulate the hibnerated system image
- hardening tools often recommend to turn off hibernation in the kernel completely because of #2 (and the implication that this would load any crafted image into your working memory)
- recent distributions create /tmp as a tmpfs/ RAM disk which makes hibernation impossible due to power loss of RAM in this sleep state, and /tmp could be the default if nothing else is specified
- partition parameters on kernel command lines rise and fall with modules available at boot time/ through the bootloader, e.g. GRUB or Lilo. It might happen that using UUID in the case of hibernation does not work in combination with certain bootloader versions
- hardware does not support the power down sleep state, e.g. Raspberry PI or has no peripherals connected triggering a boot process (BIOS does this upon pressing for example the shutdown-key on a USB-keyboard with this enabled in the BIOS which in turn requires the USB-ports to be monitored/ enumerated and powered which isn't the case for any Raspberry)
I've been using hibernation for more than a decade on different hardware and distributions but only on that drag-around low-fi laptop ingesting ycombinator, running IRC client or Liferea. I always use the swap partition for this and it has always been /dev/sda2 with 4GByte (currently 5.4.* for Arch, Gentoo and Debian). I trust Grub, currently 2.x but also worked back in the days with 1.x since it is a kernel parameter (and the kernel self-compiled with CONFIG_HIBERNATION=y and copied with a steady hand and a magnetized needle).
In Debian, this is handled by initramfs scripts: the script asks for password, unlocks the device and then resumes from it. I think this will be the case with other distributions too. Or at least you can hack it yourself (open the device and run "resume" command on it).
> - with an active state originating from an encrypted partition gives any attacker the opportunity to manipulate the hibnerated system image
This is true, however a) with common encryption modes (XTS) they can only produce garbage, b) it's very difficult to target specific data as the memory allocation is random, c) they can use the same tampering for the system itself (e.g. /bin/bash), d) they can tamper with bootloader or kernel (unless SecureBoot is enabled) anyway.
> - recent distributions create /tmp as a tmpfs/ RAM disk which makes hibernation impossible due to power loss of RAM in this sleep state
I don't see a problem with this. The content of all tmpfs filesystems is saved into the image (there is much more that could break otherwise, for example /run).
> - partition parameters on kernel command lines rise and fall with modules available at boot time/ through the bootloader, e.g. GRUB or Lilo. It might happen that using UUID in the case of hibernation does not work in combination with certain bootloader versions
I have never had problem with this and I can imagine a situation when this happens (you are using the same bootloader and initramdisk for normal boot and for resume).
> You need a swap configuration that's large enough to fit your entire RAM and also your current swap.
I'm struggling to wrap my head around this one - please help me understand?
How can a swap be made large enough to fit your entire RAM as well as your current swap?
In other words, what if your current swap is already being used near capacity?
Or is that not really likely with a really large swap?
https://help.ubuntu.com/community/EnableHibernateWithEncrypt...
https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryptio...
Incidentally, I've just upgraded my RAM to 64GB and it's in the process of resizing the swap partition right now!
This makes a huge difference on Linux, and I hear the windows mode is somewhat experimental and not working so well yet even with Windows.
https://mobile.twitter.com/dorfsmay/status/13629639921094778...
Oddly, enabling Android got the touchpad working in Ubuntu.
Sleep works fine for ages. Works better on Linux on my 2015 laptop than on Windows (hint: if you have a KIRA laptop, suspend stops borking after you update the drivers for the touchpad to a ~2019 version).
E.g. for a relative secure setup you can:
- use a custom platform key
- use EFIStub boot and bundle you kernel initramfs, flash screen image, kernel options, etc. into a single efi bootable blob
- sign that blob with your custom platform key (or enroll it's hash if you don't use a custom platform key).
- copy your secure boot signed early boot environment into the efi partition.
- have everything else in encrypted partitions including /boot (which your are not using)
- easiest way to have this is make a EFI partition and a single large encrypted partition and then use LVM (logic volume manager 2) on it to split it into swap, root, /home etc. Added benefit is you can easily resize them.
- now you just need to setup a way to decrypt on boot, e.g. by having a boot password, secure key or similar. You will need to provide it even if you boot from hibernation. (or you use the platforms TPM!)
Naturally you can also just ignore how hibernation breaks secure boot and set it up anyway. Your computer doesn't know you are braking the secure boot spec. But a company (like Ubuntu) might have committed to not brake the spec.
0. This is a highly unusual operation. There is no other code that exercises this scenario of switching form a hot state to another hot state, not even S3 sleep or runtime suspend (AKA s0ix, or PCI D3 Hot) although they are a little similar. You need to completely freeze the hardware (including invalidate every cache, stop all firmware, etc), then switch to the other Kernel and make sure this other Kernel can resume operation from the state the hardware is, which is probably different from the state left at boot or at S3.
1. AFAIK the hardware (BIOS, firmware, etc.) cannot detect this as well as it can detect, for example, S3, so it can not properly react. I know, sometimes hardware/firmware gets in the way, but sometimes it helps by setting state your driver may not otherwise be aware it needs to set.
2. Testing S4 is a pain. Basically if you want to guarantee S4 works you have to put the machine to S4, wake it up, run your whole test suite again, then put to S4 and wake up a few more times and then test again. Some bugs don't show up in the first S4 cycle.
3. Debugging S4 is even worse, since it involves two different Kernels and a lot of wasted time checking for everything. Do you think devs run S4 cycles before sending patches to the mailing list?
4. With machines booting so fast and both S3 and runtime suspend working so well (not necessarily on Linux), there is little reason to even want to hibernate. Seriously, why would I ever want to use S4?
4.5. Colorary: S4 bugs will always be very low priority for the devs I pay, unless I have a paying client explicitly yelling about it.
5. Every driver in your system needs to be properly working. Just a single broken driver may screw everything in your S4 cycles. So unless you're running on a machine where some dev team explicitly tested S4 to make sure it works, then there's a chance it won't work properly.
6. It's not impossible to get this right, it's not impossible to architect drivers so the S4 code benefits from the S3 code. It's not impossible to architect a driver so it's properly initialize and work on whatever state the registers are. But it's just almost never the priority to ensure S4 works.
Edit:
The driver I worked on was nicely designed and we tried to take advantage of S3 for S4 as much as we could. Still, sometimes an S4 bug would appear and would result in tons of debugging hours just for it. I remember one specific case where the hardware got a new cache and we forgot to invalidate it before switching, and that caused very weird memory corruption. We wasted probably 2 "man months" in debugging hours before the one line fix was committed. We had a client that was doing like 50 S4 cycles in their test procedures, and the bug for some reason would only appear after 2 S4 cycles.
And these days, I have to leave my desk pretty often so I have it set to hibernate after 30 minutes of inactivity. My pc idles at 80 watts, so it saves a decent amount of energy to hibernate often.
You should compare the power use on sleep, not idle.
I have a ThinkPad running Archlinux. I have suspend-then-hibernate mode enabled, which means when I close my laptop lid it suspends for 2 hours (configurable) and then puts itself into hibernate. If I decide to open the laptop within 2 hours, it's available instantly. Otherwise, it takes maybe 20 seconds to reanimate from hibernation. People often say, why not just shutdown and reboot? The obvious answer is that I don't want to close out a dozen Chrome tabs, close all my terminals, all my files, and open everything up every time I need to walk away from the computer.
I have secure boot turned on. Hibernation is done to a swap file (I can simply delete the file if I need the space). I have LUKS encryption enabled. I'm dual booting with Windows. And yes, it all does work perfectly fine.
You can have your cake and eat it too. It just takes a bit of research and a bit of time to setup.
But at some point I noticed that laptops I'd left for a long time without power would wake up & resume. I'd expected they had run out of juice while asleep & I'd have to boot fresh.
Turns out systemd (in my Debian OSes at least) was set up to hibernate at a very low critical % of power remaining. The laptop would rouse from sleep & hibernate, at the last minute (and change). And it was working fine.
After seeing it happen a bunch of times I decided to try to embrace hibernation, & remapped my power button from sleep to hibernate. Everything worked great! Now my computers drain no battery when not active. I love it. Been this way for half a decade now. Works great.
Bonus, one of my laptops would, when it woke up from sleep, "lose" it's wifi card. With hibernate, that laptop's wifi card shows up again, even if it had lost the card to sleep before. Hibernate, contrary to my expectations, was even safer than sleep.
Can you get gpu accelerated video playback in Firefox/Chrome? For me these days, "having your cake and eating it too" means running linux on a virtual machine.
I have hardware accel running in Chromium. It's really glitchy and would not recommend it. I'd probably just use mpv or vnc if you need hardware accel video.
Really, my biggest gripe with Chromium is that it does not yet support kinetic scrolling with a touchpad. Firefox supports it, however it's still not as comfortable as my Macbook.
My current papercut is that 4k@60hz does not work with an Lenovo Gen 2 USB-C dock, while it works fine in Windows:
https://gitlab.freedesktop.org/drm/amd/-/issues/1317
(I didn't report this, but am running into the same issue.)
Yes. (not with nvidia drivers.)
> What ensures that the hibernation image was actually written out by the kernel? Absolutely nothing, which means a motivated attacker with root access could turn off swap, write a hibernation image to the swap partition themselves, and then reboot
Maybe I'm just really thick, but I can't think of a reason to care that root could bypass secure boot. The attacker already has access to the entire system and I would usually assume the valuable part of that access is the data and not the hardware or the kernel. This is an attack at a level beyond the typical "evil maid" with physical level access.
Besides that, I'm not sure what would stop anyone from just tampering with pacman, mkinitcpio, or other things and just wait until the next kernel is being built and redeployed to have their fun. You're going to have to upgrade your kernel at some point, and you'll need some kind of tools to do so.
There's probably a very thin line between the threat that secure boot protects against and someone beating me to death for my password.
Increasingly, root and kernel access aren't the same thing any more (if you enable lockdown mode). That stops root from doing a whole bunch of things. It's true that often, user-level access is enough (if you only care about the user's data). But if you want to modify syscalls or do some other thing that root may not do in lockdown mode, you'll need to get kernel access. And many other ways of getting there have been blocked in an attempt to strengthen the barrier between root and kernel (some dispute the utility of that separation, but I think it's because they fundamentally reject its goals). This is about closing another hole in the barrier.
How useful that barrier is against attacks of the https://xkcd.com/538/ kind is, of course, a different matter. In my view, the point is that it raises the cost.
The advantage is that files are much easier to change (extend) than a disk partition.
Ref:
https://askubuntu.com/questions/904372/swap-partition-vs-swa...
https://askubuntu.com/questions/927854/how-do-i-increase-the...
On btrfs systems, for example, I have to set a bit to disable COW for the file to be used as a swapfile, otherwise it will not work.
Edit: I found that zvol is virtual volume so anyway it should be handled by zfs.
I also found mention about the bypass mechanism. http://lkml.iu.edu/hypermail/linux/kernel/0507.0/1690.html
Just echo "disk" or "mem" or "freeze" to /sys/power/state with sudo to make it sleep / suspend / hibernate.
If you want to lock the screen as well, run `i3lock -d -c 000000` or `xlock` before updating the power state.
Through there is some hardware for which you will have a hard time to make hibernation work and the only reason why it works on windows is because the vendor explicitly provided a proprietary/closed source driver for their hardware.
And besides this there is the simple reason that Linux is server first. Servers generally don't do hibernation.
Regularly my MBP dies with the lid closed with no option to hibernate. After which, it refuses to start for 15 minutes after being plugged in, before it agrees to turn on. To me, that is user hostile.
Windows hides the hibernate option until you do some magic incantation. Often upon restart, wifi driver is disabled or cannot be enabled and I have to restart.
On Linux, At least with a decent swap size, all I have to do is `systemctl hibernate` and it works like magic. LUKS and sd-boot are what I use as well.
Also the charger that ships with the USB-C macs doesn't feel like it puts out enough energy to jump start them, feels like it has to build a little battery charge just to get over that initial hump. Older models used to be even from cold dead battery it would start instantly once the power cord was in.