My laptop isn’t under my supervision most of the time. And I’d hate it if someone were to steal my SSD, or whole laptop even, when I’m not around. Is there a way to encrypt everything, but still keep the device in sleep, and unclock it without much delay. It’s a very slow laptop. So decryption on login isn’t viable, takes too long. While booting up also takes forever, so it needs to be in a “safe” state when simply logged out. Maybe a way that’s decrypt-on-demand?
I’m on Arch with KDE.
Is your idea to do the easier decrypt on boot, and optimize the boot times?
I could probably do that, but someone else said that there is a decrypt on hibernate, seems better.
Yeah im thinking do “normal” decrypt on boot. It’ll be easier to troubleshoot and recover from if something goes wrong and there’s fewer pitfalls to deal with.
I also suspect that theres a problem with your computer because boot times have been pretty fast for many years now.
E: I just now saw that you’re using an eighth generation intel processor, plenty of ram and an ssd.
I have the same situation but a much older processor and my boot times from button press to desktop are ~10 seconds.
Unless your expectations for boot times are way out of line, you ought to have no problem using decrypt on boot.
One possibility is that your ssd has aged and is having to read those old system file blocks hundreds of times to get it right. Badblocks -n or spinrite level 2 or 3 scan fixes this problem.
I bought it used, so I’m interested in your last point. I’ve reinstalled it - first thing I did. Do SSDs slow down overtime? And there is a linux command to fix that? Sound crazy, can you elaborate?
Yeah badblocks -n /dev/your_target_device launched from a different boot device.
You can’t run it from your install because it’s gonna read every block into memory and then write some crap to it and read it back to make sure the block works then write what was originally there back to it.
It’s really important that you check yourself before you wreck yourself with the badblocks command because you can destroy data if you use the wrong flags.
Another program that fixes that problem is spinrite. It costs money but it’s very useful and has a lot of good documentation.
Each cell in the ssd isn’t a digital “1” or “0” but a charge coupled device that stores a voltage. Over time that potential changes in a way that’s directly proportional to the number of read cycles and age of the data from first write. When it changes enough, the controller has to try to read it many times to get a sane result it can send down the bus.
That results in your ssd seeming slow.
How long does it take to boot though, and what do you expect?
didn’t run a timer, it was still fast enough, but for turning it off and on every 5 minutes (or more realisticly hour)… I’d like the fastest possible. I’ll have fun with this badblocks, sounds OP af. However I don’t think it’s a good sign if this returns anything right? I could make it so the filesystem avoids that block, that is good and all, but doesn’t that means my SSD started “turning bad”. So either way I should get a new one? If one cell fails other will soon follow, and my data is lost, no?
Always have a backup.
Badblocks shouldn’t output anything when run on an ssd. It’s not really useful for its intended purpose there because ssds have hundreds to thousands of bad blocks to start with (depending on how you define “blocks”) and reprovision messed up sections all the time to cover up the fact that they’re screwing up constantly from the bus.
It’s also true of rotational hard drives nowadays, not that they’re fundamentally based on using a medium that’s incredibly prone to “failure” but that they don’t expose the actual addresses on the medium to the controller.
The old way, what the bad blocks tool is intended to address, is like if there were a big warehouse and when you wanted something you asked for the thing in rack 6F, shelf D8. The disk goes and gets it for you and if it’s the right thing then you’re golden and if it’s wrong you got a problem.
Badblocks -n grabs the thing on 6F,D8, sets it aside and asks the disk to put something else in there, then asks for it back. If it succeeds then wonderful! “Block” 6FD8 is good and it puts the thing that was originally there back and moves on to the next one ad infinitum.
Of course, new rotational disks and all available ssds don’t actually work like that. You hand the disk an object and say “put this in 6FD8” and the device says “you got it” and then promptly opens the package you handed over and puts its contents wherever it wants.
When you ask for 6FD8 back the device grabs all the stuff that’s supposed to be there, puts it all back together and hands it to you. The disk itself might have all kinds of messed up things going on internally and you only see it when the data you put in doesn’t come out the same.
Part of what makes the secure erase functionality work on ssds is that very insane obfuscation. When there’s no actual physical structure to the way data is stored, no “raw” read of the ccd chips can make heads or tails of it. The disk can be easily and quickly “wiped” just by asking the disk itself to kindly forget its own key used to locate information requested and viola! Secure erase!
Of course, none of that matters because we’re not using badblocks to figure out if there are bad blocks, we’re using it to force the ssd to rewrite its ccds so they respond to requests faster.
The behavior we care about is writing something to the “block” then erasing it and rewriting the original data into it. Badblocks -n should do that.
There are times when it might not though, the ssd may hand you porno.mov out of “6FD8”, write random data to somewhere in the ccd chip that it writes down is supposed to be 6FD8, read it back to badblocks, then when badblocks says “alright, that one passed, lets put porno.mov back there” the ssd says “wait a second, I have a string of bits that matches this!” And just update its internal ledger that 6FD8 is now what it was before that silly random data kerfuffle, never actually rewriting anything.
It saved a write cycle on those cells after all! It did you a favor!
So sometimes badblocks -n doesn’t work in this application. Spinrite is the “correct” tool, but for some applications it doesn’t work either (non x86 systems) so I use dd in that case to just slam the disk full of something so it can’t reprovision and save any write cycles and writes every possible cell with something. That destroys data, of course.
What I’m getting from this is badblocks isn’t a magical tool that makes all storage devices faster and better anymore. correct? The fact that modern storage devices do that is a bit scary. I’m guessing it’s firmware, no way to turn it off. And why would you, it helps you, just takes control away from you.
I wasn’t really trying to wipe my storage device, but to make it faster. However you said a bunch of interesting stuff, and I thank you for that.
eh, if you don’t have spinrite or something like it and don’t wanna wipe your device with dd then it works well for the purpose of renewing ssds.
with the -n flag it will probably help and shouldn’t cause any damage, assuming the problem is that you have an old clapped out ssd.
remember, you’ll have to run it from a usb boot or something.
In that case: maybe I’ll try it on the weekends, I heard it takes a while to run. Thanks for the toy :p