Anyone ever have cryptsetup just start hanging after entering password on boot? This seems like it’s going to be a fun issue to try to resolve…
Boot with previous kernel ? If fail, boot from Linux live, connect, mount, make backups, and try to fix.
It could also be a disk problem. I second the backup suggestion
This is my main concern.
How could you boot a different kernel if you can’t unlock the drive?
Isn’t it quite common to have /boot on an unencrypted partition?
Oddly, after a few tries I managed to get past. I religiously back things up, and just last night pushed all my current dots.
I’m gonna run some drive diagnostics. If everything looks good, I’ll just repartition and take this as a sign to only use encryption on secondary drives where I backup sensitive info.
I really need to get into pushing dot files. Every time I think „its not going to be that much“. Then I install a new system and like 20 apps, then I fiddle here and there. After a couple weeks I def rack up one or more hours of config.
My protip is to use symlinks, and then just keep all your dots in a project folder. Makes it super easy to keep iterating on them in realtime, and pushing changes.
Thats neat! Thanks for the suggestion. I‘ll try that. Currently am experimenting on libraries with my coding stuff.
How long do you wait before you declare it hung?
Sometimes decryption takes up to a minute depending on your system specs and optimizations.
I suggest booting from a live disc and trying to unlock it from there.
10m is when I throw my hands up. Normally it takes under 20s.
Paste the output of
cryptsetup benchmark
# Tests are approximate using memory only (no storage IO). PBKDF2-sha1 2957901 iterations per second for 256-bit key PBKDF2-sha256 4946113 iterations per second for 256-bit key PBKDF2-sha512 1945410 iterations per second for 256-bit key PBKDF2-ripemd160 1123875 iterations per second for 256-bit key PBKDF2-whirlpool 773286 iterations per second for 256-bit key argon2i 8 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time) argon2id 8 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time) # Algorithm | Key | Encryption | Decryption aes-cbc 128b 1794.0 MiB/s 6427.8 MiB/s serpent-cbc 128b 107.4 MiB/s 765.7 MiB/s twofish-cbc 128b 275.7 MiB/s 498.2 MiB/s aes-cbc 256b 1392.5 MiB/s 5266.3 MiB/s serpent-cbc 256b 114.8 MiB/s 798.4 MiB/s twofish-cbc 256b 284.6 MiB/s 498.7 MiB/s aes-xts 256b 5290.1 MiB/s 5322.6 MiB/s serpent-xts 256b 697.6 MiB/s 635.9 MiB/s twofish-xts 256b 403.4 MiB/s 413.4 MiB/s aes-xts 512b 4070.4 MiB/s 4048.9 MiB/s serpent-xts 512b 664.6 MiB/s 642.0 MiB/s twofish-xts 512b 417.6 MiB/s 421.7 MiB/s
how about
systemd-analyze
andcryptsetup luksDump <lukspart> | grep Slot
That’s more than a reasonable period of time to wait.
Can you run a SMART check on the drive from a liveCD? memtest86?
An extended test using
nvme-cli
showed zero errors. I’ll try memtest later today.
Today it happened for the first time for me. I use arch btw.