3 ms·

It might be a bit of tinkering but you can enable suspend-then-hibernate with logind/systemd which gives you a similar setup to Macbooks but slightly slower to

by f_devd 3y ago

It might be a bit of tinkering but you can enable suspend-then-hibernate with logind/systemd which gives you a similar setup to Macbooks but slightly slower to wake from deep sleep as it needs to go through post/grub again. With the bigger battery provide and new CPU I do hope it lasts longer when idle though.

sowbug 3y ago
Does that require a LUKS unlock step?
- f_devd 3y ago
  I believe so, I remember an article on hibernation+luks being more difficult to set up
  - dathinab 3y ago
    it mainly lacks good UI/UX tools to do so and an agreement on what the right approach is, especially if combined with raid without raid it's not too hard, just bothersome and finding the right information can be annoying the main gotcha is that lockdown mode is incompatible with hibernation (no matter if it's encrypted or not) and some distros enable it by default when secure boot is used, which is most times the case with a full disk encryption setup
hutzlibu 3y ago
"It might be a bit of tinkering" Thats an understatement. I never made suspend-then-hibernate work reliable on linux and I tried it over the years on different systems. So I just had developed the habit of always entering hibernation, if I intend to close the lid for longer. On windows suspend-then-hibernate never failed so far. Drivers are just the crux with linux in too many cases. Not much you can do about it, except reverse engeneering drivers as a side project.
- vetinari 3y ago
  Suspend and hibernate are calls into ACPI, so no amount of driver work is going to help, when the firmware is responsible.
  - hutzlibu 3y ago
    You can also reverse engeneer the firmware if you like, but as a matter of fact, it always worked reliable with windows laptops and not one single time with linux for me (open for suggestions of stable hw). And I am not a kernel dev, but I am pretty sure drivers are in general involved with waking up and sleeping as well. There are just lots of things, that can go wrong there. One small bug somewhere can result in blocking the hibernation => result is a drained battery.
- f_devd 3y ago
  For the framework 13th gen it only required running a fairly recent kernel (>=6.1) for it to work, but that's definitely hindsight
- dathinab 3y ago
  I use it too it's not hard to setup and works well (with very few exceptions and if you use a "recent" enough linux kernel, depending on your hardware). Once hibernation is setup just set systemd [Login]HandleLidSwitch=suspend-then-hibernate and maybe configure the delay with [Sleep]HibernateDelaySec=5min. Hibernation most times works nice too (even with Full Disk Encryption (FDE)) there is just one gotcha, lockdown mode is currently fundamentally incompatible with hibernation (even through it's docs seem to imply something else, they refer to a not yet existing feature). And some distros enable lockdown mode by default if you use a proper FDE setup. Leading to a lot of confusion about hibernation suposedly not working anymore in linux or being incompatible with FDE.
  - hutzlibu 3y ago
    Ok, I will give it a try again, thanks for the explanation.

by f_devd 3y ago

sowbug 3y ago

Does that require a LUKS unlock step?

f_devd 3y ago
I believe so, I remember an article on hibernation+luks being more difficult to set up
- dathinab 3y ago
  it mainly lacks good UI/UX tools to do so and an agreement on what the right approach is, especially if combined with raid without raid it's not too hard, just bothersome and finding the right information can be annoying the main gotcha is that lockdown mode is incompatible with hibernation (no matter if it's encrypted or not) and some distros enable it by default when secure boot is used, which is most times the case with a full disk encryption setup

hutzlibu 3y ago

"It might be a bit of tinkering" Thats an understatement. I never made suspend-then-hibernate work reliable on linux and I tried it over the years on different systems. So I just had developed the habit of always entering hibernation, if I intend to close the lid for longer. On windows suspend-then-hibernate never failed so far. Drivers are just the crux with linux in too many cases. Not much you can do about it, except reverse engeneering drivers as a side project.

vetinari 3y ago
Suspend and hibernate are calls into ACPI, so no amount of driver work is going to help, when the firmware is responsible.
- hutzlibu 3y ago
  You can also reverse engeneer the firmware if you like, but as a matter of fact, it always worked reliable with windows laptops and not one single time with linux for me (open for suggestions of stable hw). And I am not a kernel dev, but I am pretty sure drivers are in general involved with waking up and sleeping as well. There are just lots of things, that can go wrong there. One small bug somewhere can result in blocking the hibernation => result is a drained battery.
f_devd 3y ago
For the framework 13th gen it only required running a fairly recent kernel (>=6.1) for it to work, but that's definitely hindsight
dathinab 3y ago
I use it too it's not hard to setup and works well (with very few exceptions and if you use a "recent" enough linux kernel, depending on your hardware). Once hibernation is setup just set systemd [Login]HandleLidSwitch=suspend-then-hibernate and maybe configure the delay with [Sleep]HibernateDelaySec=5min. Hibernation most times works nice too (even with Full Disk Encryption (FDE)) there is just one gotcha, lockdown mode is currently fundamentally incompatible with hibernation (even through it's docs seem to imply something else, they refer to a not yet existing feature). And some distros enable lockdown mode by default if you use a proper FDE setup. Leading to a lot of confusion about hibernation suposedly not working anymore in linux or being incompatible with FDE.
- hutzlibu 3y ago
  Ok, I will give it a try again, thanks for the explanation.