[pkg-cryptsetup-devel] Bug#576186: Bug#576186: cryptsetup: Setting up crypto device on Startup takes too long w/ ext3

[Jonas Meurer]

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 <jonas at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20101112/f9733e38/attachment.pgp>