Bug 441137 - software raid is not started
software raid is not started
Product: Fedora
Classification: Fedora
Component: dmraid (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: Heinz Mauelshagen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-04-06 13:48 EDT by dex
Modified: 2008-10-16 08:47 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-09-27 16:02:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
partitions (1.03 KB, text/plain)
2008-04-08 18:11 EDT, dex
no flags Details

  None (edit)
Description dex 2008-04-06 13:48:32 EDT
Description of problem:
Software raid is not started from fstab

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

How reproducible:

Steps to Reproduce:
Actual results:
Drives are not found in /etc/fstab 

Expected results:
drives to be mounted

Additional info:
manually running 'dmraid -ay' results in a perfect start.
Comment 1 Casey Dahlin 2008-04-06 15:02:19 EDT
What could have changed to cause this?
Comment 2 Warren Togami 2008-04-07 10:41:46 EDT
This has nothing to do with upstart.  This is the job of mkinitrd?
Comment 3 Bill Nottingham 2008-04-07 12:13:52 EDT
Please attach /proc/partitions and /proc/mdstat after a successful boot, as well
as the output of 'dmsetup ls', so we can assign this to the proper component.
Comment 4 dex 2008-04-08 18:09:50 EDT
I see at boot,
Mounting other Filesystems :mount failed for /dev/mapper/pdc_bjebbjhcb1 
mount failed for /dev/mapper/pdc_jgabafbj1   [FAILED]
These are the drives I have listed in fstab.
/proc/partitions is attached from boot.
Personalities :
unused devices: <none>
dmsetup ls shows no devices.
after dmraid -ay dmsetup ls shows
pdc_bjebbjhcb1	(253, 3)
pdc_bjebbjhcb	(253, 1)
pdc_jgabafbj	(253, 0)
pdc_jgabafbj1	(253, 2)
Comment 5 dex 2008-04-08 18:11:10 EDT
Created attachment 301721 [details]
Comment 6 Bug Zapper 2008-05-14 04:59:01 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 7 dex 2008-05-18 17:45:39 EDT
workaround: using dmraid -ay in /etc/rc.local for now.
Comment 8 Bill Nottingham 2008-05-19 16:16:36 EDT
Out of curiousity - what happens if you try the initscripts package currently in
Comment 9 dex 2008-05-22 15:21:47 EDT
No change with initscripts-8.76.2-1.i386
at start up.
I'm also now being flooded with these messages:

attempt to access beyond end of device
sdc: rw=0, want=320159171, limit=160086528
Buffer I/O error on device sdc1, logical block 160079553
attempt to access beyond end of device
sdc: rw=0, want=320159173, limit=160086528
Buffer I/O error on device sdc1, logical block 160079554
attempt to access beyond end of device
sdc: rw=0, want=320159175, limit=160086528
attempt to access beyond end of device
sdc: rw=0, want=320159369, limit=160086528
attempt to access beyond end of device
sdc: rw=0, want=320159371, limit=160086528
attempt to access beyond end of device
sdc: rw=0, want=320159373, limit=160086528
attempt to access beyond end of device
sdc: rw=0, want=320159375, limit=160086528
where sdc & sdd 2x80Gb make up the fake raid.
Comment 10 dex 2008-05-24 01:52:52 EDT
wait I've been seeing this for sometime in rawhide also look at this dmesg: 
Comment 11 Mike Gahagan 2008-06-03 16:05:00 EDT
I hit a similar issue after adding 3 hard disks to an already installed F9
x86_64 system. The disks make up an md RAID 5 array with LVM on top. Nothing I
did with mkinitrd or fstab would ever bring up the array on boot, however when I
created an /etc/mdadm.conf file it all started working and I was pretty sure I
never had the config file before and it was just all autodetected. I still have
the old system the drives came out of I can take a look at to grab any old
config files if needed, but it all seems to work great now. I was always able to
bring up the array & logical volumes manually by doing:

mdadm -auto-detect
vgchange -a y

Comment 12 dex 2008-06-26 02:22:30 EDT
Ok its getting worse, no kernel newer than will boot all fail
with this error, (hand written)

Loading ata_generic module
   -"-  dm_mod module
device-mapper:uevent:ver 1.0.3
   -"-       :ioctl:4.13 .... @redhat
Loading dm-mirror
   -"-  dm-zero
   -"-  dm-snapshot
device-mapper:table:253:0:stripped:couldnt parse strip destination
   -"-       :ioctl:error adding target to table
   -"-       :reload ioctl failed:no such device
   -"-       :table:253:0:linear:dm-linear:device lookup failed
   -"-       :ioctl:error adding target to table
   -"-       :reload ioctl failed:invalid argument
   -"-       :table ioctl failed:no such device or address
   -"-       :deps ioctl failed:no such device or address
init[1]:segfault @ 10 ip 006d30fa sp bfbfbdfc error 4 in libdevmapper.so.1.02
more stuff about nash blowing up then freeze.
Comment 13 Heinz Mauelshagen 2008-07-21 06:19:30 EDT
The opeing comment shows it's not a dmraid issue.
Was the initrd updated properly ?
If not so, outdated mapping tables could be used..
Comment 14 dex 2008-07-21 12:34:48 EDT
Thanks for replying
Yes that sounds logical dmraid will start but only after manual intervention.
I've also rebuilt initrd for all failing kernels which rules that out.
As for mapping tables I have no knowledge of, if you can provide any test for me
to perform or further information needed I'll do it but if nobody else has any
ideas alpha 10 is here I'll try again. (Sulphur stinks!)  
Comment 15 Herta 2008-08-04 17:14:28 EDT
/etc/rc.d/rc.sysinit still checks for the old software raid instead of md

If you replace

  if [ -f /etc/raidtab ]; then
  if [ -f /proc/mdstat -a -f /etc/raidtab ]; then


  if [ -f /proc/mdstat -a -f /etc/mdadm.conf ]; then
    echo $"Starting up RAID devices: "

    /sbin/mdadm --assemble --scan
    # A non-zero return means there were problems.
    if [ $RETURN -gt 0 ]; then
      echo $"*** An error occurred during the RAID startup"
      echo $"*** Dropping you to a shell; the system will reboot"
      echo $"*** when you leave the shell."

      PS1=$"(RAID Repair) \# # "; export PS1

      echo $"Unmounting file systems"
      umount -a
      mount -n -o remount,ro /
      echo $"Automatic reboot in progress."
      reboot -f

The problem is solved.

FWIIW, also applies to Red Hat
Comment 16 Bill Nottingham 2008-08-20 20:34:56 EDT
Herta, I'm not sure what version you're quoting there, but it's not Fedora 9.
Comment 17 dex 2008-09-27 16:02:22 EDT
times up!!!

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