Bug 596227
Summary: | Anaconda swaps names of md devices | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Alexander Todorov <atodorov> |
Component: | anaconda | Assignee: | Hans de Goede <hdegoede> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Release Test Team <release-test-team-automation> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 6.0 | CC: | alex.williamson, anaconda-maint-list, dledford, hdegoede, jonathan, mbanas, myllynen, vanmeeuwen+fedora |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | anaconda-13.21.48-1 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | 596224 | Environment: | |
Last Closed: | 2010-07-02 20:50:21 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Alexander Todorov
2010-05-26 12:24:14 UTC
Cloning for RHEL6 (some update) or RHEL7. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. (In reply to comment #0) > As for "md0 and md1 seem to be the wrong order" that's because they *are* in > the wrong order. The arrays are added to the device list when we first find a > device with a superblock. Which device we find first (/dev/vda2 or /dev/vda3) > is random because we find them in the order that udev processes them and udev > can process the partitions on a drive in any order. According to the > storage.log, /dev/vda3 was found first, and according to the blkid information > it has a raid superblock that clearly indicates that it *wants* the name > /dev/md1, but because it was found first, anaconda blindly renamed it to > /dev/md0. And when /dev/vda2 was processed, the logs show it has a superblock > that clearly indicated it wanted the name /dev/md0, but because it was already > taken, it was blindly renamed to /dev/md1. > > I consider this a *SERIOUS* shortcoming in how anaconda processes md raid > devices, but I was told that changing anaconda so that it didn't renumber > arrays in the order that it finds them was too drastic of a change for > f13/rhel6 and it would have to wait for f14 (or later) and rhel7. I'm afraid this is a misunderstanding. What we wanted to delay till Fedora-14 / a later RHEL is allowing specifying a name for an mdraid array, like we allow for volgroups or logical volumes. We do however try to take the current superblock device name into account when it matches the md# scheme and if we fail to do that, we've a bug. Here is the code in question: # try to name the array based on the preferred minor md_info = devicelibs.mdraid.mdexamine(device.path) md_path = md_info.get("device", "") md_name = devicePathToName(md_info.get("device", "")) if md_name: try: minor = int(md_name[2:]) # strip off leading "md" except (IndexError, ValueError): minor = None md_name = None else: array = self.getDeviceByName(md_name) if array and array.uuid != md_uuid: md_name = None Where the essence is the call to devicelibs.mdraid.mdexamine(device.path), which does: mdadm --examine --brief /dev/vda# Of which we then parse the output, we seem to have a bug somewhere in this code, and I fully agree this is something which we should fix for RHEL-6. And here we have our problem, from program.log from bug 591970: ARRAY /dev/md/1 metadata=1.1 UUID= Notice the /dev/md/1 rather then /dev/md1, that is not what anaconda expects. One patch coming up. A patch which should fix this has been send to the mailinglist for review, adding a devel-ack. This is fixed in anaconda-13.21.48-1, moving to modified. Thanks Hans, the idea of devices silently swapping around was a scary one ;-) Tested with anaconda-13.21.50-9.el6 (0622.1 tree) and steps to reproduce from comment #0. Now anaconda correctly shows that vda2 belongs to md0 and vda3 belongs to md1. Moving to VERIFIED. Red Hat Enterprise Linux Beta 2 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |