Here are some news about the analysis of this boot problem. First, starting and stopping test partitions with cryptdisks_start and cryptdisks_stop does work properly after the computer has boot, but does not work at boot time. Here is the example of the command (with decrypt_keyctl modified to display the keys at the end, as suggested in an earlier post).
root@marislae:/lib/systemd/system# cryptdisks_start sda3_crypt [....] Starting crypto disk...[info] sda3_crypt (starting)... Caching passphrase for /dev/disk/by-uuid/4f04656d-00fc-4fea-8c8a-44a7bdc7b6e5: ****** BEGIN DECRYPT_KEYCTL DEBUG OUTPUT id: cryptkey-pw1 | key id: 657815207 key content: testpw key list: 1 key in keyring: 657815207: --alswrv 0 0 user: cryptkey-pw1 END DECRYPT_KEYCTL DEBUG OUTPUT [ ok crypt (started)...done. root@marislae:/lib/systemd/system# cryptdisks_start sda5_crypt [ ok ] Starting crypto disk...sda5_crypt (running)...done. root@marislae:/lib/systemd/system# As you can see, running it on an already started system is fine. On the other hand, the same setting does not work at boot time. Back to the original problem, without the test partitions and using only my regular two work partitions sda5 and sdb1 holding LVM volumes. The modification of the decrypt_keyctl to display the key on boot showed that after the key for the first partition was entered, it was stored in the user keyring. I got something like: id: cryptkey-sda5b1 | key id: 1007139041 key list: 1 key in keyring: 1007139041: --alswrv 0 0 user: cryptkey-sda5b1 Then the system asked for the second key, ignoring the one it already known, and the following is displayed: id: cryptkey-sda5b1 | key id: 422064942 key list: 1 key in keyring: 422064942: --alswrv 0 0 user: cryptkey-sda5b1 So the id was exactly the same, but the key id was a new one. It seems the keyring is cleared sometime between the two runs of the script and in each case only one key was stored in the keyring. I think the culprit is there: why did key 1007139041 disappear from keyring between the two commands? Another important information is that this system uses systemd, and it seems decrypting is handled differently with systemd. If I run journalctl to get information, I see this message: oct. 12 12:08:05 marislae systemd-cryptsetup[574]: Password file path 'sda5b1' is not absolute. Ignoring. oct. 12 12:08:05 marislae systemd-cryptsetup[574]: Encountered unknown /etc/crypttab option 'keyscript=decrypt_keyctl', ignoring. oct. 12 12:08:05 marislae systemd-cryptsetup[574]: Volume sda5_crypt already active. oct. 12 12:08:05 marislae systemd-cryptsetup[575]: Password file path 'sda5b1' is not absolute. Ignoring. oct. 12 12:08:05 marislae systemd-cryptsetup[575]: Encountered unknown /etc/crypttab option 'keyscript=decrypt_keyctl', ignoring. oct. 12 12:08:05 marislae systemd-cryptsetup[575]: Volume sdb1_crypt already active. However, this message seems to be generated after the partitions have already been activated, and from the message displayed on the console, I know decrypt_keyctl did run, despite these messages. Yet another information is I noticed earlier in journalctl the message oct. 12 12:08:05 marislae systemd[1]: /usr appears to be on its own filesytem and is not already mounted. This is not a supported setup. This problem is explained here: <http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/>. I don't know if it is related to my problem, I will try to fix this by moving /usr content into the / partition and see if it helps. best regards, Luc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org