[pkg-cryptsetup-devel] regarding Bug#573073: delay at creating lvm devices

[Jonas Meurer]

Hey LVM and Udev package maintainers,

the buglog of bug#573073 (filed against cryptsetup) indicates that the
lvm2 initscript at boot process finishes before the devices are actually
created by udev. this leads to a race condition in some situations,
where the cryptsetup init script tries to access an lvm device before
udev actually created it.

i guess this is a general problem concerning several initscripts which
push udev, but it might be able to workaround it by invoking 'udevadm
settle' in lvm2 initscript.

what do you suggest?

greetings,
 jonas

----- Forwarded message from Linas Žvirblis <0x0007 at gmail.com> -----

Date: Fri, 26 Mar 2010 14:58:23 +0100
From: Linas Žvirblis <0x0007 at gmail.com>
To: Jonas Meurer <jonas at freesources.org>
Cc: 573073 at bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#573073: cryptsetup: boot fails
	because fsck tries to access the device before it is unlocked

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




----- End forwarded message -----
-------------- 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/20100925/d769c8ad/attachment-0001.pgp>