Bug 446998 - md type raid arrays are no longer assembled by rc.sysinit
md type raid arrays are no longer assembled by rc.sysinit
Status: CLOSED DUPLICATE of bug 447818
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Doug Ledford
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-16 17:57 EDT by George Joseph
Modified: 2008-05-21 18:15 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 18:15:30 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 George Joseph 2008-05-16 17:57:07 EDT
Description of problem:

mdadm is no longer called from rc.sysinit so md raid arrays are no longer
assembled at startup from the mdadm.conf file.

Instead, device-mapper grabs the devices which is NOT a good thing.

Version-Release number of selected component (if applicable):


How reproducible:

Every time.  The code block simply isn't there anymore.  The following code
block USED to be directly before the device-mapper initialization...

# RAID setup
update_boot_stage RCraid
if [ -f /etc/mdadm.conf ]; then
    /sbin/mdadm -A -s --auto=yes

Steps to Reproduce:
1.  Create a md raid array and update mdadm.conf accordingly
2.  Reboot.
Actual results:

The md array is not created and device mapper has incorrectly grabbed the devices.

Expected results:

mdadm should have been executed first creating the correct array and associated
device nodes.

Additional info:

A non-partitioned array can be automatically started from the kernel command
line but md is compiled as a module making it a little tricky and this method
doesn't handle partitionable arrays correctly (the partition device nodes aren't
Comment 1 Randy Zagar 2008-05-19 13:53:03 EDT
This creates additional problems when lvm volume groups use md raid arrays.
Comment 2 Bill Nottingham 2008-05-19 16:25:05 EDT
MD arrays are assembled by udev. See /etc/udev/rules.d/70-mdadm.rules

So, the question is why aren't they being assembled in your case. Do you have a
Comment 3 George Joseph 2008-05-19 22:43:38 EDT
Here's my mdadm.conf

DEVICE /dev/sd[bc]1
ARRAY /dev/md_d0 level=raid1 num-devices=2 auto=mdp

I've completely re-installed the test box and brought it up to date and I've
been able to make a little more progress...

The old rc.sysinit did a "mdadm --assemble" which started all the arrays in the
mdadm.conf file.

Using the mdadm.conf example from above, mdadm creates the following device nodes...

(9,0) md0

All of which are correct.

Looking at 70-mdadm.rules I see it does a "mdadm --incremental" as each
underlying device is found.  When mdadm find enough devices to start the array,
it does so.

Using the same mdadm.conf example, here's what I get..

(9,0) md0
(9,0) md_d0

I can reproduce this from the command line so maybe the issue is with mdadm.

If you agree I'll reassign the bug to the mdadm component.

Comment 4 Bill Nottingham 2008-05-20 10:51:41 EDT
Hm, possibly. What happens if you add the UUID of the array to the ARRAY line?
Comment 5 George Joseph 2008-05-20 13:16:54 EDT
No change with uuid added.  I also tried changing auto=mdp to auto=mdp4 as a
hint to create 4 partition device nodes but it didn't help either.  Then I tried
creating the array directly on the disk nodes (sdb, sdc instead of sdb1, sdc1)
but still no go.  incremental just seems to ignore the request to create a
partitionable array.  A quick look at the source code shows comments in
Incremental.c that make me believe that it should.

Comment 6 Bill Nottingham 2008-05-20 13:29:12 EDT
Assigning to mdadm for now.
Comment 7 George Joseph 2008-05-20 14:10:54 EDT

The mdadm package is mdadm-2.6.4-4.fc9.x86_64

Comment 8 George Joseph 2008-05-21 18:15:30 EDT
created a new bug for mdadm with a patch
resolving this one as a dup

*** This bug has been marked as a duplicate of 447818 ***

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