Red Hat Bugzilla – Bug 168317
default mdadm command in rc.sysinit does not init RADI devices
Last modified: 2007-11-30 17:11:13 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Description of problem:
This originally started as an upgrade issue (FC3 -> FC4) where my RAID config was not being recognized. I gave up on getting it to migrate and ended up re-creating the RAID 5 device (/dev/md1) from scratch. Even after recreating it, it was never recognized on boot up. Once the system did boot up, I could only ever get the device activated by using the command "mdadm -A /dev/md1". I also created a mdadm.conf file listing the devices and the array information, but could never get the "mdadm -A -s" format of the command to work. Because this is the format of the command specified in the /etc/rc.sysinit file, I modified /etc/rc.sysinit to use the "mdadm -A /dev/md1" format instead, and everything works fine.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create RAID device (e.g., /dev/md1) but don't add entry to /etc/fstab
2. create /etc/mdadm.conf file as per man pages
3. reboot system and run 'mdadm -D /dev/md1'
4. run 'mdadm -A -s' and 'mdadm -D /dev/md1' again
5. run 'mdadm -A /dev/md1' and 'mdadm -D /dev/md1' again
Actual Results: after step 3 above, the command indicated that no RAID devices were active/running
after step 4, the same thing happens - no RAID devices
after step 5 the RAID device is activated and the detailed status information is provided
Expected Results: 'mdadm -A -s' should have recognized the /etc/mdadm.conf file and started the RAID device on boot up.
After I got everything back up and running and started my data restore, I checked my old /etc/mdadm.conf and /etc/rc.sysinit files and they were identical to the defaults (mdadm.conf - same devices, etc; rc.sysinit had not been modified and still used 'mdadm -A -s').
Please post the contents of your mdadm.conf file and the output of /proc/mdstat
when the array in question is up and running.
(In reply to comment #1)
> Please post the contents of your mdadm.conf file and the output of /proc/mdstat
> when the array in question is up and running.
Here it is along with the output of mdadm -D /dev/md1:
# mdadm -D /dev/md1
Version : 00.90.02
Creation Time : Wed Sep 14 10:10:25 2005
Raid Level : raid5
Array Size : 240129600 (229.01 GiB 245.89 GB)
Device Size : 80043200 (76.34 GiB 81.96 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Mon Oct 31 17:29:14 2005
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 0d52afed:19610c0a:ac9a96b9:913257e9
Events : 0.301475
Number Major Minor RaidDevice State
0 33 0 0 active sync /dev/hde
1 34 0 1 active sync /dev/hdg
2 56 0 2 active sync /dev/hdi
3 57 0 3 active sync /dev/hdk
# cat /proc/mdstat
Personalities : [raid5]
md1 : active raid5 hde hdk hdi hdg
240129600 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>
# cat /etc/mdadm.conf
DEVICE /dev/hde /dev/hdg /dev/hdi /dev/hdk
ARRAY /dev/md1 devices=/dev/hde,/dev/hdg,/dev/hdi,/dev/hdk
This report targets the FC3 or FC4 products, which have now been EOL'd.
Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?
This bug should no longer be present in modern fedora. It most likely was an
issue with the mdadm -A -s command also needing the --auto=yes flag to create
the device node before attempting to start the device. Note: the bug is also
related to using whole disk devices instead of partitions to create the raid
array, if the md1 device had been made out of partitions that were marked for
auto assembly, then the bug would have been completely avoided.