Bug 526606 - boot fails with initramfs (/boot on raid1 md0)
boot fails with initramfs (/boot on raid1 md0)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Doug Ledford
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-30 20:36 EDT by Allen Kistler
Modified: 2009-11-09 02:23 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-09 02:23:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
serial console log from failed boot with initramfs (20.28 KB, text/plain)
2009-09-30 20:36 EDT, Allen Kistler
no flags Details

  None (edit)
Description Allen Kistler 2009-09-30 20:36:59 EDT
Created attachment 363273 [details]
serial console log from failed boot with initramfs

Description of problem:
Booting with ext2 /boot on raid1 md0 and ext3 / on LVM on raid 1 md1 fails and drops to maintenance prompt.  The problem appears to be md0 (/boot) is stopped soon after it is started.  Additionally rc.sysinit appears to be run twice.  (Console log attached.)  The same problems do not occur using initrd.

Version-Release number of selected component (if applicable):
dracut-002-8.git845dd502.fc12.noarch

How reproducible:
Always

Steps to Reproduce:
1. Given /boot on raid1 md0 and / on lvm on raid1 md1, boot
  
Actual results:
Boot fails and drops to maintenance prompt.
Some boot messages are repeated.  (see attached serial console log)

Expected results:
System boots.

Additional info:
I tried using device UUID vs super-minor in /etc/mdadm.conf.
I tried using fs UUID vs /dev/md0 in /etc/fstab.
All combinations result the same way.
Comment 1 Harald Hoyer 2009-10-01 05:43:58 EDT
 /etc/rc.d/rc.sysinit: line 343:   631 Segmentation fault      /sbin/mdadm -As --auto=yes --run

I blame it on mdadm :)
Comment 2 Doug Ledford 2009-11-05 14:29:38 EST
What version of mdadm was on the system, and are you still seeing this or has it been resolved since this report was filed?
Comment 3 Allen Kistler 2009-11-09 02:23:51 EST
The current version on the system is mdadm-3.0.2-1.fc12.
The problem appears to be resolved.

Closing...

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