Bug 129633

Summary:	raid fails to autorun upon reboot using mdadm
Product:	[Fedora] Fedora	Reporter:	Need Real Name <sonikbuddha>
Component:	mdadm	Assignee:	Doug Ledford <dledford>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	2	CC:	mattdm, ylee
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:	FC4	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-10-17 17:24:37 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:

Description Need Real Name 2004-08-11 06:12:31 UTC

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 14:48:12 UTC

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-20 01:10:37 UTC

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 16:34:48 UTC

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 17:24:37 UTC

No updates in 6 months, closing.