Hey Luc, Am 12.10.2014 um 12:57 schrieb Luc Maisonobe: > Here are some news about the analysis of this boot problem.
First, great that you finally managed to use the debugging version that I sent earlier. > 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. Looks good so far. > 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? Is this output from the boot process or did you try to unlock the encrypted LVM volumes after boot process finished? > 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: This information changes everything! I never tried systemd myself so far and I don't know nothing about how the systemd boot process handles dm-crypt devices/cryptdisks/crypttab at all. > 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. This looks suspicious to me. Maybe systemd has its own crypttab implementation which doesn't support all the crypttab options/functions from Debian sysvinit init and initramfs scripts? At least some 'systemd-cryptsetup' process seems to process crypttab entries and detects an unsupported option 'keyscript'. > oct. 12 12:08:05 marislae systemd-cryptsetup[574]: Volume sda5_crypt > already active. At the same time, the encrypted device is detected as 'already active'. Doesn't make sense to me. But nevertheless, I can imagine that systemd-cryptsetup detects unknown crypttab options and falls back to the default password prompt afterwards. That would explain why you're asked for the password of every encrypted device. > 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. Ok, another option would be that the initscript is executed first, and afterwards the systemd-cryptsetup helper binary iterates over crypttab entries again and detects that the devices are already unlocked. > 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. Yeah, I remember I've read somewhere that systemd doesn't support separate /usr partitions. But again, I don't know nothing about systemd yet. Never tried it so far. So I don't even know at which state systemd executes the cryptdisks initscript, and how it interacts with the kernel keyrings. I'm eager to say that your problems are related to systemd init system. Honestly, I don't know when I will find time to give systemd a try and further debug this issue :-/ Cheers, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org