Bug 168660
| Summary: | Software Raid Mirror wont boot from second disk | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lars Hentschke <nuggets> |
| Component: | anaconda | Assignee: | Peter Jones <pjones> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7 | CC: | bbaetz, curtis, k.georgiou, lfelipebm |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-04-25 03:40:21 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: | |||
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. 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. :-) 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. 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. 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! Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9. 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. |
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]