[pkg-cryptsetup-devel] Bug#573073: Bug#573073: cryptsetup: boot fails because fsck tries to access the device before it is unlocked

[Linas Žvirblis]

tir, 16 03 2010 kl. 14:13 +0100, skrev Jonas Meurer:

> On 08/03/2010 Linas Žvirblis wrote:
>
> > I am using cryptsetup with lvm2 and encrypted logical volumes. The setup
> > was created during install with Debian Installer. The problem is that
> > sometimes it boot fine, but sometimes it dies like shown in boot
> > sequence transcript below. The passphrase is not being asked then.
> > 
> > When it dies I just rerun the script manually, and continue with boot
> > sequence. To me it seems like some sort of race condition, but I was
> > unable to locate the problem.
> 
> i'm not sure whether this is a race condition. according to your boot
> process transcript, /etc/init.d/cryptdisks is invoked, and
> vg01-swap_crypt is unlocked, but vg01-home_crypt isn't. so you'll have
> to find out why vg01-home_crypt isn't unlocked at cryptdisks initscript.
> 
> > A while ago the chances of booting properly were close to 50%, but
> > something in recent upgrades greatly reduced the odds, as I have not
> > managed to get a proper boot in like 10 reboots.
> 
> that indeed sounds odd. maybe you could add some debugging code to
> the do_start() and handle_crypttab_line_start() functions from
> /lib/cryptsetup/cryptdisks.functions to see what causes vg01-home_crypt
> to be ignored. the fact that _nothing_ is printed to the commandline
> irritates me. you would get a warning if only the source device was
> missing.

I found out what is going on.

During boot sequence /etc/init.d/lvm2 is started
before /etc/init.d/cryptdisks. It creates entries in /dev/vg01/ and
links them to entries in /dev/mapper/. However there is a very tiny
delay before udev finishes creating entries in /dev/disk/by-uuid/ in the
background. Therefore when /etc/crypttab is parsed, a device with a
specified UUID does not yet exist, and is skipped.

Not sure why I am not seeing a warning about missing device. Might be
related to conditional check on line 526 in cryptdisks.functions?

Introducing any tiny amount of waiting before execution of
handle_crypttab_line_start() solves the problem. In fact, it was even
enough to turn on verbose output of lvm2 to give udev a fraction of
second to finish.

My current work around is to use a device name instead of UUID
in /etc/crypttab.

Unfortunately I do not know how to solve this in a proper way. This does
not seem to be cryptsetup bug, but much more general one, as it also may
happen in other scripts relying on udev creating device nodes.

Linas