[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#403687 lvm2: several issues with devmapper devices



Steve asked today:
<vorlon> fjp: I'm confused why bug #403687 is marked as RC, instead of bug 
#402511

I've decided to answer by mail instead of on IRC because this issue 
probably needs some coordination between maintainers of several packages.

It looks certain that #402511, and probably also #401393 were introduced 
by this change in udev (0.103-1):
* udev.rules, devfs.rules: stop suppressing creation of dm-* devices,
  because they are needed by HAL. (Closes: #392623)

The second line in this snippet from /etc/udev/udev.rules was dropped:
# device mapper creates its own device nodes, so ignore these
KERNEL=="dm-[0-9]*",            NAME=""
KERNEL=="device-mapper",        NAME="mapper/control"

The reason I filed #402511 as important is because, although it is a clear 
regression and IMHO rather ugly, it is still mostly a cosmetic issue.
It looks like vgchange just loops over all /dev/dm-* devices and checks if 
any of them are LVM volumes, and prints an error if a device does not 
exist.

My conclusion is that udev now creates /dev/dm-* device nodes for cryto 
devices (and possibly other dm devices too), but nothing yet takes 
responsibility for _deleting_ them when the corresponding crypto devices 
are brought down [1]. This looks like a structural issue, but I have no 
idea if that should be the responsibility of the device mapper, udev or 
cryptsetup.
I also wonder what the risk is of other, not yet reported, issues 
introduced by the change in udev.

The reason I filed #403687 as RC is because IMO it is the _combination_ of 
several issues introduced by the change in udev that needs to be looked 
at before the release. I have no idea how important the HAL-support is, 
but the regressions it introduced seem serious enough to consider 
revering it.
IMO the management of /dev/dm-* devices is something that needs to be 
looked into structurally by maintainers of _all_ involved packages 
(probably also dmraid), I'll leave it to others whether that needs to be 
done before or after the release.

Cheers,
FJP

[1] The crypto devices in /dev/mapper/ *are* correctly removed after
S48cryptdisks has run, but the corresponding /dev/dm-* devices are not.

Attachment: pgpLmGatRhSdv.pgp
Description: PGP signature


Reply to: