Hibernation is not slow on modern PCs (XPS-15 9500 here), the problem is that Windows 10 can wake the PC from Hibernation at any time, and there's no option in BIOS to prevent that.
I chased all the sources using Windows Event-log and "powercfg /lastwake" and then disable each, but it took DAYS to find them all and make sure it now stays in hibernation.
I had this problem with mt desktop PC, which would randomly wake up from hibernation in the middle of the night. My computer was in my bedroom, so this was very much a problem since the bright screen would always wake me up. I couldn't even shut off the screen since it didn't have a power button (Apple Thunderbolt display).
My solution was to reach around to the back of the tower and cycle the PSU power switch after hibernating the PC, every time.
I have a Dell laptop I bought within the last couple of months. Hibernate is not in the start menu, and the option to add it to the start menu has been disabled.
It's still possible to assign "hibernate" as the action taken in response to various power-related actions such as closing the lid or pressing the power button. This makes no sense; I'm not sure what's going on.
You can enable the start menu hibernate button in advanced power settings:
System -> Power & sleep -> Additional power settings -> Choose what the power buttons do -> Change settings that are currently unavailable -> Check Hibernate.
And then get lucky that your laptop wakes up again (mine dies 1 out of 10 times)
Maybe you have Group Policy settings? Sometimes "Windows tweaker" type apps install these. Also, mine has a link "Change settings that are currently unavailable" which shows a UAC prompt and then enables all checkboxes.
Fedora doesn't even create swap partitions anymore, so you have to enable that first to enable hibernation, enabling it requires you to create a swap-partition, change things in systemd and meddle with the grub-configuration: https://www.ctrl.blog/entry/fedora-hibernate.html
if you use secure boot, you cannot use hibernation under fedora (or any Linux, afaik) since there is no way to "seal" the hibernation image from modification by an attacker who could mount the swap on another OS where they have root. this is regardless of disk encryption.
Secure boot is not that useful anyway. I'm kind of security freak, but I decided that security boot is not worth it. My disk is encrypted to protect from stolen laptop. My BIOS and grub have password to protect from someone using keyboard. Scenario with someone meddling with my boot partition and replacing my kernel with modified one is just not realistic for my life. So just disable it and enjoy proper hibernation, that's my opinion.
I don't know precisely how secure boot works under fedora, but you can have FDE with swap just fine in Linux. A swap partition can live inside a LVM logical volume.
For secure boot I would guess you could have the EFI partition signed/validated with the TPM.
In my case, I use SecureBoot to check the boot image's signature (contains the kernel + initrd + boot params). Then it starts everything from an LVM that lives on top of LUKS. I always have to type in the password (never bothered to get the TPM working), but I don't see why the TPM wouldn't be able to do it.
From the system boot point of view, it just starts an OS. The OS will then proceed to load some data in RAM. It's its business whether this is "fresh" data for a new boot, or "old" data from the last boot.
"Cannot" this is not true. It might not satisfy some sort of branding requirement but at the end of the day all a secure boot implementation does under the hood is to verify the kernel against the signing keys stored in the firmware before handing off control to it. The kernel can do whatever it pleases after that including granting you root access, joining a botnet, or, indeed, loading a hibernation image.
As for security, the hibernation image is at risk unless you use full disk encryption. But then (last time I checked) so is the typical Linux distro because ultimately you (the end user) have complete control over the OS. That means that at some point the kernel has to load and run privileged code that was never signed by some central authority. The only alternative to this would be sending all drivers to be signed by someone else, even those you built yourself from source.
tl;dr You can in fact use hibernation if you set it up, even with secure boot. Doing so is not a security issue. Lack of full disk encryption is always a security issue if physical access is an attack vector you are concerned about.
Huh TIL. Apparently the mainline kernel got a lockdown feature in version 5.4 that prohibits this. Ubuntu started shipping with a version of the patches in 2018. So I guess you'll have to disable that "helpful" feature first if you want to restore functionality.
TBF hibernation has never been entirely reliable under Linux due to hardware vendors being difficult (IIUC). Getting it working for me has typically involved trying to make sense of arcane kernel log messages. I never managed to on my current laptop.
I don't really understand why is it the case. I could understand that sleep is a complex mode, when hardware have to properly sleep and restore. But hibernate is just dumping RAM to disk. It should not require anything special from underlying hardware.
Because reinitialising all the hardware and bringing it back to the same state is hard, and sometimes impossible with buggy hardware or whose full spec cannot be known..
If you create a swap partition manually during installation and there's no secure boot, Fedora will put the "resume=" parameter into your grub config automatically.
You still need to create `/etc/dracut.conf.d/resume.conf` with `add_dracutmodules+=" resume "` line and regenerate initramfs with `dracut -f`. Then it should work.
I don’t really think that hubernating is worth it when you have gobs of RAM and a lot of data and state in it. The sheer time it’s going to take each time even with an NVMe drive, blergh.
Now that batteries are decent and S3 on Linux is good, I don’t bother with anything else. I reboot/power off my machines on a regular basis to make sure the things I need persisted are, in fact, persisted and everything will be brought up again.
So I was quite surprised to find resume= pointing to my swap partition in my /proc/cmdline after a default install.
It isn't. It can add just some seconds (probably less than 5 on fast SSDs, even less if you don't have too much RAM). If people can't wait this little they need to have their lives / jobs / mental health fixed rather than add more orders of complexity (with according increase in problems) into the computers.
On my work laptop (modern HP Elitebook), sleep doesn't work at all (laptop just turns on again after going to sleep), so I'm using hibernate exclusively. Waking up from hibernate takes longer than one minute.
On the other hand, my private laptop (Huawei Matebook) wakes up from sleep in less than 10 seconds.
On my MateBook 13 (2020) the Fn and Shift Lock lights are turned on, while the laptop is still powerd on, but not under OS control anymore:
Sleep takes 6 seconds down and 2 seconds up.
Hibernation is 9 seconds down and 20isch seconds up.
Shutdown is 20isch down and Boot is 22isch to desktop (fastboot=off).
I am quite confused. I thought Windows 10 “fast boot” was hibernation and default “shutdown” behavior. I thought Windows 10 startup times were faster because of hibernation shortcutting the real boot sequence.
Windows 8 and later enable “fast boot” by default which, on shutdown, logs the user out of the current session and then hibernates the logged out state of the OS by writing the RAM contents to disk.
“Full” hibernation is still there, it’s just disabled by default in the UI but not on the OS level.
There’s also this “hybrid sleep” concept introduced since Vista where an OS would go from Sleep state to Hibernate automatically after 180 minutes of Sleep (IIRC, also can be overridden by the OEM) to save the laptop battery further since after the laptop hibernates it’s effectively off.
It’s really confusing and a hell to troubleshoot if something goes wrong. I think Microsoft was trying to apply smart decisions on the OS level _for_ the user but there’s no real indication of what’s actually happening with the system. The naming doesn’t help either, especially after “Modern Sleep” has been introduced.
EDIT: I decided to check myself because I wasn’t sure and it turns out I was indeed wrong. “Hybrid Sleep” is actually about a device going to Sleep and Hibernate simultaneously - it’s so that you can still resume from the hibernated image on the disk in case battery dies while in Sleep. At the same time, you can resume from Sleep right away even before parallel hibernation is finished. I think the intention is that you kinda get the best of both worlds here.
The behavior of going to sleep to hibernate after some time which I’ve described originally is actually something that was there since at least Windows XP.
If your drive is actually capable of sustained 3 GB/s write it would be ~11.5 seconds. However typical NVMe drives are closer to ~2 GB/s sustained which would be more like 17 seconds. (Note GB 8 * 10^9 bits and GiB 8 * 1024^3 bits.)
I guess most people have 16 GiB RAM or less though. I'm not sure why an ~10 second wait is too long given that the user intentionally selected hibernate instead of sleep.
you have 32 GiB of RAM, gibibytes, meaning 32 * 1024^3. does your drive write at 3 GB/s (gigabytes) or Gb/s (gigabits)? if little b bits, it'll be more like 80 sec
if this comment is serious i strongly suggest you inform yourself about nvme drives. they're absolutely worth their money.
i haven't encountered anyone in years that didn't have at least one in their pc/laptop, but if you dont: i strongly suggest you buy one. because writing 30 Gbyte sequentially generally does takes about 10 seconds.
When I got my work laptop, first thing I did is erased its NVMe SSD by writing garbage. It was fast first 30 seconds. In the end sustained write speed was around 60 MB/s. My old HDD works faster. It's fast enough in day-to-day usage, though.
I'll be honest. i haven't encountered a single workload in which i had to write over 90 GByte over 30 seconds (3gbyte sustained for 30 seconds), so you could be correct. Even benchmarks are generally done within 10-15 seconds and my IO is usually constrained by network or CPU at that point.
not sure how that would in any way impact a hibernate routine which would very rarely have to store more then 64gb though.
Problem is that hibernation is slooow so people don't like to use it