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
Hardware (peripherals) have state. Reading the hardware state is difficult and sometimes impossible so recreating that state correctly after powering down is very difficult. Then multiply that difficulty across all the different hardware that can be in a PC and it becomes extremely difficult to do on an arbitrary laptop/PC.
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.
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.
I think the non server Linux community needs a reference device.
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.
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.
>If you could get a couple of distro owners such as Red Hat, Ubuntu, Arch, etc. to agree upon such a device
I think I would rather (it'd be easier) to wrangle cats.
I think I would rather (it'd be easier) to wrangle cats.
yeah. RedHat (owned by IBM) will surely step up to the plate here. . .
I feel like there's a punchline coming, then realized that was the joke
Red Hat would never participate. Their current (and for like the last decade or more) strategy seems to be to run toward various goals in convoluted and incompatible ways such that they're always "ahead" of everyone else, using their weight and the combined power of several projects they head to force the rest to burn resources playing catch-up with their meandering path to sub-optimal-but-sufficient solutions.
Never heard that
Do you have any source? (Even if those are opinion based)
Do you have any source? (Even if those are opinion based)
Gnome, systemd and its increasingly-tight integration with same, plus its eating everything in sight, wayland conveniently leaving everything up to the DE/WM (but gnome works, so why don’t you just use gnome?).
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.
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.
Is Gnome driven by Red Hat? According to the project site the board and the advisory boards are not controlled by Red Hat employees, the Gnome foundation president isn't from Red Hat either, and the project is a GNU project.
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.
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.
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.
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.
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.
> 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.
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.
These kind of comments are really baffling to me. If they have no interest or investment whatsoever in A, then what are they supposed to do? Can you blame any distribution for not wanting to put in all that extra work to package and maintain it themselves, for every single other piece of open source out there that someone might have a passing interest in? It's a business, they don't have infinite money to spend towards everyone's side project on Github. I wish they did but sadly, they don't.
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.
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.
> These kind of comments are really baffling to me. If they have no interest or investment whatsoever in A, then what are they supposed to do? Can you blame any distribution for not wanting to put in all that extra work to package and maintain it themselves, for every single other piece of open source out there that someone might have a passing interest in? It's a business, they don't have infinite money to spend towards everyone's side project on Github. I wish they did but sadly, they don't.
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?
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?
I completely disagree with your comment and I'm not talking about different things. There are a lot of side projects on Github to replace various parts of a Linux system, and various parts of systemd. They exist. What else were you talking about? When you want to replace something then you have to re-implement all its functionality. Systemd isn't any harder to replace than anything else, and it certainly didn't create the problem that someone has to actually put in the work to write the replacement. If it feels like too much extra work, then maybe ask yourself if it's really worth it to replace it to begin with? What are you really getting out of it?
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.
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.
> I'm not talking about different things. There are a lot of side projects on Github to replace various parts of a Linux system, and various parts of systemd. They exist. What else were you talking about?
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.
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.
It's hard to escape being de facto controlled by the entity that's providing the overwhelming majority of your development resources. The board doesn't have the time or expertise to take a position on deep technical questions, and the main contributors are Red Hat employees with a Red Hat worldview.
Red Hat is also the main contributor to the linux kernel, almost every year. Red Hat is probably the company with the largest contribution to the open source world at large, and it's been that way before most of the other big players of today were born.
Systemd is winning because it’s clearly a lot better than the alternatives.
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.
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.
I assumed the majority of distro makers chose it because of red hat and canonical choosing it, making it a defacto standard.
Kinda like gnome, even though kde is more customizable and has more features.
Kinda like gnome, even though kde is more customizable and has more features.
This seems like it could just be a case of Hanlon's razor. Software projects are quite capable of being convoluted and incompatible without any agenda having caused it.
Yes, but there would be a sufficiently-well-resourced agenda to mostly avoid convolution....except the incentive is misaligned.
[deleted]
With the death of CentOS, is Red Hat really relevant anymore in the consumer space anyway? My gut instinct would be no but happy to be corrected if this is false.
CentOS isn't dead.
So CentOS is actually getting better with a more open development model. Awesome.
Fedora?
Maybe not a single reference device, but there are fairly standard devices that are advertised, ship with, and offer support for Linux. The HP Z8 claims "Ubuntu. Certified and pre-installed." I've always run RHEL or CentOS on them and the company I worked for paid Red Hat for kernel customizations...so I figured there was comparable support. Yes, these are workstations, but HP says the same thing about their zbook. I've just never used those.
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
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
>I think the non server Linux community needs a reference device.
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.
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.
> and it's upto hardware manufacturers to try and match the reference device to make their laptops/desktops compatible.
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 ...
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 ...
Maybe because "being compatible with Linux" doesn't mean anything specific. There's no spec so nobody can follow it... which is what GP is saying I suppose: Define a bar so people can try to aim for it.
Wouldn't "Compatible with Kernel 5.11" be a pretty good/accurate bar? That is if they upstream their drivers or develop their closed sourced ones against certain kernel?
Except that when you get the device in your hands, the kernel version advertised is in the very best case one year old. So irrelevant.
ARM9 SystemReady is designed to offer manufacturers of devices a way to target a "reference platform", where all compliant devices can be booted from a single kernel/os image. I detailed this out in a comment earlier this week, with PDF links, if you'd like to read more. I think they're specifically thinking of mobile phones and servers (and the Server spec is its own standalone thing, which is smart). https://news.ycombinator.com/item?id=26694321
Any hardware manufacturer deciding hibernation for Linux was worth doing would have done it already.
Back in the day, this was basically how Thinkpads were, right?
My recent-ish Thinkpad (T470) didn't give me much, if any trouble with hibernation on Linux. I can reliably use it to switch operating systems (dual-boot with Windows 10) without losing the state of either OS. I've had rare occasions where the presence of certain USB devices caused it to resume unexpectedly, but that's the only issue.
Sounds like a great idea. I suggest that as a reference device we use this device sold by my company. :)
Honestly if your company made a firm commitment to publishing the necessary specs, fixing reported bugs, and maintaining that stance going forward, then that would probably be a deal many open-source people would take.
That's a good idea! What do you think would convince hardware vendors to match a reference device?
A large number of sales of said device. That's pretty much what drives any manufacturer.
In consumer space it’s probably 1 sale for every 100 Windows. If you’re constrained on engineering resources guess which one you won’t care about ?
1 to 100 in the consumer space seems to me extremely optimistic, not sure if I'm betting that it's a 2 or 3 orders of magnitude miss.
I know it's not representative of the consumer space as a whole, but Linux users apparently make up about 1% of the Steam userbase fwiw https://www.phoronix.com/scan.php?page=news_item&px=Steam-Li...
Yeah, but that 1% can choose either the Linux reference hardware or keep buying some other random laptop and throwing Linux on it.
So, the market is really rather less than that 1%...
So, the market is really rather less than that 1%...
Well, since Steam is the only gaming platform available on Linux, and since Steam is sold as a system based on linux with its own Linux distribution, SteamOS, and since Steam have its own version of Wine that magically runs Windows games on Linux, I would say that this statistic says nothing at all.
It would be difficult to get the mainstream vendors to match this initially, but I suspect the Linux focused vendors like Pine and System76 would do so fairly rapidly.
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.
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.
I mean, Pine's and System76's laptops don't even use the same CPU architecture as each other currently...
Some certification of genericity required for all future device purchases by publicly funded institutions, for example.
That's what Microsoft did. Initially there were a lot of issues and also things like hibernation didn't always work right.
Linux needs to have similar certification. The rest would be to have customers look for it and prefer hardware that's certified.
Linux needs to have similar certification. The rest would be to have customers look for it and prefer hardware that's certified.
You mean something like this:
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).
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).
> 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 then I guess they aren't really doing their job when certifying things that don't work.
HW vendors that want to race to the bottom, sure.
But if I want to differentiate, commanding a higher price, then I'll probably be different.
But if I want to differentiate, commanding a higher price, then I'll probably be different.
> I think the non server Linux community needs a reference device.
The question is, who is going to make this reference device? Intel? AMD? ARM?
The question is, who is going to make this reference device? Intel? AMD? ARM?
imo they already have them--they're all the unsupported macbooks
Apple computers might actually be a good device for that role. Enough variability to cover most pricepoints, high quality build, consistent components.
Good luck trying to get specs out of Apple.
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.
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.
Also the amount of stuff the firmware does nowadays, especially on a laptop, is quite high. The OS-UEFI interface is quite complex and involves a fair amount of firmware code which keeps running after boot. This code is heavily involved in operations like suspend and hibernate, and is usually developed by the laptop OEM themselves, so quality is not very high and they have little incentive to test with anything other that windows. This results in a tendency towards fragility (even with windows), as well as worse battery life under linux.
And besides all that, hibernate is fundamentally more complex than sleep. With sleep, when waking up the computer resumes directly to the already loaded operating system in RAM, and the operating system "only" has to restore all the hardware state. With hibernate, the computer does a clean boot of a fresh copy of the operating system, which has to initialize all hardware, read the hibernation image, de-initialize (quiesce and/or power off) all hardware, and finally jump to the copy of the operating system found in the hibernation image, which only then will restore all hardware state.
On top of that. All that state is written to disk, and if someone else goes romping through where you've written your hibernate state to, you get a corrupted state to restore to.
Speaking of disk, on a laptop where hibernate did work, I once ended up with more disk space available than there was in total, because it was mounted through the hibernate and I was using it from another OS. Lucky a reboot fixed that bit of weirdness.
how does winndows resolve these issues?
Most hardware device vendors write Windows drivers and test them. Since they built the hardware, the vendor driver developers are privy to all the internals. Windows also has a stable ABI for drivers.
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).
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).
And even with all these advantages, my four month old Windows laptop fails to resume from hibernation 3 times out of 10. Sometimes wifi won't work, sometimes USB won't work, sometimes it just freezes.
Don't forget that "hibernating" a laptop with a lot of RAM might take long enough to run down your battery.
I think Hibernation has been impractical since 2013 or so.
I think Hibernation has been impractical since 2013 or so.
It's basically impossible for hibernating a laptop to take more than about 5-6 minutes unless you deliberately configured it with insanely imbalanced components, ie. more RAM than mainstream laptop hardware platforms support, and the slowest storage you can find.
Could still be a problem if you are expecting hibernation to save you at 1% battery remaining.
Especially when 1% is displayed as 5% or 10%.
The monster laptop consumes more power because it has all of that RAM, the battery is sized to "not cause a crisis on an airplane if it burns up" not to power a machine of that type, particularly after a year of battery aging.
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 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.
SSDs have also been getting pretty fast, though.
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.
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.
Really? Hibernate has never taken more than 30 seconds for me even on a mediocre laptop with an HDD.
My bog-standard PCIe laptop SSD writes at 3GB/s, so anything over 10s seems like it is an implementation problem not a hardware limitation.
Strange. I never reboot, only use hibernation. I've been doing that for years and never had any problem.
You might want to share your setup then.
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.
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.
Same, the main instabilities come when I go out of hibernation with changed hardware, ie. haven't plugged back the mouse or changed the display from desk to meeting room
Also availability of drivers in Windows doesn't necessarily mean everything is comfy, certain manufacturers/BIOS vendors were notorious for not implementing ACPI correctly leading to several such issues; I hope with UEFI things have improved.
I’m wondering if a clever solution of presenting the Windows ABI to drivers but translating to Linux calls under the hood would be feasible?
It is, but the point of not defining a Linux ABI is to avoid proprietary, binary blob drivers and instead force drivers to exist in the upstream Linux kernel where they can be maintained by the kernel developers and freely distributed.
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.
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.
"The kernel can be changed freely without worrying about supporting drivers that cannot be updated because they only exist as binaries."
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.
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.
There will never be a year of the Linux desktop if ideological purity (of a highly questionable ideology in the first place) continues to stay in the way of practicality. Grandma doesn't care if her network driver doesn't give her the whatever number of software freedoms as defined by RMS and honestly neither do I.
If you really care about user experience, I recommend seeking out products made by companies that are vertically integrated, like Apple, because they have the power to curate the components of their products for maximum compatibility and support.
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.
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.
That is what I thought when I decided to give money to Asus with 1215B pre-installed with Linux, I was wrong.
Grandma doesn't care about the year of Linux on the Desktop either because she probably just uses a macbook to manage the server farms that are running on Linux and won't need to hibernate.
Honestly how old is "grandma" in 2021? Grandma is probably 60-70 years old, and likely grew up in the "space age" of computers. She likely has a Facebook and uses an Android phone. Grandma should take some time to learn the Linux way, she'll be a better computer user for it.
Why should she? Grandma primarily uses Facebook, Instagram, and Facetime. Grandma doesn't have a goal to become a better computer user in general terms. Linux gives effectively 0 value to her over any other OS. And negative value in a number of various ways. Driver support among them.
At this point, I wonder if Grandma wants a desktop at all. Maybe Grandma just wants a tablet, perhaps with a keyboard. Tablet OSes don't really hibernate, but they use a lot less battery and have software designed to come back from a cold boot quickly.
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.
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.
Or she doesn't care about computers and just wants to call her friends via Skype in a pandemic. Why would she care about becoming a better computer user?
Yes, your type of grandma exists, but I don't know her.
Yes, your type of grandma exists, but I don't know her.
> she'll be a better computer user for it
Who (outside of HN readership) wants this?
Who (outside of HN readership) wants this?
Linux is tremendously successful. You want to enforce restriction on kernel developers because of "grandma", that's impractical.
Linux is tremendously successful as server OS.
Desktop - not very much, because of "grandma"
On server and Android, and IoT. Sleep is enough for my laptop.
I hardly doubt you are kernel developer yet you "know better". Such people always do.
I hardly doubt you are kernel developer yet you "know better". Such people always do.
One doesn't have to be kernel developer to acknowledge the fact that Linux on desktop is not doing very well.
By the way, Linux did well on Android because it is made there with "grandma" in mind.
By the way, Linux did well on Android because it is made there with "grandma" in mind.
Kernel is one of the best parts about Linux on desktop. It works. I've recently tried Windows, annoyed by hibernate, few seconds to wake up but sleep is instantaneous.
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.
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.
>> You've said hibernation is a matter ideological purity
I've never said that.
I think this conversation is going nowhere, no reason to continue it.
I've never said that.
I think this conversation is going nowhere, no reason to continue it.
None of the issues mentioned are about some theoretical ideological purity, they're all about very practical pragmatic concerns. There are a lot of open source software that put some ideological purity above all other concerns, but the Linux kernel is certainly not among them - if anything they're among the most "flexible" when it comes to GPL compliance.
It's easy to criticize the chosen trade-offs, but I would argue that Linux would actually be in worse shape today if it had taken the driver ABI approach and encouraged proprietary drivers. Many drivers originally upstreamed in the 32-bit x86 era would no longer be usable on amd64 had they been 32-bit proprietary drivers, and a good number of 64-bit proprietary drivers would be useless on ARM platforms like the Raspberry Pi.
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.
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.
Sounds a lot like NDISwrapper.[1] God, that was a pain in the ass.
[1]https://en.wikipedia.org/wiki/NDISwrapper
[1]https://en.wikipedia.org/wiki/NDISwrapper
I don't miss that. But it was better than the alternative at the time...
"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.
"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.
AMD tried something similar and the Kernel maintainers rejected the patch. At least that's how I understood it. I think this is a HN post about it: https://news.ycombinator.com/item?id=13142285
[deleted]
As others have said, essentially by being the single os for a multibillion dollar pc industry for decades. I forget exactly when the hibernate api came online... 90's?... and Microsoft has a porting layer test suite as a manufacturer that you have to pass to get that little windows stamp. All done by paid professionals and spread over the cost of the large number of pcs sold.
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.
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.
Delegated and distributed responsibility.
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.
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.
It doesn't, really. Hibernation and even the levels of "sleep" mode have and still have issues in Windows. I have a brand new Dell Precision workstation that still can't properly come back from sleep mode every time.
I haven’t had any issues with hibernating or sleep on windows with any device I’ve owned.
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.
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.
You've never had games that would only start and run without crashing from a clean boot?
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.
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.
I've never had that problem. :D
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 :(
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 :(
I dual booted Win10 and Ubuntu on my laptop and I could only use the dedicated graphic card in Ubuntu if I turned Windows off with the power unplugged. Maybe that was a symptom of similar properties?
Windows 10 doesn't completely turn off by default anymore. It closes all the applications and then hibernates the Windows system stuff so doesn't need to re-initialize everything on boot. There's a way to fully shut down but you'd have to look into that.
Heh, as I've posted above, I've had the reverse. All kinds of weird broken behavior on Windows, everything works perfectly on Linux.
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.
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.
Same.
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.)
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.)
The reason is that Dell replaced S3 sleep with Modern Standby.
Modern standby is turning on my XPS so much it can actually get dangerously hot in my backpack.
Modern standby is turning on my XPS so much it can actually get dangerously hot in my backpack.
"Modern Standby": https://www.dell.com/support/kbdoc/en-au/000177661/what-is-m...
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.
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.
Thanks. This, and the GP, are helpful. Does naturally lead to the question of why in hell they'd implement this when, from my perspective as a user, it's much MUCH worse than S3 sleep.
The Bay Trail Atom-based tablets used this, they behaved really like oversized x86 smartphones. When it works ;), it is quite impressive.
You can enable Network Disconnected Modern Standby. Documented well at https://www.tenforums.com/tutorials/108378-add-networking-co... and https://www.tenforums.com/tutorials/146593-enable-disable-ne...
I recommend the powercfg command line approach instead of the UI.
I recommend the powercfg command line approach instead of the UI.
My Macbooks have cooked themselves in my backpack plenty of times over the years.
Sure, mine's done it occasionally (rarely enough to be a surprise when it does happen), but do they do it every single time you put them to sleep? I doubt it. My Dell does this every single time it goes to sleep. It's really aggravating.
If you use an SD card, Apple issued an update to have it cook itself every single time, and never enter hibernate, to sell more 2-3x markup native storage space. If you try to fix it, the next update will break it again.
I don't use Windows so I didn't know what Modern Standby is. I googled this page https://docs.microsoft.com/en-us/windows-hardware/design/dev...
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?
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?
> 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.
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.
On ThinkPads it can be disabled in BIOS.
> Don't you have a way to disable it and go back to what Microsoft calls Traditional Sleep?
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.
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.
What happens if you install Linux? Does it stay in traditional sleep because there is no software in the OS to temporarily awake the computer?
The new Dell laptops only support "modern sleep". Linux doesn't support this very well, so while things look to go to sleep (eg, screens turn off) the system is still on, just idling. Since Linux doesn't have all the hardware support that Dell's drivers for Windows might, not all hardware devices are put into a low power mode.
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.
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.
Sleep doesn't always work on Macs. For instance, when the kernel panics because you shut the lid and stuffed it in your bag before you detached your USB-C mouse and keyboard, so it's overheated or dead by the end of your commute.
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.
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.
Highly specific to Dell XPS laptops, but I used to have a similar issue to this. Eventually realised that the display wasn't actually turning off sometimes when I closed the lid. After much mucking around, it eventually turned out that in some of these laptops the magnet in the lid that triggers the "lid closed" action can become physically unstuck, and move around in the display housing (on my XPS 9350 this is in the bottom right corner of the display). Using an external magnet to jiggle it around both allowed testing to trigger the sensor and confirm the issue, and also to move it back to its proper location. Seems to work properly again now.
Windows machines have the habit of waking from sleep after 3 hours, to do whatever and then fail to go back to sleep when they are done. I only use hibernate for that reason, on an Ssd resume is fast enough.
I got rid of my MacBook about a year ago but when I had it sleep never always worked for me. My current current ThinkPad is just as reliable when sleeping as my MacBook was.
Some XPS models from recent years have known sleep problems. There is essentially no fix. The best you can do is switch to "network disconnected modern standby." Search for my other post in this thread.
I bought a new Dell XPS13 two weeks ago and discovered the hard way - after totally flat batteries - that sleep mode doesn't work. Whereas my other XPS13, the previous year's model, works perfectly.
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)
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)
Adding to my comment on my XPS13 7 days ago:
* 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.
* 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.
I believe that on (some?) Intel 11th gen chips, S3 sleep states are disabled, and only S1 works?
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!
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!
Sorry to hear it's happening in the latest generation product too. This is really disgraceful by Dell as the issue has been known about for years and they don't seem to care. Same with the crappy thermal pasting job that their factory does.
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.
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.
I have issues on all the Macs I own too, it honestly seemed to work perfectly but about 3 years ago maybe they all became unreliable after some OS update, I want to say maybe High Sierra.
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.
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.
Yep. I have a Surface for work. It just reboots when you tell it to hibernate or even sleep.
I have a gaming PC with Windows and Linux. "Sleep" on Windows fails every second time for me (the screen is off but the machine continues to run), whereas on Linux it fails every ~10th time. No idea what the issue is but I have fairly standard hardware.
On the other hand, I can't remember the last time sleep didn't work on any of my Macs.
[deleted]
How long are you giving it for sleep to actually turn off? "Hybrid sleep", which is on by default now, can look like this - the monitor and peripherals will turn off first and then it can take another minute or so while the machine writes out its RAM for the hibernate portion.
I had an odd issue with Windows sleeping on one of my machines a while back.
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.
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.
Sleep might not be hibernate. If it's just standby some device (Mouse, ethernet ...) might wake it instantly.
My old T420 couldn't sleep overnight in Windows 7 (something would trigger a resume), but would sleep fine under Linux and FreeBSD.
They make it the OEM's responsibility. The board integrator tests hibernate, sees that it fails, checks the docs, eventually figures out that it's the driver for (just to invent a random example) their oddball audio codec forgetting to reset the RST_OR_BADSTUFF register on hardware reset, so it starts pushing bad data at the hardware DMA controller which confuses the media stack.
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 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.
Meh. For what it's worth, Windows doesn't always do this right either.
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).
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).
I had to disable "Fast Startup" in Windows because it would make WSL lose its mind. So whatever they are doing, it has issues as well.
Here, the trackpad is broken after fastboot 1/2 times (basically registers button presses all the time, making it unusable). Without fastboot no such issues, plus modern machines boot fast even without fastboot ;).
Wsl1 wsl2 - No issue with fast startup, sleep or hibernation
Even windows has sometimes troubles with it. On work with my HP ZBook and the HP Docking Station I had many, many crashes and bluescreens allways, when I the external monitors felt asleep. Now, no monitors goes blank ever and since then everything works fine.
My windows think pad has had a super buggy hibernation for a few years. Better than Linux laptops I’ve tried, but still not at all solved. Only my mac seems to get hibernation right.
I don't believe the latest version of macOS supports Hibernation anymore. At least I couldn't get it working with an hour or two of finagling/googling around.
Closed hardware platform, no coincidence there.
Pay people to fix these i-hate-my-life bugs.
I've seen companies run shelves full of sleep-wake machines. sleeping and waking. sleeping and... yawn... waking.
I've seen companies run shelves full of sleep-wake machines. sleeping and waking. sleeping and... yawn... waking.
In my experience, it doesn't. Hibernation is a hit and miss on Windows too, just less so.
With Windows 10 shutdown means hibernate so if it’s flakey you’ll crash every time.
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.
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.
When does restoring state become a necessity as opposed to just disconnecting the devices upon hibernate and reconnecting them afresh when the device wakes up?
If there is a running process using that device before/after hibernate, it needs to know it should re-configure it. There is currently no way to pass this information to a Linux process, and quite a task to add the feature to all existing programs.
Right, that seems more tractable than trying to restore the actual state of the device though which sounds like a different problem.
Why not create a low-level hardware state interface layer that linux uses to save/restore hardware state. The attitude could be "it's not linux's job to fix your hardware" At first nothing would use it and it would be basically useless, but eventually manufacturers would add support. In the meantime, Another layer on top of this low layer could be created to make older hardware compatible. For hardware that is worth the effort, people could write drivers or other things that could bridge the gap between hardware and the low-level interface.
The problem with that is that it doesn't work. People will buy the cheap broken hardware and then complain that Linux doesn't work. That's basically how it is already.
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.
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.
This wouldn't be a silver bullet, many hardware have their own controllers, with their own firmware and their own state that the kernel cannot directly control. And for the same type of hardware some might have a full reset with a power cycle, and other might not.
For some reference you can look at the GPU reset bug for navi 10 and below.
I remember things like getting initialized by at boot cleanly vs coming back from sleep and having to remember the no-boot-state setup.
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.
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.
Have no clue from hardware, but why we cannot take a full memory snapshot to the hard disk and then just load it back bit to bit ?
The "memory", or more like "relevant state" is spread across lots of hardware pieces. It's not just RAM. Saving all RAM blocks is indeed easy. Consider the RAM of the graphics card as an example, it can have lots of complicated structures stored by the running programs.
After setting up a swap partition of sufficient size, hibernate worked with no issues whatsoever on my very recent hardware and kubuntu. The main reason it's disabled by default on ubuntu is that the default partition setup isn't compatible with hibernation for most memory sizes. You need a swap configuration that's large enough to fit your entire RAM and also your current swap. I find it works at least as well as on any other OS. I currently have it configured to auto-hibernate on low battery or after some number of hours of sleep. From my point of view the Linux community is doing absolutely great on that front, and I've never had a machine where hibernate didn't work correctly. The main issue here is the defaults on one distribution (ubuntu) make it a massive pain to enable.
And you need to find some buried comment on hacker news to figure out that partitioning is the problem! Thanks!
Use the Arch Linux documentation it's often helpful even if you don't use arch Linux.
Or the Gentoo-one or Debian or even the Kernel docs regarding resume=<partition>. There are a few things to consider:
- 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).
- 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).
> - it does not work on encrypted partitions since there is no way to unwrap any key at all
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).
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).
I have hybernation working fine with root and swap under lvm in a luks encrypted partition. Pretty sure when I set up ubuntu 16.04 or 18.04 it just worked out of the box. Though sound doesn't like to come back properly for the headphone jack and I need to rmmod/modprobe the driver.
Same here - the swap partition to match the memory size did the trick. I'm on a Lenovo 480. To hibernate, I just type in "sudo systemctl hibernate" and it works, I'm happy.
Incidentally, I've just upgraded my RAM to 64GB and it's in the process of resizing the swap partition right now!
Incidentally, I've just upgraded my RAM to 64GB and it's in the process of resizing the swap partition right now!
it usually works out of the box but the swap won't be encrypted. that may or may not be what you want. a proper solution with random generated key to encrypt swap takes some extra steps:
https://help.ubuntu.com/community/EnableHibernateWithEncrypt...
https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryptio...
https://help.ubuntu.com/community/EnableHibernateWithEncrypt...
https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryptio...
This was a fascinating comment to read - thanks for the insight.
> 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?
> 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?
The memory contents have to go somewhere. They can't stay in RAM as RAM will be powered off. If there's sufficient free swap space they go there. If there isn't, the current swap and memory contents get compressed and it then goes to swap. If there's still not enough space, hibernation will fail. So if your swap is filled with incompressible data to its full capacity, you will not be able to hibernate. This is very unlikely if your swap is enormous, but it can happen.
That's for taking the time to explain - makes perfect sense - cheers.
This seems like a bug because it means system state results in unpredictable behavior. There should be a dedicated swap for hibernation, like the pre-allocated hiberfile used by Windows.
you can set it up that way if you prefer, there is a resume= kernel param you can set to a separate file or device. I keep them combined tho because I hardly ever use much swap, and don't have a ton of disk, and if hibernation ever did fail, I can just close some tabs and be fine
Make the swap partition equal to 1.5 times your RAM. That's always worked for me.
Everything in RAM and Swap will be compressed when you want to hibernate.
It's going to depend on your hardware and probably your distro.
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.
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.
Because you mentioned secure boot and encryption: Matthew Garrett wrote an interesting blog post a while ago on making hibernation work with lockdown mode, i.e. verifying that the hibernation image wasn't tampered with. Otherwise it might be possible to get around the whole secure boot chain by writing a compromised kernel to a hibernation image. It's quite interesting to think about, even if it isn't necessarily something you as a user should need to think about (distros should probably handle it): https://mjg59.dreamwidth.org/55845.html
I read up a bit on this when I was setting it up.
> 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.
> 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.
No, this isn't beyond evil maid - it doesn't require physical access, it only requires root access.
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.
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.
> You can have your cake and eat it too.
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.
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.
Works fine with me with amdgpu. It's included in Firefox by default and it works great after enabling it.
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.)
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.)
> Can you get gpu accelerated video playback in Firefox[...]?
Yes. (not with nvidia drivers.)
Yes. (not with nvidia drivers.)
ah, well yeah I didn't mean all Linux issues are solved.
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.
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.
I haven't been diligent about secure boot. I could imlrove. With regard to hibernation, I avoided hibernation for years under the assumption that it was untrustworthy. Sleep felt "sufficient", safe.
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.
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.
And it's really easy to setup hibernate on archlinux.
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.
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.
Out of curiosity, do you know the functional difference between a swap file and a swap partition? A swap file seems like quite a bit more added complexity with very few benefits.
The kernel cheats: on start up it figures out which sectors the swap file uses (best if it is contiguous on the drive) and doesn't actually use the file system to read/write swap. This allows it to achieve the same performance for a file as a partition.
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...
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...
How does that work with log-structured filesystems (or any filesystem that does online defragmentation)?
AFAIK it doesn't, it expects a continuous file without fragmentation.
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.
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.
ZFS zvol works as swap even though CoW can't be disabled, how does it 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
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
Not even MacOS gets it right if you confront it with the same problem that Linux is facing.
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.
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.
Curiously, the M1 Macs don't support Hibernation at all. The feature has been dropped. (run `pmset -g cap`, you’ll see that hibernatemode and hibernatefile have disappeared.)
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…)
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…)
Yes that is because Apple promises that everything works iff you buy hardware and installation of it from them. I changed a RAM module once and hibernation stopped working, Apple says that is because it's not the identical RAM-module they sell. So their list of supported hardware is pretty small
Historically there have been sites that tell you which RAM modules work with OS X. It's usually the higher end stuff, but then again the modules that come with OS X tend to be better than average to begin with.
As I've gotten older, and am not having to pinch pennies quite as badly, I just buy Apple expansion hardware from the places that specialize in it. I was refurbing one MacBook Pro of some era (2012 maybe?), and it simply would not play nice with an ADATA SSD (recognized it, but data transfers were so slow the OS wouldn't install - known issue, apparently). I saved a bit compared to the OWC option, except I wasted an afternoon of messing around and had to buy the OWC option after all.
Some RAM modules not working at all makes sense, though.
A module working for everything except hibernate is ridiculous.
A module working for everything except hibernate is ridiculous.
My 2020 Intel Macbook Air crashes every single time it falls asleep while attached to an internal monitor, on Catalina and Big Sur
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 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
My M1 MacBook Air never shuts down cleanly, it reboots on it’s own and after login prompts to send error report. It has happened every single time.
You have defective HW or you have installed 3rd party driver that is broken. If the 3rd party HW driver is out, take it to Apple and get a new one. Really.
I did call Apple service. They suggested creating a temporary new user and logging into that account. It shuts down cleanly from that account, means there's some third party software or config that's causing the issue. It's not easy to pinpoint the problematic software.
Thanks will do it.
About 1/10 times I have to either unplug my USB-C monitor cable, open my Intel MBP, or both, in order to get my Mac to wake up properly.
I had similar issues with my Surface Book 2, though it wasn't as pronounced as my mac.
I had similar issues with my Surface Book 2, though it wasn't as pronounced as my mac.
This is why Apple uses custom SSDs and you should never switch to another NVMe, even when adaptors are avaiable.
Personal hot take: It's super hard and no one cares very much.
With SSDs, booting is fast. Most apps that I care about which have complex state (browser, IDE) do a much better job of saving their state than the OS can do (browsers & IDEs can and do easily restore sessions, etc).
With SSDs, booting is fast. Most apps that I care about which have complex state (browser, IDE) do a much better job of saving their state than the OS can do (browsers & IDEs can and do easily restore sessions, etc).
Plus, with full-disk encryption, I don't want my key getting written to disk so that anyone can get it until the end of time. I'm okay with my laptop powering down fully after sleeping for some amount of time.
If you use a swap file on the encrypted root partition then initramfstools will actually ask you to enter the password before it can resume from hibernation - the file is encrypted like everything else on the partition.
Interesting read here: https://mjg59.dreamwidth.org/55845.html ("Making hibernation work under Linux Lockdown")
Discussed in HN: https://news.ycombinator.com/item?id=26285683 (113 points, 39 days ago, 64 comments)
Discussed in HN: https://news.ycombinator.com/item?id=26285683 (113 points, 39 days ago, 64 comments)
The link you posted is talking about the security implications of hibernate when also using lockdown (a kernel security feature). It has nothing to do with getting hibernate to work in general.
I imagine that kernel lockdown is the main reason why hibernate doesn't work out of the box for most people ATM.
Are you sure? Which distros ship with Linux lockdown by default? I was under the impression it was a niche security feature.
One reason is that a big community effort to rewrite the suspend-to-disk layer, which made it more reliable, called TuxOnIce, was kept out of the mainline kernel for a number of reasons, and thus a lot of "community energy" for solving the problem has been sapped out. Also, this is a uniquely "desktop Linux" problem, so exactly the kind of problem that rarely gets commercially sponsored developer hours thrown at it.
https://en.wikipedia.org/wiki/TuxOnIce
https://en.wikipedia.org/wiki/TuxOnIce
I am surprised that your comment is the only one that seems to engage with the historical reality of suspend and hibernation on Linux. So many people seem to be ignorant of kernel history, and how things came to be the way they are.
I followed kernel development closely 10-15 years ago, paying particular attention to hibernation because, well, it was rather more useful back then! And one thing that gradually became clear over the years was that there was one person in the kernel community, with a lot of responsibility, who was completely and utterly incompetent to handle that position. That one person, in my opinion, set Linux hibernation back by more than a decade.
I followed kernel development closely 10-15 years ago, paying particular attention to hibernation because, well, it was rather more useful back then! And one thing that gradually became clear over the years was that there was one person in the kernel community, with a lot of responsibility, who was completely and utterly incompetent to handle that position. That one person, in my opinion, set Linux hibernation back by more than a decade.
Was the choice to have either one incompetent person or no person?
No. From what I saw, this person actively blocked attempts by others to make things better. It seemed to be something of a classic personal fiefdom. (Combined with a bit of genuine technical incompetence.)
(And to sibling: I'm not going to name any names, since I prefer not to shame in public. Especially when most all of what I did was read LKML, so who knows what background stuff I'd missed. I'm afraid you'll have to come to your own conclusions.)
(And to sibling: I'm not going to name any names, since I prefer not to shame in public. Especially when most all of what I did was read LKML, so who knows what background stuff I'd missed. I'm afraid you'll have to come to your own conclusions.)
Who?
As a side note, if you have a recent laptop, there is probably a setting in the BIOS for sleep mode, Windows 10 vs Linux.
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...
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...
This tends to also apply to whitebox models. I have a no name ODM laptop which has options in the Bios to indicate the system is booting as a Windows, Linux or Android device.
Oddly, enabling Android got the touchpad working in Ubuntu.
Oddly, enabling Android got the touchpad working in Ubuntu.
This switch is gone on late 2020 Dells and forward. It's the new experimental Windows way only.
I was involved in these discussion for Ubuntu ... back in 2011.
You can see some discussion here: https://bugs.launchpad.net/ubuntu/+source/policykit-desktop-...
and even more here: https://bugs.launchpad.net/ubuntu/+source/policykit-desktop-...
net/net even back then, no matter how much effort we put into it, we could never make it work on even most machines because there was just too much variability. The OEM team could make it work for specific machines that Ubuntu was pre-installed on, but otherwise, hibernate was just a bug farm.
You can see some discussion here: https://bugs.launchpad.net/ubuntu/+source/policykit-desktop-...
and even more here: https://bugs.launchpad.net/ubuntu/+source/policykit-desktop-...
net/net even back then, no matter how much effort we put into it, we could never make it work on even most machines because there was just too much variability. The OEM team could make it work for specific machines that Ubuntu was pre-installed on, but otherwise, hibernate was just a bug farm.
Hibernate with LUKS (albeit after a lot of hacking) works pretty well on Debian Buster. I've resumed and hibernated for many cycles with no issues. Wifi comes back etc. It never used to be the case, in my experience at least
I just wanted to write it works without any hacking on Arch Linux, then I realized that 100% of the Arch Linux installation process would normally count as hacking. So I guess hacking it is. ;-)
Same here, I'm using it all the time with Debian on two laptops (Latitude and Thinkpad) and it's stable for me.
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
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
I have to be honest, I struggle to think of a scenario where simply putting the computer to sleep isn't the better option. If power draw is a concern, just power the computer off? It's certainly not worth having a 16 or 32 GB swap partition on my machine just to enable hibernate
I was hoping to replace my laptop with a NUC running Linux, that I would transport between home and office. Since a NUC is a (small) desktop machine it doesn’t have a battery. Hibernate would have been great.
Hibernate IS great, IMO. It saves massive battery life, nobody cares about the hiberfile size with large disks, and for me it’s often more reliable than S3 sleep. Sleep may run out of battery and I lose everything open. Sleep may not power back up correctly and I lose everything open. I only use sleep mode for short trips between locations, with car rides or walking to another office. But overnight? Hibernate or shutdown for me.
For desktop computers it makes sense. I find that hybrid hibernation gets the best of the two world. I can have the PC in sleep and have it turn on faster, or if the PC looses power you don't loose anything.
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).
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).
> If power draw is a concern, just power the computer off?
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.
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.
a bit of storage is easily worth the benefit for me. Now if I had some superthin laptop with soldered-in SSD at exorbitant pricing that might be different, but other than that disk space is not that much at a premium.
I don't think this is true.
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.
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.
Yeah have the same issues with modern MBPs, it feels like Macs used to handle closing the lid perfectly then at some point in history is broke and they're not fussed enough fix it. So many times all my MBPs awaken to either a KP screen or a "Your machine restarted because of a problem" message.
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.
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.
My very naïve understanding of hibernation was that basically RAM was written to disk as some sort of image, and coming back from hibernation means loading that back into RAM... I'm getting the impression that this is very much not true.
I can't, however, easily find an explanation of how actual hibernation is different from this simplistic understanding.... would someone care to explain?
I can't, however, easily find an explanation of how actual hibernation is different from this simplistic understanding.... would someone care to explain?
At a very, very high level, you're exactly correct. The state of RAM is written out to disk, and on restore, it's loaded back into memory, and stuff resumes.
But the devil is very much in the details, and you may not have access to any of the details because the datasheets are NDA'd or just flat out not available to anyone outside the OEMs.
The problem is mostly around hardware state. I've written some sleep patches for Linux on a PineBook Pro (I should finish those and try to upstream them...), and the problem is that on restore, you have to put the hardware exactly as it was when you put it to sleep, or things just don't work. The details of both querying the hardware state, and putting it back, range from "fairly straightforward if inefficient" (copying out device register state on sleep, restoring state on resume - but which of them actually matter?) to "really, really nasty, involving going through the init sequences again, then updating state in the proper order."
Resuming from hibernate is almost the same as a cold boot, except that it's a different shutdown state, so the boot firmware may or may not do things the same as on a cold boot. If you've moved PCI devices around to where you want them instead of where the boot firmware put them, you have to shuffle them back to where you want them - and do this in the correct order, which may or may not be the same as the ordering you did it when the kernel first came up.
If any of this isn't done properly, the system will be in a weird state and things might not work on resume. The patches I wrote for my PBP work fine, unless there's audio playing when the system goes to sleep. Then it still doesn't restore audio state properly and I've not taken the time to dive into the Linux sound system enough to understand why... and this is sleep (suspend to RAM), not hibernate (suspend to disk). Coming up from hibernate, the device state might be entirely different.
Like just about anything with modern computers, a simple idea turns into an absolute minefield of implementation details, and the Linux side of things is hindered because you often simply don't have the datasheets. So now you have to reverse engineer Windows drivers if you want support, or guess that, well, this device is in the same family as that similar device we have a leaked datasheet for from some OEM's FTP site, so maaaaybe it uses the same weird register layout, and... etc.
But the devil is very much in the details, and you may not have access to any of the details because the datasheets are NDA'd or just flat out not available to anyone outside the OEMs.
The problem is mostly around hardware state. I've written some sleep patches for Linux on a PineBook Pro (I should finish those and try to upstream them...), and the problem is that on restore, you have to put the hardware exactly as it was when you put it to sleep, or things just don't work. The details of both querying the hardware state, and putting it back, range from "fairly straightforward if inefficient" (copying out device register state on sleep, restoring state on resume - but which of them actually matter?) to "really, really nasty, involving going through the init sequences again, then updating state in the proper order."
Resuming from hibernate is almost the same as a cold boot, except that it's a different shutdown state, so the boot firmware may or may not do things the same as on a cold boot. If you've moved PCI devices around to where you want them instead of where the boot firmware put them, you have to shuffle them back to where you want them - and do this in the correct order, which may or may not be the same as the ordering you did it when the kernel first came up.
If any of this isn't done properly, the system will be in a weird state and things might not work on resume. The patches I wrote for my PBP work fine, unless there's audio playing when the system goes to sleep. Then it still doesn't restore audio state properly and I've not taken the time to dive into the Linux sound system enough to understand why... and this is sleep (suspend to RAM), not hibernate (suspend to disk). Coming up from hibernate, the device state might be entirely different.
Like just about anything with modern computers, a simple idea turns into an absolute minefield of implementation details, and the Linux side of things is hindered because you often simply don't have the datasheets. So now you have to reverse engineer Windows drivers if you want support, or guess that, well, this device is in the same family as that similar device we have a leaked datasheet for from some OEM's FTP site, so maaaaybe it uses the same weird register layout, and... etc.
Thanks for the detail: I take it that hibernation is not a core need for data centers/servers, and therefore the major distros like Red Hat & Ubuntu aren't particularly concerned about dedicating resources to this problem?
It's been a while since I've done anything with data centers, but I can't think of a single reason one would bother with hibernating a datacenter server. Even dynamic VM load stuff (think a cluster of machines supporting 1000 VMs that can migrate, turn machines on and off based on load) just shuts down machines, as far as I know. You might get some benefits from sleep if you need rapid wake (5-10 minutes for a big server booting from power off isn't uncommon), but... eh. I don't know anyone messing with that stuff at scale, for sure.
Thanks to Secure Boot (AFAIK), you can't implement hibernation until you implement hibernation file signing.
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).
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).
You can, by having LVM on top of a LUKS or a swap file on a LUKS partition.
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.
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.
uswsusp can both sign and/or RSA encrypt the image essentially from the beginning of its existence. On the other hand you in fact do not need that and can simply store the hibernation image on otherwise encrypted device (either as LV on encrypted LVM or as a file somewhere).
Frustrated with my Fedora Linux configuration, I recently got hibernate to work with my Gentoo Linux system.
I have a LUKS (but not LVM) encrypted root and swap partition on /dev/sda3 and /dev/sda4 respectively.
I use the command "su && mount /boot && genkernel --luks initramfs" to generate the initramfs.
I give the initramfs the following parameters: "crypt_root=/dev/sda3 root=/dev/mapper/root crypt_swap=/dev/sda4 resume=/dev/mapper/swap". This makes my initramfs ask for my password for the partitions, then decrypt the partition, then mount them and resume from hibernation if possible.
I add this parameter by setting GRUB_CMDLINE_LINUX in /etc/default/grub, and then running "grub-mkconfig -o /boot/grub".
When I want to hibernate I use the following command: "exec loginctl hibernate". My window managers let me bind this to a keyboard combination.
I am using openrc as my init system (with elogind), and sway/GNOME as my window manager. The computer uses legacy BIOS (SeaBIOS) and the storage uses GUID partition table with the grub bootloader. Hope this helps.
I have a LUKS (but not LVM) encrypted root and swap partition on /dev/sda3 and /dev/sda4 respectively.
I use the command "su && mount /boot && genkernel --luks initramfs" to generate the initramfs.
I give the initramfs the following parameters: "crypt_root=/dev/sda3 root=/dev/mapper/root crypt_swap=/dev/sda4 resume=/dev/mapper/swap". This makes my initramfs ask for my password for the partitions, then decrypt the partition, then mount them and resume from hibernation if possible.
I add this parameter by setting GRUB_CMDLINE_LINUX in /etc/default/grub, and then running "grub-mkconfig -o /boot/grub".
When I want to hibernate I use the following command: "exec loginctl hibernate". My window managers let me bind this to a keyboard combination.
I am using openrc as my init system (with elogind), and sway/GNOME as my window manager. The computer uses legacy BIOS (SeaBIOS) and the storage uses GUID partition table with the grub bootloader. Hope this helps.
You should add this to the Gentoo Wiki.
You are misleaded. Only the Debian and Ubuntu communities are struggling with technical issues, such as hibernation. What do you expect from lawyers running a distro?
The technical linux communities, like Redhat, Suse or Arch figured it out. See eg https://www.ctrl.blog/entry/fedora-hibernate.html
The technical linux communities, like Redhat, Suse or Arch figured it out. See eg https://www.ctrl.blog/entry/fedora-hibernate.html
Hibernation and suspend work fine in Linux on hardware designed for Linux.
I think this sums it up pretty well. As other posters have mentioned, Windows works great until it doesn't, Mac does it well unless you replace some internal hardware with something other than their branded gear. O
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...
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...
Partially. You can also assume that something that does not work on Ubuntu will work fine in a RedHat distro. Esp. something kernel, firmware, systemd, compiler or qemu related.
Maybe some important context that's missing for a lot of people is - on Windows hibernation is disabled by default too. So perhaps the question is, is hibernation still relevant in 2021?
Windows user, still using hibernation. My corpo-Dell has abysmal battery and I definitely don't want to not-hibernate it, nor restart all programs, browsers, terminals etc each time.
It works mostly well. Once every few years I come across some weird issue happening with software X which over time I figure out is linked to software X not handling dehibernation well, but the pros outweigh the cons.
It works mostly well. Once every few years I come across some weird issue happening with software X which over time I figure out is linked to software X not handling dehibernation well, but the pros outweigh the cons.
I use hibernate on my windows desktop every night so that I don’t have to deal with the blinking power light that happens when I just put it to sleep.
Hibernate works great on my Windows laptop too, but I wonder if Microsoft disabled it for a good reason. Perhaps the same instability that Linux suffers from, but on fewer models?
I don't see why not, I do that everyday with my laptop. Saves me the trouble of opening up a dozen programs in the morning.
Reading replies, it seems hibernation is not something that users ask for. What they ask for is to restore the program(s) to the state that they left it in. Files open, state loaded in memory etc. This should be an easier problem than a special boot sequence that is restoring hardware state. There’s probably one or two programs open at a time, that I don’t want to lose my place in, maybe some that I’ve written myself. If we wanted to add a “save state” option in the title bar would that be a tractable problem?
Of course app developers can make a restart less painful too. Web browsers have already implemented restoring tabs from the last use, and Outlook will automatically save any of your drafts. For any work in the cloud, you really just need a pick up where you left off cue.
Of course app developers can make a restart less painful too. Web browsers have already implemented restoring tabs from the last use, and Outlook will automatically save any of your drafts. For any work in the cloud, you really just need a pick up where you left off cue.
I agree that you should be able to suspend individual programs to disk, but I disagree with the idea that application developers should make their own suspend-to-disk functions, as they would all be basically implementing the same thing.
Instead, I think the kernel/OS should implement this feature instead (perhaps as a something like SIGINT that can be overridden). This would be great on hardware like the pinephone, where you have multiple programs vying for memory but only 1 app is really being used at any given moment (because of screen space). As far as I know this is already implemented in android somehow.
I think it would be simpler if the operating system suspended programs automatically, because it already knows how much memory the system has, the memory speeds, and all that, so it could probably figure the optimal way to shuffle programs around.
Instead, I think the kernel/OS should implement this feature instead (perhaps as a something like SIGINT that can be overridden). This would be great on hardware like the pinephone, where you have multiple programs vying for memory but only 1 app is really being used at any given moment (because of screen space). As far as I know this is already implemented in android somehow.
I think it would be simpler if the operating system suspended programs automatically, because it already knows how much memory the system has, the memory speeds, and all that, so it could probably figure the optimal way to shuffle programs around.
Not even Microsoft get hibernation right all the time. So this isn't a issue that only Linux has.
Every time my desktop PC running Windows 10 tries to wake up from a suspend-to-disk or even suspend-to-RAM state, it resets its BIOS and RTC.
Every time my desktop PC running Windows 10 tries to wake up from a suspend-to-disk or even suspend-to-RAM state, it resets its BIOS and RTC.
Hibernation is kinda useless on my laptop with 64 GiB of RAM. Most of my machines have 32, none less than 16.
Hibernation is not a very viable scenario for me. I have uses for a 64 GiB chunk of my solid state storage, thank you very much.
Hibernation is not a very viable scenario for me. I have uses for a 64 GiB chunk of my solid state storage, thank you very much.
The hibernate image is much smaller than RAM: disk cache is dropped and the image is compressed. It of course depends on your use-case (how much incompressible data you have in RAM), but you can expect about one third to one half of RAM size.
But you cannot guarantee it’s going to take half of my RAM size at most. In practice I’m going to see either hibernation failing at times, or maybe my system being hosed at times, because the hibernation image would exceed the expected fraction of RAM size.
Besides, 32 GiB of disk space is nothing to sneeze at as well. I don’t quite trust using dynamically-created swap files as hibernation images, alas.
Besides, 32 GiB of disk space is nothing to sneeze at as well. I don’t quite trust using dynamically-created swap files as hibernation images, alas.
I have a Dell precision laptop from 5 years ago. Every single piece of hardware is supported in Linux, including the smart card reader and the dual Nvidia Quadro and Intel graphics. With Ubuntu 18.04 hibernation, which was enabled, would sometimes cause graphic glitches when resuming. Fixing them required a reboot. From 18.10 onward the issue has been resolved completely. Perhaps this is because of special attention from Dell and Canonical? Linux is listed as full supported by Dell for this laptop. I did ensure I had a swap partition larger than my available RAM.
My day-to-day Linux usage was mostly in the '90s and 2000s, but back then anything related to power management was just like that. Like, power management stuff was generally implemented and available, but often disabled by default because it was only 99% reliable when it needed to be 99.99999% reliable.
Back then the consensus was that it's a really hard problem for all sorts of reasons (including but not limited to proprietary hardware, crappy hardware, etc.), which of course it is, but that given a few years and the shallowness of all bugs under the collective eyeballs of the entire Linux community it was inevitable that it would eventually become rock solid. I just remember a lot of people being really really really insistent about it, and when sophomore CS undergrads on Slashdot are really insistent about things being true then you know it must be true. I'm seeing the same advice here today, so you're in luck! Give it a couple years, it'll be fine. Either that or "Windows doesn't do it that great either". Either that or "nobody actually needs to use power management features and if you do you are computering wrong". Either that or "I've never had a single problem with power management on Linux but I've had tons of problems with it on macOS and Windows so there!" Aren't you glad you asked?!?
Back then the consensus was that it's a really hard problem for all sorts of reasons (including but not limited to proprietary hardware, crappy hardware, etc.), which of course it is, but that given a few years and the shallowness of all bugs under the collective eyeballs of the entire Linux community it was inevitable that it would eventually become rock solid. I just remember a lot of people being really really really insistent about it, and when sophomore CS undergrads on Slashdot are really insistent about things being true then you know it must be true. I'm seeing the same advice here today, so you're in luck! Give it a couple years, it'll be fine. Either that or "Windows doesn't do it that great either". Either that or "nobody actually needs to use power management features and if you do you are computering wrong". Either that or "I've never had a single problem with power management on Linux but I've had tons of problems with it on macOS and Windows so there!" Aren't you glad you asked?!?
I've been using hibernation in Linux for over a decade. Sometimes it's as simple as appending "resume=/dev/my-swap-disk" to your bootloader kernel args.
I think distros don't ship with it by default because it's still slightly tricky to get right in some cases. Hibernating on some hardware can crash or lock your machine. Remember that most Linux distros are still just a puddle of random tools and glue; it's never going to be as polished as a commercial OS.
I think distros don't ship with it by default because it's still slightly tricky to get right in some cases. Hibernating on some hardware can crash or lock your machine. Remember that most Linux distros are still just a puddle of random tools and glue; it's never going to be as polished as a commercial OS.
Is it really worse it though? Today (and for a number of years now) RAM is cheap enough to stuff even low-end laptops with multiple GiB. Unless you have a very fast storage subsystem, hibernating and restoring from the frozen image takes an awful long time. These days many applications, including web browsers (which for many is the only application they ever need), offer to restore the last state, hence you get mostly the same benefit (plus garbage collection).
I use hibernation a lot. I do have really fast storage. (two nvme drives running in raid 0) So it takes maybe 20 seconds to come out of hibernation with windows 10. Which is about twice what a cold boot up takes. But it is usually worth it to not have to get everything open again with the correct files open.
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.
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.
> 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.
You should compare the power use on sleep, not idle.
Very fast storage has also gotten cheap. If you have 16GB of RAM, a $70 Samsung 980 can write your hibernation data in 6 seconds or less.
Because ACPI is garbage.
This. ACPI seems to ensure that platforms have to depend on lowest-common-denominator buggy firmware that is only tested against Windows, all while trying to say there's any benefit at all to allowing laptop manufacturers to hide/abstract away hardware involved in power and fan control from the operating system.
ACPI implementations differ, bugs and crappy ACPI stacks. Faulty firmware is everywhere.
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...
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...
Why haven’t computer companies implemented hibernation for Linux?
If a laptop that won’t hibernate is a defect, it’s a manufacturing defect.
It’s not the fault of volunteers working on a free operating system.
If a laptop that won’t hibernate is a defect, it’s a manufacturing defect.
It’s not the fault of volunteers working on a free operating system.
Hibernation never fails for me with Debian, but sleep sometimes gets in a weird argument with some peripheral where it immediately wakes again. My solution for the sleep problem is actually to hibernate, and after bringing the system up from hibernation, sleep works again.
It's been a while since I worked with Hibernation (S4 suspend) on Linux, so forgive me if any of the details is wrong. Hibernation involves booting a "clean" Kernel and then switching on the fly to the previously stored Kernel after everything is up.
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.
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.
Point 5 seems to apply to s3 as well. Source: my XPS laptop.
I frankly don't trust hibernation on any computer, using any operating system. Too much can go wrong, and testing it is so hard that I don't think any organization really has it solved. It's also hard to beat the power drain of "off".
If you shut down the computer when it's not in use, the problems stated never happen. That's not a solution everyone will use, I guess, but it completely eliminates the problems and is very simple to do. I wish more problems had "simple and complete" solutions :-).
If you shut down the computer when it's not in use, the problems stated never happen. That's not a solution everyone will use, I guess, but it completely eliminates the problems and is very simple to do. I wish more problems had "simple and complete" solutions :-).
sounds like you don't know what "hibernation" is in this context.
when you hibernate a computer, it serializes all of its RAM and the state of all hardware to disk then powers off. Powers off. this is not "standby."
on Windows it generally works flawlessly, and when spinning disks were still the ruling storage mechanism, hibernation was always faster than shutting down and booting again later.
I will admit that I haven't tried using hibernate on any machine with an SSD as a main drive since bootup is so fast with an SSD.
when you hibernate a computer, it serializes all of its RAM and the state of all hardware to disk then powers off. Powers off. this is not "standby."
on Windows it generally works flawlessly, and when spinning disks were still the ruling storage mechanism, hibernation was always faster than shutting down and booting again later.
I will admit that I haven't tried using hibernate on any machine with an SSD as a main drive since bootup is so fast with an SSD.
I have setup hibernation on a arch laptop -
https://austingwalters.com/increasing-battery-life-on-an-arc...
Effectively it will idle for 2 hrs and if I don’t reopen the lid it’ll shut down (saving state to disk). Works really well, boot up is slower than I’d like, but battery life is great. Pretty happy, tbh.
https://austingwalters.com/increasing-battery-life-on-an-arc...
Effectively it will idle for 2 hrs and if I don’t reopen the lid it’ll shut down (saving state to disk). Works really well, boot up is slower than I’d like, but battery life is great. Pretty happy, tbh.
Don't know. Tbh. hibernation always worked for me, but I ironically close to never used it.
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.
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.
In order to get around this I got a 4500U PN50 [0] and two power supplies, so I can take my 'work computer' home with me, it's a compromise but it's good!
[0] https://www.asus.com/au/Displays-Desktops/Mini-PCs/All-serie...
[0] https://www.asus.com/au/Displays-Desktops/Mini-PCs/All-serie...
Is it? I use Hibernate every single day on my EndeavourOS laptop, and I didn't have to configure anything. It perfectly as far as I can tell.
I got hibernation working on my PopOS machine a while ago, but it took a lot of steps. The problem is that it requires a LOT of swap space. That machine has 32GB of RAM—and that means I have to have a dedicated swap partition at least that large to make it work.
Honestly, it would probably be easier to just run everything off a VM if having persistent states matters to you.
Honestly, it would probably be easier to just run everything off a VM if having persistent states matters to you.
Does it need a dedicated partition or can it be created with a loopback file on disk?
A swapfile can be used in place of a swap partition.
https://wiki.archlinux.org/index.php/Swap#Swap_file
https://wiki.archlinux.org/index.php/Swap#Swap_file
At the cost of being practically forced to write your own initramfs, since few of the distro ones actually support this. Surprisingly how few projects use uswsusp anymore...
Wake up from hibernation kicks in early in the boot process, before file systems are resumed. You must have a partition for that.
I think it is possible https://wiki.debian.org/Hibernation/Hibernate_Without_Swap_P...
The default kernel resume implementation will look for a hibernate header in the visible swap partitions on boot.
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.
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.
Research the way to make a swap file (no need for partitions) that has enough room to fit your RAM and hibernation could be usable.
References: https://wiki.archlinux.org/index.php/Power_management/Suspen...
References: https://wiki.archlinux.org/index.php/Power_management/Suspen...
I am a Linux enthausiast but I never got why people need/want hibernation. My Linux laptop (Dell XPS15) boot under 7 seconds... my desktop starts in 10ish (?)
Even if it took 20 I am fine with that. My previous desktop did not even have an SSD and I was fine with a 1 minute boot.
It’s not only about boot time - it’s more about preserving the state of things - which apps are open, where documents are positioned...
It's unfortunately non-trivial to set up and requires a fairly large swap partition
https://blog.ivansmirnov.name/how-to-set-up-hibernate-on-ubu...
https://blog.ivansmirnov.name/how-to-set-up-hibernate-on-ubu...
My brand new Lenovo laptop with Windows would fail to wake up from hibernation quite often. I decided that since it starts up in about 15 seconds from a cold start that I will just power it off every time instead. It powers down in about 10 seconds.
Maybe (almost) nobody cares? I'd bet that most cases where it'd be useful are served fine by sleep mode; S3 and company do use power, but it's so little as to be irrelevant for most people.
[deleted]
Ironically, I think my new Windows laptop handles S4 far more reliably than it can do S3. S3 seems like a coin toss on new laptop platforms until maybe a year or more of driver updates have rolled out.
When I had Manjaro on a desktop machine, hibernation worked out of the box and pretty well. I didn't use it that frequently though. But this was without full system encryption.
I run Arch Linux on Thinkpads. I’ve never had an issue with hibernation.
If you stick to “common” hardware and a high quality distribution you should be fine.
If you stick to “common” hardware and a high quality distribution you should be fine.
[deleted]
Hibernation or suspend?
Both. I suspend my desktop (refurbed ex-corpo ThinkCentre small form factor thing running Arch) but I always go straight to hibernation on my laptops.
With suspend, I hate that nagging feeling that the battery is still running down, even if only slightly, while it's in my bag.
With suspend, I hate that nagging feeling that the battery is still running down, even if only slightly, while it's in my bag.
One issue is CPU power states. Linux doesn't always do such a good job handling power states across various hardware configurations.
I'm surprised to hear this. Hibernation has worked perfectly since installation on all of my Linux computers for the last ~2 years.
I've never had an issue with hibernation. Both suspend to ram and suspend to disk just work.
I think a version of the question including the hardware vendors could be more fruitful.
It's a mess, sure. But it is very much possible to hibernate with Linux. I have yet to find a machine where it doesn't work with the way described here: https://tkainrad.dev/posts/setting-up-linux-workstation/#hib...
TL,dr: Set up large enough Swap and configure Grub correctly
TL,dr: Set up large enough Swap and configure Grub correctly
I have a whole presentation about this — TL;DR asking your BIOS to change power states in Linux is a black art that is performed via the fruits of (usually) reverse engineering or strategic guessing, especially in the UEFI world. Multiply that across all the different hardware combos that can exist, and you can see why this is supported on windows/closed source OSes and not Linux.
Its not? I have using `systemctl hibernate` many time in each day for a year past
It works fine on all of the laptops in my house. We are running kde on manjaro.
Same reason they're struggling with security.
Intel doesn't need it to sell chips.
Intel doesn't need it to sell chips.
Can anyone speak to their experience with hibernate on system 76 laptops?
They can’t even make it remember my screen configuration on reboot...
Works out of the box on my manjaro install.
With your specific hardware drivers, on your specific Kernel revision.
I'm on manjaro and its miserably broken (recent aero laptop)
Why would you expect Linux to work well on a laptop designed for Windows? Do you also expect that MacOS will work on it?
A laptop designed for Windows..
Do you read the ASCII you output ? Does it compile in your mind? In mine it clearly doesn't.
[deleted]
The better question is why are you struggling to volunteer your time to help make hibernation on Linux better?
There's many OS designs out there.
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.
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.
That might explain why some manufacturers don't invest at all in Linux drivers. However in an alternate reality where they sell Linux laptops and Windows turned into a fringe desktop OS for some 2% people (I'm one of those 2% Linux desktop users), hibernation would work very well on Linux and with some luck on Windows. That despite any possible architecture of the Linux kernel: manufacturers would make it work even with a kernel written in COBOL and drivers written in BASIC in a sandboxed DOS virtual machine. /s
I disagree. The Linux Kernel power management framework is quite simple and easy to understand. The problem is mostly driver implementations, which are usually mostly self-contained. But it is possible to design a driver so that it works well in terms of power management.
I don't think the design of linux really affects this very much. The primary issue with hibernation is the interaction with hardware can be quite complex, and the development effort behind linux drivers is generally less than what goes into the drivers on other platforms (and often has less documentation to go on). The core of linux can handle hibernation just fine in my experience, if you're on hardware which linux supports well enough.
Is that right? Very surpised to learn about this. Messy, brutal, nightmare. I’m running Linux as my primary OS more than a decade and find it very stable compared to Win and Mac which I use when it’s a must.
I wonder how such a messy base offers such stability ...
I wonder how such a messy base offers such stability ...
> I wonder how such a messy base offers such stability ...
By not solving problems like hibernation.
By not solving problems like hibernation.
When people are afraid or unable to make changes, you get few breaking changes at all.
Partially right. I have a DIY machine with Ubuntu. There has been display issues, sound issues, and hibernation issues as well. If you go to Ubuntu's bug report website (https://bugs.launchpad.net/ubuntu), there is a huge list of them. It is true for other distros and Windows (internally).
Yes, that's right. Linux is severely lacking in internal structure, and it takes a lot of effort to develop for this kernel. It is easily an order of magnitude harder relative to every other kernel I've touched.
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.
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.