In my opinion, s2idle with suspend-then-hibernate is the answer to this conundrum. It provides quick, trouble free suspend/resume and low battery degradation over the long term. Suspending to deep kills the battery if you leave the laptop for longer periods between uses as it constantly drains the battery.
suspend-then-hibernate is problematic for a number of reasons, and s2idle drain really needs to improve for this to be a complete product:
- It doesnāt work with secureboot (it might in the future, details here: mjg59 | Making hibernation work under Linux Lockdown)
- It doesnāt work with Zram, which is default on Fedora (and maybe other distros)
- Swap space has to be large, and cannot be encrypted (yet?)
- Combining this with a BIOS password (which is best practice for workstations) and LUKS encryption means having to type credentials in many times during wake
- 20 second (plus multiple password typing) boot times is unreasonable for many people
I see in some other threads that Windows users got s0ix drain down to ~150-500mW. Thatās a much better level than the current 2.2W (calculated from 4% drained per hour on the 55Wh battery)
I know that Framework is a small company with a small dev team, and doesnāt have many resources to allocate to fix these problems.
If this doesnāt get fixed soon Iām either going to request a refund (still within my 30 day return window) or donate it to a Linux dev who can make power management work with all the hardware in the device.
2 Likes
Yes, this is annoying, but the whole āsecure bootā thing is sort of irrelevant for most regular people. If youāre being targeted like that, you have other problems.
Why not just force a password to edit UEFI settings? That is, for booting, why require a password? Especially if you encrypt your disk (like you should be doing anyway)?
For most threat models, a UEFI password on every boot is idiotic. Right now, when I boot up, I enter one password (to decrypt my hard drive), since I use my fingerprint (+ Yubikey) to login or unlock my screen. Even if I setup a UEFI password, Iām not going to require it to boot since thatās generally not that helpful anyway. It does make sense to lock the F12 menu and UEFI settings menu behind a password, though, since that can be used to bypass e.g. full-disk encryption and boot from a USB drive.
You seem to have fairly regressive views towards device security, along with some rude language. The former is fine for yourself, but does nothing to help others. Youāve belittled my concerns over perfectly valid use cases and features.
Forcing a password to edit UEFI settings is recommended, as is a password for regular booting. For some background to my concerns, please see https://github.com/lfit/itpol/blob/master/linux-workstation-security.md
Fingerprint and MFA tokens do help speeding up credential input, but donāt eliminate the need for multiple interactive steps to the process.
I donāt really think I was being rude, but I understand that sometimes intentions donāt get conveyed appropriately over the Internet, so I apologize if I came across as rude, as that was not my intention at all.
Absolutely, what youāre describing has a valid use case. What I am questioning is which threat model you are operating under. And my assertion would be that for most regular laptop users, the requirements you are describing arenāt really necessary (though they might be nice to have).
Take secure boot, for example. The main sort of attack it might prevent is the so-called āevil maidā attack, where someone tampers with your unencrypted boot partition. Is this a threat that most regular people are reasonably likely to fear? Not particularly. Would it be nice to have while not breaking hibernation? Absolutely. But for 99% of regular people, the ability to hibernate far outweighs defeating the theoretical evil maid attack.
Compare this with something that actually has a practical effect: full-disk encryption (minus the boot partition in most cases). What does this prevent against? Well, if someone steals your laptop (which might happen for all sorts of reasons), they canāt access your files (which might include emails, passwords, etc), so it turns from being a life-changing disaster (having to change all passwords, possibly reporting all credit cards stolen, etc) to being a major annoyance (having to buy a new laptop and set it up again). This is what I mean when I mention a threat model, and it seems (to me) to be lacking from your analysis.
Here, youāre taking a workstation hardening guide (without a clear threat model) and applying it to a laptop (which inherently has a vastly different threat model to begin with, since it can much more easily be physically compromised or stolen). This seemsā¦not so ideal, to be honest. Again, Iām not saying that these arenāt good tips or that we shouldnāt work towards enabling this use case. But what Iām saying is that we should slow down and establish a threat model first before decrying Linux on the Framework for not supporting your particular use case (while implying that it should be the use case for many/most people, as you did in your initial post).
My swap is absolutely encrypted. The easiest way to do this is to setup a LUKS-encrypted partition and then setup LVM inside with volumes for root and swap. Normally, I use a separate disk for /home, but on the Framework, I setup three volumes instead: root, home, and swap. All are encrypted.
Look, Iām not saying that these arenāt valid complaints. All Iām questioning is your implication that all of these features are needed for all threat models and therefore Linux on the Framework is unsuitable for even minimal security. Maybe this is something Iām reading into what you said and you did not mean to imply that, though.
7 Likes
Just tested deep sleep on EndeavourOS, kernel 5.15.7, and went from a charge_now of 3539000 to 3512000 in 4h20m. That would be less than 1% loss in that time period, which I consider to be really good! The charge_now value might not have been updated, though, because it quickly dropped to 3489000, or 1.5% loss.
Time to sleep and time to wake were in the 20 to 25 second range each way, which I consider to be an acceptable trade for that little battery usage while sleepingā¦
I did pull my USB-A expansion cards for the test, though. Might try a longer duration with them kept in and see if it makes any difference. If so, I may order 2 more usb-c cards and just do away with the A cards entirelyā¦
I had pretty good results enabling deep sleep and hibernate running Ubuntu 21.10 on Framework Laptop DIY Edition. If the battery loss that I observed during 3 days of hibernation is linear, then this laptop can hibernate for weeks before depleting completely. Hereās a quick guide Solving the Framework Laptop Battery Drain Issue
3 Likes
I ran an comparison against a Lenovo t450s with an unmodified fresh install of SUSE Tumbleweed. With a 6 cell (57WH) I saw an 8% drop over a 6 hour period.
Framework laptop (55WH) with a similarly fresh install, but with mem_sleep=deep set and confirmed, Iām still seeing ~20% battery loss over the same 6 hour period. Reading above, it appears that everyone confirms this through a ~2%/hr drop.
Iām not sure why this is being applauded. This is a huge amount of energy loss without any good reason. Iāve never had to do this much configuration and validation on a Lenovo.
Please, if anyone can point out something Iām missing, Iām open to trying anything.
If anyone else prefers IRC, I can be found in Liberaās #framework-laptop channel.
EDIT: Iāve read through this forum and I know a few people here seem to completely ignore, and even belittle, full disk encryption. Many people, like myself, are required to comply with FDE for corporate environments, and this is non-negotiable. Please keep your opinions about security practices to yourself.
3 Likes
Yeah for sure I experienced the same, the older ultrabook Iāve used seem get similar drain of about 0.8 to 1.1% an hour, upon deep sleep, I asked on discord too, but people seem to suggest hibernation and other methods 
.
My guess is its because of rechargeable RTC battery and the USB-A / HDMI expansion cards, removal of which gave me both runtime and sleep time reduced consumption. At runtime each A card seem to consume 0.5W with no use.
And for the good news
There seem to be a new bios update which is expected to improve battery drain at shutdown probably itāll also affect the sleep mode too. Try that A cards out and wait for the bios update too.
I have made a thread for soft-access to hardware kill of ports
Has anyone noticed that each of the USB-A expansion card draws about 0.5W? - #2 by Animesh_Sahu as well as default off when sleep/shutdown
How to disable USB ports during sleep or shutdown? (Any OS) but none of them got any answers
1 Like
@Animesh_Sahu Thank you for the context and tips! I will do some more tests today with the expansion cards removed and look into the BIOS update.
@lbkNhubert Indeed, but I havenāt been able to get suspend-then-hibernate to work as expected. I works if I manually execute it with systemctl, but not when in deep sleep and triggered by HibernateDelaySec
@cornfeedhobo - I hope that youāre able to figure out whatās causing it not to work. After I finally got it working on Pop!_OS it has been fantastic.
In case it may be of some help, here are the relevant lines in my sleep.conf and logind.conf files:
etc/systemd/sleep.conf:
[Sleep]
#AllowSuspendThenHibernate=yes
HibernateDelaySec=120min
/etc/systemd/logind.conf:
[Login]
HandleLidSwitch=suspend-then-hibernate
HandleLidSwitchExternalPower=suspend-then-hibernate
IdleAction=suspend-then-hibernate
IdleActionSec=30min
5 Likes
@lbkNhubert Thanks for the paste. It turns out I had all of that set properly, the issue was with KDEās PowerDevil. In the power management settings, itās required to toggle āWhen asleep, hibernate after a period of inactivityā. After this was set properly, I tested different HibernateDelaySec and it was finally being respected properly.
I now have working deep sleep and suspend-then-hibernate!
Thanks everyone. I might start a new thread to document everything I did. Also looking forward to the bios updates mentioned.
2 Likes
@cornfeedhobo - thanks for the follow-up, itās great to hear that you got it working. Looking forward to reading the steps that you took.
@lbkNhubert I decided to make a gist instead, but Iāll be linking it to the relevant OpenSUSE thread.
2 Likes
Sleeping battery life on Linux is terrible compared to macbooks on all hardware Iāve tested. This would be a boom for frame.work and would be relatively easy to achieve. s3 is just terrible - see recent Lenovo + Linux debacle. We need a laptop that can sleep for a month, wake up quickly, and still have battery life left for usage (my 2012 Macbook Pro could do this, and there would be 60+% battery life left after a month sleeping).
Thanks frame.work - I know you can do it!
12 Likes
To give the full story:
I recently sold my old 2012 macbook pro (which I installed a new battery in). I reinstalled the OS, had a full charge, and left it unplugged and sleeping for over a month while it was unsold. When I opened it back up it had about 60% battery left! Wowā¦ I only use Linux now, but this really seems like it should be possible on modern laptop hardware + Linux. How many days will the framework last using hibernation?
In my experience, the laptop will almost entirely discharge within about 36 hours, even on Windows, which I switched to to improve battery life. Undeniably disappointing for a product that I had high hopes for. Without this issue, the laptop would be a 10/10. As it is, I have difficulty seriously recommending it over the competition.
1 Like
Recently left mine off and unplugged for 10 days. Battery life went from 80 to 70%.