The problem was caused by a number of ordering issues and race conditions relating to when lvm and mdadm were called, and how those interacted to ensure the devices were created and their contents examined.
This should work as follows:
* an underlying block device, sda1, is detected
* udev (through vol_id) detects that this is a RAID member
* udev invokes mdadm, which fails to assemble because the RAID-1 is not complete
* the creation of a new raid, md0, is detected
* udev fails to detect this device, because it is not yet complete
meanwhile:
* a second underlying block device, sdb1, is detected
* udev (through vol_id) detects that this is a RAID member
* udev invokes mdadm, which can now complete since the set is ready
* the change of the raid array, md0, is detected
* udev (through vol_id) detects that this is an LVM physical volume
* lvm is called to handle the creation of the devmapper devices
then
* various devmapper devices are detected
* the devices are created by udev, named correctly under /dev/mapper
* meanwhile the requesting application spins until the device exists, at which point it carries on
* udev (through vol_id) detects that these devices contain typical filesystems
* using vol_id it obtains the LABEL and UUID, which is used to populate /dev/disk
Note that this event-based sequence is substantially different from Debian, so any bugs filed there will not be relevant to helping solve problems in Ubuntu.
This should now work correctly. If it does not, I would ask that you do not re-open this bug, and instead file a new bug on lvm2 for your exact problem, even if someone else has already filed one, with verbose details about your setup and how you cause the error.
We believe that this problem has been corrected by a series of uploads today. Please update to ensure you have the following package versions:
dmsetup, libdevmapper1.02 - 1.02.08-1ubuntu6
lvm-common - 1.5.20ubuntu12
lvm2 - 2.02.06-2ubuntu9
mdadm - 2.5.6-7ubuntu5 (not applicable unless you're also using mdadm)
udev, volumeid, libvolume-id0 - 108-0ubuntu1
The problem was caused by a number of ordering issues and race conditions relating to when lvm and mdadm were called, and how those interacted to ensure the devices were created and their contents examined.
This should work as follows:
* an underlying block device, sda1, is detected
* udev (through vol_id) detects that this is a RAID member
* udev invokes mdadm, which fails to assemble because the RAID-1 is not complete
* the creation of a new raid, md0, is detected
* udev fails to detect this device, because it is not yet complete
meanwhile:
* a second underlying block device, sdb1, is detected
* udev (through vol_id) detects that this is a RAID member
* udev invokes mdadm, which can now complete since the set is ready
* the change of the raid array, md0, is detected
* udev (through vol_id) detects that this is an LVM physical volume
* lvm is called to handle the creation of the devmapper devices
then
* various devmapper devices are detected
* the devices are created by udev, named correctly under /dev/mapper
* meanwhile the requesting application spins until the device exists, at which point it carries on
* udev (through vol_id) detects that these devices contain typical filesystems
* using vol_id it obtains the LABEL and UUID, which is used to populate /dev/disk
Note that this event-based sequence is substantially different from Debian, so any bugs filed there will not be relevant to helping solve problems in Ubuntu.
This should now work correctly. If it does not, I would ask that you do not re-open this bug, and instead file a new bug on lvm2 for your exact problem, even if someone else has already filed one, with verbose details about your setup and how you cause the error.