Bug 446998 - md type raid arrays are no longer assembled by rc.sysinit
Summary: md type raid arrays are no longer assembled by rc.sysinit
Keywords:
Status: CLOSED DUPLICATE of bug 447818
Alias: None
Product: Fedora
Classification: Fedora
Component: mdadm
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-16 21:57 UTC by George Joseph
Modified: 2008-05-21 22:15 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-21 22:15:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description George Joseph 2008-05-16 21:57:07 UTC
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 17:53:03 UTC
This creates additional problems when lvm volume groups use md raid arrays.

Comment 2 Bill Nottingham 2008-05-19 20:25:05 UTC
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-20 02:43:38 UTC
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 14:51:41 UTC
Hm, possibly. What happens if you add the UUID of the array to the ARRAY line?

Comment 5 George Joseph 2008-05-20 17:16:54 UTC
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 17:29:12 UTC
Assigning to mdadm for now.

Comment 7 George Joseph 2008-05-20 18:10:54 UTC
OK.

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



Comment 8 George Joseph 2008-05-21 22:15:30 UTC
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.