-
Notifications
You must be signed in to change notification settings - Fork 7
Description
Fresh install of SpiralLinux Cinnamon 12.231008 release.
I have selected swap (with hibernate) and btrfs. Also, the drive is encrypted.
Processor: Intel Core i7-3520M
There are two problems:
1: decryption takes a very long time:
After I have entered the password after startup, it takes over 30 seconds until the message Slot 0 opened appears.
2: when decrypting the swap partition, a strange message comes:
After the grub-menu it comes to these outputs:
cryptsetup: luks-UUID-of-sda1: set up successfully
Gave up waiting for suspend/resume device
It also takes almost 30 seconds for the second line to appear.
Despite this error(?), hibernate works without problems. And lsblk correctly indicates that the drive has been mounted.
After switching to the Testing branch, these outputs occur:
cryptsetup: luks-UUID-of-sda1: set up successfully
cryptsetup: luks-UUID-of-sda2: set up successfully
The delay in decryption at the beginning remains, although it became less (15 seconds).
Troubleshooting steps (with the support of a major search engine):
When I run sudo cryptsetup luksDump /dev/sda1 I get the info that there are two key slots allocated on sda1. The same is true for sda2.
According to this post, this is normal: Disk encryption: Why are 2 key slots in use?
With sudo cryptsetup --verbose open --test-passphrase /dev/sda1 I found out that the password is stored in Slot 0 for sda1 (and sda2 respectively).
Also a luksDump information: The iterations for all four slots seem very high to me (over 1,000,000 each). Unfortunately, I can only change the iterations for the password-slots I have not found out how to change them for the keyfile-slots.
So I tried sudo cryptsetup luksChangeKey --iter-time 500 /dev/sda1 and did the same with sda2.
Default is 1000 (1 sec) and lowering it is not the best idea. I will try to compensate it with a strong password.
Result: Iterations for the password-slots are now at just over 300,000 and unlocking takes less than five seconds.
See also:
- 3.4 Unlocking a LUKS device takes very long. Why?
- 5.10 What is "iteration count" and why is decreasing it a bad idea?
Question:
Is there a possibility to lower the value for the luks-iterations in the Calamares installer in the live environment and include this in the documentation? At least for weaker hardware this seems to be reasonable.
Unsolved:
I couldn't figure out how the Gave up waiting for suspend/resume device message came up or why switching to the Testing branch solved this and lowered the decryption time from 30 to 15 seconds.