Hey Markus, On 24/07/2010 Markus Melms wrote: > Sorry for my long reply time.
sorry for my even longer 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. to me this sounds like something related to udev, or a kernel event. are you still able to reproduce the bug with a recent and up-to-date system? i don't know whether debugging the issue is worth the effort, maybe it's a hardware issue after all (or combination of for example hardware and udev). > > > 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. did you give that a try? what if you dd the complete 60-seconds partition to the new drive? maybe that way you're able to reproduce? greetings, jonas
signature.asc
Description: Digital signature
