Bug 638768 - LVM fails to bring up all dm-crypt targets, making md fail, if it uses dm targets
LVM fails to bring up all dm-crypt targets, making md fail, if it uses dm tar...
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-09-29 17:07 EDT by Tristan Santore
Modified: 2010-09-29 19:30 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-09-29 19:30:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tristan Santore 2010-09-29 17:07:22 EDT
Description of problem:
LVM fails to bring up all dm targets for md raid to use to assemble the array.
Resulting in a chicken and egg problem, as md thinks devices actually failed.

Version-Release number of selected component (if applicable):
Latest lvm2 updates August, will change component later, as recovering from live-cd.

How reproducible:
Reboot, different dm-targets seem to be enabled, or md cant start, because not all targets are present to assemble a raid5 array.
It must be stressed, this only affects systems, that have been set up with the following device setup:

sdx > dm(dm-crypt) > md > lvm

After speaking to Kevin Frenzi, it has become apparent, that the new standard anaconda method of set up appears to use the following setup:

sdx> md > dm(dm-crypt)

Steps undertaken trying to remedy:

The system was rebuilt (recovered to be precise ) 5-6 times, using different methods.
a. just unlock device and recover
b. erase md superblocks and rebuild(recover)
c. /dev/zero whole device, repartition, re-add md device, recover
d. boot into live cd, recover, reboot into main system

Each time in scenarios a-c the reboot resulted in the initial problem, i.e. random device, only two devices showing. After re-adding a device, recovery starts, finishes, reboot, same problem.

Scenario d. after reboot into live-cd, all is well, after first reboot into main system, all is well, on subsequent reboot, only two devices show up.

I am currently back in the live-cd recovering, I will try downgrading lvm next, after that is finished and see if the problem persists.

Another fact I noticed is, that on boot on the main system, The keyslot 0 unlocked lines do not show up. On the live-cd the boot output shows device lines being unlocked using keyslot 0. 3 lines for each device.

Further, I had added a normal device with md on it, that device always works and shows up in the array.

Also, no dracut updates were pushed to F13, which rules it out as a cause of the problem. No mdadm update was pushed either. I checked the mirrorservice.org mirrors. GB.

Expected results:

MD should start with all dm targets.
Comment 1 Milan Broz 2010-09-29 19:30:52 EDT
I read your report three times and still have no idea what exactly is the problem...

All three layers are independent (MD, DM, LUKS), all uses its activation mechanism (mdadm, lvm2, cryptsetup).

If you cannot assemble MD (because of some glitch in udev, mdadm now assembles arrays through udev rule) please report it for mdadm. It has noting to do with lvm.

"keyslot unlocked" message was moved to verbose level in new cryptsetup version and will not show anymore during activation, this is not bug.

I am not sure if initscripts/dracut properly handle sdx->dm-crypt->md - but this setup does not make much sense to me (usually you want sdx->md->crypt/lvm).

Anyway, if it worked in some release, report it to inistricpts/dracut and add exact configuration description, it is neither lvm nor cryptsetup problem.

Closing for now, please feel free to reopen when you have more info. I guess you want report this for mdadm component if the problem is with MD device?

Note You need to log in before you can comment on or make changes to this bug.