Bug 129633 - raid fails to autorun upon reboot using mdadm
raid fails to autorun upon reboot using mdadm
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Doug Ledford
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-11 02:12 EDT by Need Real Name
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-17 13:24:37 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 Need Real Name 2004-08-11 02:12:31 EDT
Description of problem:
Software raid fails to detect upon boot.
I am running a 4 disk scsi raid 0 on two scsi cards. The disks are
partitioned to use the whole drives and are nearly identical. The
partitions are labeled as linux raid autodetect. The raid builds and
assembles fine from the command line using both mdadm and mkraid yet
fails to autorun upon reboot, failing to read the raid superblock
(dmesg and /var/log/messages do not show this message, it only appears
in the boot screen). Yet when I create a /etc/raidtab (even if it is
bogus), it follows the protocol in /etc/rc.sysinit and reruns the
autorun for md, finds the array, starts it

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


How reproducible:
Beyond above, build array using mdadm, reboot.

Steps to Reproduce:
1. Build array w/o /etc/raidtab
2. Reboot
3. 
  
Actual results:
Raid fails to start.

Expected results:
Raid would be detected and run based on information stored in the raid
superblocks=.

Additional info:
Comment 1 Need Real Name 2004-08-11 10:48:12 EDT
I also received this error message in /var/log/messages while testing
using mdadm.  I am sorry I cannot remember which command caused it,
but I can attempt to reproduce:

Aug  9 11:37:24 dogen kernel: md: bug in file drivers/md/md.c, line 1513
Aug  9 11:37:24 dogen kernel:
Aug  9 11:37:24 dogen kernel: md:^I**********************************
Aug  9 11:37:24 dogen kernel: md:^I* <COMPLETE RAID STATE PRINTOUT> *
Aug  9 11:37:24 dogen kernel: md:^I**********************************
Aug  9 11:37:24 dogen kernel: md0:
Aug  9 11:37:24 dogen kernel: md:^I**********************************
Aug  9 11:37:24 dogen kernel:


Some addtional information:
Tested in both 2.6.7-1.494.2.2smp and 2.6.6-1.435.2.3smp kernels.
Scsi: Adaptec AHA-2940U/UW/D
Motherboard: Gigabyte GA-6vtxd dual 1.26 Intel proc
Comment 2 Yeechang Lee 2005-02-19 20:10:37 EST
I too have run into this problem with Fedora Core 3. I have an eight-disk
software RAID 5 array using two 3Ware 7506-4LP cards (in JBOD mode). On reboot,
the system doesn't assemble the array (despite the 'mdadm -A -s' in rc.sysinit
and a working /etc/mdadm.cojnf), so fsck/mounting the LVM logical volume in
/etc/fstab that encompasses the entire array fails, dumping me to the command
line. And like sonikbuddha, I noticed that creating a bogus, empty /etc/raidtab
did trigger proper array assembly in rc.sysinit and a consequent successful boot.

Another oddity I noticed is that, when dumped to the command line after a failed
assembly, 'cat /proc/mdstat' did reveal a properly-assembled array, so something
by that time *has* assembled the array. Weird, eh? 
Comment 3 Matthew Miller 2005-04-26 12:34:48 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 4 Doug Ledford 2005-10-17 13:24:37 EDT
No updates in 6 months, closing.

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