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.
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!
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.
It’s highly unlikely that any hardware would last so long if just left sleeping. I mean, DRAM consumes non-trivial amount of power which would probably drain any battery unless some form of hybernation is used.
@Edward_Gray - Are you sure? I don’t see anyone else being able to reproduce that. You mean you left it unplugged & off - not sleeping?
@Korvin - Ya well that is Apple’s secret sauce, but it can’t be that hard if they had it solid by 2012. Maybe they have some hybrid using suspend to ram and suspend to disk.
Actually it is very hard. One of the hardest parts of hardware design, in fact. Apple can afford to poach and pay engineers due to their massive profits and revenue. So yes, this is VERY hard work, and Apple has a strategic advantage due to their ability to attract talent.
People in general don’t understand that the hardware is in fact the easy part. Software is by and far the hardest part of a product.
.