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)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Doug Ledford
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2008-05-21 18:15:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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):

initscripts-8.76-1.x86_64

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
fi


Steps to Reproduce:
1.  Create a md raid array and update mdadm.conf accordingly
2.  Reboot.
3.
  
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
created).
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
mdadm.conf?
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
        devices=/dev/sdb1,/dev/sdc1

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
(254,0)md_d0
(254,1)md_d0p1
(254,2)md_d0p2
(254,3)md_d0p3
(254,4)md_d0p4

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
OK.

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.