For what it’s worth, I’m on Fedora F35 (5.14.17-301.fc35.x86_64) and I’ve done some experimentation, with s2idle and deep sleep. I’m seeing ~4% drain per hour on s2idle and 2% drain per hour on deep sleep. I’ve done some short experiments with turning off WiFi / Bluetooth, and unplugging USB peripherals, but don’t it doesn’t seem to make much difference in the rate of discharge. Overall, I think deep sleep is at an acceptable level, however I do find it annoying that it takes so long to wake from deep sleep (usually it’s a good 15 - 20 seconds). I may eventually come up with a script that starts sleep in s2, and goes to deep after 1 hour or so, such that if I close the lid for a short period of time (let’s say walking around the house) I can resume quickly, but overnight or in transit, I can benefit from good power savings. If anyone has done this already, please post.
FYI my specs are:
i7-1165G7
32 GB RAM - single slot
AX210 (with vPro) - IDK why I got vPro, since my CPU doesn’t support vPro, and apparently vPro Wifi can contribute to power drain…
SN850 1TB SSD
HDMI, Display Port, USB-A, USB-C ports
Hibernate is not available, I believe due to secure boot being enabled upon installing Fedora. From what I understand, I’d have to re-install with secure boot turned off to enable hibernate.
No, you can just toggle secure boot in the UEFI settings. You’d have to reinstall if you wanted to switch from BIOS to UEFI or vice versa (source: I did the same thing where I installed Debian with secure boot enabled but later disabled it so that I could hibernate).
It seems like it’s an Intel-specific, faster better version of hibernation, but other than that little section in the Arch Wiki, I really can’t find much info on it. Apparently it requires a special partition, and:
there’s no obvious indication to the OS that the feature is supported unless the appropriate partition already exists
Which seems like the perfect formula for spending a whole afternoon messing with partitioning and whatnot without any indication of whether or not what you’re doing will result in anything useful. But, if it’s actually supported it seems very worthwhile.
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.
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.
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.
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.
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
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.
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.
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.
@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
@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.
.