Hi Jonas, this time with MILAN and bugs.debian.org in CC.
Sorry for my long reply time. On Sun, 18 Jul 2010 22:51:07 +0200 Jonas Meurer <jo...@freesources.org> wrote: > On 08/07/2010 Jonas Meurer wrote: > > > Last line before prompting for passphrase is like: > > > cryptsetup -c -aes-... --key-file=- create cryptofs /dev/sda3 > > > After waiting 50 secs, first line is: > > > '[' -z /lib/cryptsetup/checks/vol_id ']' > > > > this verifies, that the delay is caused by cryptsetup binary, not by > > anything else from the initscript. The weired thing is: When I type in the passphrase, I have to wait 60 secs before the bootup process continues. But if I just wait 60 seconds and type in the passphrase afterwards, the bootup process continues immediately. > > you could check the unlocking > > by booting into single user runlevel (init=1), and manually invoking > > > > # cryptsetup -c aes-cbc-essiv:sha256 create cryptofs /dev/sda3 > > > > simply let the unlocking process fail three times (wrong > > passphrase), and the boot process will stop at runlevel 1 with an > > emergency shell. there you can test the manual unlocking of > > encrypted device. If I try to let the unlocking process fail the first time, I have to wait 60 seconds anyway. After those 60 seconds, the following unlocking tries will work instantly. So in addition, I bought another harddisk from a different manufacturer. I copied the partition table, created a new encrypted partition and copied the whole system using the rsync command. So now I have the same files on both disks. If I use the new disk, there is no delay. Therefore this is not a configuration issue, since all configuration files are the same. Next step could be to wipe the 60-second disk and provide it with a new encrypted partition. But if I do this, the bad thing is we don't get to find out what ever caused the delay. Best regards, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org