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 <0x0...@gmail.com> -----
Date: Fri, 26 Mar 2010 14:58:23 +0100
From: Linas Žvirblis <0x0...@gmail.com>
To: Jonas Meurer <jo...@freesources.org>
Cc: 573...@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 -----
signature.asc
Description: Digital signature
