Bug 168660 - Software Raid Mirror wont boot from second disk
Software Raid Mirror wont boot from second disk
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
7
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-19 04:39 EDT by Lars Hentschke
Modified: 2008-08-02 19:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-24 23:40:21 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 Lars Hentschke 2005-09-19 04:39:51 EDT
Description of problem:
I installed Fedora on 2 SATA Disks (Via SATA Chip). The SATA-Disks running as 2
seperate Disks, not as a RAID (via BIOS). The Disks are identical, have 5
Partitions /boot / /var /usr /home, all done via Anaconda Installer and Software
RAID 1 (Mirro mode) setup. /proc/mdstat says that all ist OK and both Disks of
the mirror are UP.
Problem: The system wont start up from the second disk (in case the first had
crashed)

Version-Release number of selected component (if applicable):
mdadm v1.11.0

How reproducible:
Install a FC4 System only on Software RAID 1 Partitions, try to boot from the
second disk.
  
Actual results:
Blank black screen, no Grub/Fedora Bootup

Expected results:
Bootup the normal System in degraded mirror-mode

Actual md-config:
[root@gbit-11 ~]# mdadm --detail --scan
ARRAY /dev/md3 level=raid1 num-devices=2 UUID=aaaf1f00:0f51f401:5e76e458:720e9bd3
   devices=/dev/sda2
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=5a2483c2:a245bafe:077cf48f:81518b41
   devices=/dev/sda5
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=57f3e9b8:5720a16d:45026c32:0909c161
   devices=/dev/sda6
ARRAY /dev/md4 level=raid1 num-devices=2 UUID=af7c91cf:6bfa5a49:66683826:2e585fcd
   devices=/dev/sda7
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=489f97f6:8aa857ac:da4e1519:07b93545
   devices=/dev/sda1

/proc/mdstat:
md3 : active raid1 sda2[0]
      20972736 blocks [2/1] [U_]

md2 : active raid1 sda5[0]
      2096384 blocks [2/1] [U_]

md1 : active raid1 sda6[0]
      1052160 blocks [2/1] [U_]

md4 : active raid1 sda7[0]
      363968512 blocks [2/1] [U_]

md0 : active raid1 sda1[0]
      521984 blocks [2/1] [U_]

unused devices: <none>

(the mirrors are on /dev/sdb[12567]
Comment 1 Doug Ledford 2005-10-31 15:25:03 EST
Changing component to anaconda (the installer).  This is a bug in the initial
boot loader setup done during the install phase.  Mdadm doesn't attempt to
manage boot up in any way.  It is up to the installer (anaconda) to make sure
that grub is properly installed on both sda and sdb during installation.
Comment 2 Curtis Doty 2005-12-08 10:28:39 EST
I met this bug and hacked around it by adding the following to my kickstart %post:

echo 'root (hd2,0)
setup (hd2)' |/sbin/grub --batch
sync

Of course this worked for me because my /boot raid1 set was using sda and sdc. I
think if you user sda/sdb then it should be hd1 above. Not sure how to make it
work dynamic properly. I do have a note in my script which says:

# [expletive deleted] anaconda does weird [expletive deleted] with grub and it
goes error 16 instead of copying to the second boot drive in mirror, so we must
do it ourself

Hope that helps. :-)
Comment 3 Christian Iseli 2007-01-19 19:39:30 EST
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 ?

Thanks.
Comment 4 Curtis Doty 2007-01-19 19:44:46 EST
Have been ongoing...haven't noticed any change.

Basic steps I'm using:
 #1 zero out boot disks
 #2 use anaconda/kickstart to install raid1 /boot
 #3 inspect MBR on each disk

One will have grub. One won't. Above hack works; although it requires
hard-coding whatever drive number grub thinks is the second boot disk in the
raid1 md.
Comment 5 Luis Felipe Marzagao 2007-11-02 00:34:34 EDT
I'm using F7 here and apparently the same issue occurs. If I manually run "grub"
then do a:

root (hd1,0)
setup (hd1)
quit

The second HD will be able to boot just fine alone in the system.

Then I can re-add the first one and do a "mdadm --manage --re-add /dev/mdX
/dev/sdaX" and it will re-sync okay.

I might be wrong, but I guess the trouble here is that anaconda should install
the boot loader directly in the disk MBR (hd0) and (hd1) instead of in the disk
partition (hd0,0) and (hd1,0), when the users chooses a RAID 1 setup. What do
you think?

Cheers!

Comment 6 Brian Powell 2008-04-24 23:40:21 EDT
Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.
Comment 7 Brian Powell 2008-04-25 01:04:39 EDT
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "CLOSED INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.

Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.

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