[pkg-cryptsetup-devel] Bug#544773: Bug#544773: Update to cryptsetup 2:1.0.7-2 breaks booting

[Paul Millar]

Hi Jonas,

On Sunday 06 September 2009 02:39:46 Jonas Meurer wrote:
> On 05/09/2009 Paul Millar wrote:
> > vedrfolnir:~# ls -l /dev/mapper 
> > [...]
> > lrwxrwxrwx 1 root root      7 2009-09-04 19:06 vedrfolnir-home -> ../dm-6
> > [...]
> > vedrfolnir:~# cat /etc/mtab [...]
> > /dev/dm-6 /home ext3 rw 0 0
> > [...]
> > > i guess that you discovered the same bug as #544487.
> > Yes [...]
> 
> so indeed the problem here is that files in /dev/mapper are symlinks
> rather than devices. [...]

Good news!  The problem seems to be fixed from the update of lvm2 today.  The 
upgrade of lvm2 from 2.02.51-2 to 2.02.51-3 resulted in the files in 
/dev/mapper becoming the devices and /dev/dm-* becoming the symbolic links.

I'm somewhat confused as the lvm2 changelog[1] records a single change 
*introduced* with 2.02.51-2 to...

	Make mapper/* the real device, dm-* a symlink. (closes: #542422)

[1] 
http://packages.debian.org/changelogs/pool/main/l/lvm2/lvm2_2.02.51-3/changelog

So, if I have read the changelog correctly,  lvm2 v2.02.51-2 should have had 
/dev/mapper/* as real devices and /dev/dm-* as symbolic links.  This isn't my 
experience: with lvm2 v2.02.51-2 /dev/dm-* were real devices and /dev/mapper/* 
were sym.links.  This resulted in the problem with cryptsetup.

Perhaps 2.02.51-2 was meant to implement this switched behaviour 
(/dev/mapper/* real dev files, /dev/dm-* as sym-links) but, due to a bug, this 
didn't happen.  However, if so then the bug wasn't recorded in the changelog 
against 2.02.51-3 (or at least, it wasn't clear).

So, I'm happy the problem is fixed but unclear why this has happened with lvm2 
2.02.51-3.  Also, it's unclear to me that this won't happen again in the 
future: do the lvm2 people know that they broke cryptsetup?  The lvm2 change-
log entry is against a bug [2] that doesn't mention cryptsetup.

[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542422

> nevertheless, we'll need to add support for /dev/dm-* devices in
> cryptroot initramfs script/hook. a quick check revealed that dmsetup
> doesn't support /dev/dm-* devices as arguments. thus cryptroot needs to
> find out the name in /dev/mapper/, regardless whether it's a symlink or
> the actual device file.

It's up to you how best to handle this problem: I don't know how this all fits 
together; however, from causal reading, this sounds like you're working around 
a deficiency in dmsetup.  Would it be better to fix dmsetup here?


> so i guess that canonical_devie() needs to check whether the device is
> something like /dev/dm-* and transform that into the corresponding
> /dev/mapper/* device/symlink before returning.

Could be .. although that sounds like a fragile solution (depending on device 
and sym-link locations in the VFS, which could change)


> i'll be on holidays until september 18. so i'll not be able to look into
> that before.

Don't worry!  The problem seems to have gone away from the time being.

Cheers,

Paul.