Bug 446998
| Summary: | md type raid arrays are no longer assembled by rc.sysinit | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | George Joseph <g.devel> |
| Component: | mdadm | Assignee: | Doug Ledford <dledford> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 9 | CC: | notting |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-05-21 22:15:30 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: | |||
This creates additional problems when lvm volume groups use md raid arrays. 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? 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.
Hm, possibly. What happens if you add the UUID of the array to the ARRAY line? 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. Assigning to mdadm for now. OK. The mdadm package is mdadm-2.6.4-4.fc9.x86_64 |
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).