Bug 597423 - Installer leaves Intel BIOS Raid 1 in unsynchronized state
Installer leaves Intel BIOS Raid 1 in unsynchronized state
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-28 17:38 EDT by Markku Kolkka
Modified: 2010-05-31 16:06 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 598222 (view as bug list)
Environment:
Last Closed: 2010-05-31 16:05:18 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 Markku Kolkka 2010-05-28 17:38:11 EDT
Description of problem:
After installing a F13/WinXP dual boot system on Intel ICH8R BIOS RAID 1 and rebooting to WinXP, the Intel Matrix RAID manager reports that the RAID array is unsynchronized and starts a multi-hour rebuilding process.

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

How reproducible:
Always

Steps to Reproduce:
1. Install to RAID 1
2. reboot
  
Actual results:
RAID requires rebuilding

Expected results:
RAID array is clean and ready to use

Additional info:
Intel DG965WH motherboard, 2x WD 1TB drive in RAID 1.
Comment 1 Markku Kolkka 2010-05-29 05:33:30 EDT
The installed F13 system can be booted exactly once, reboot fails and the system needs reinstallation.
Comment 2 Hans de Goede 2010-05-31 16:05:18 EDT
Thanks for the report. I've spend some time today analyzing it, and here is what
is going on:

When moving to stage2 we rename the initrd /lib to /lib_old and add
a symlink from /lib to /mnt/runtime/lib. When shutting down we unmount
filesystems and then after unmount try to run mdadm to wait for
any Intel BIOS RAID arrays to have their metadata updated that they 
were cleanly shutdown to avoid a resync of the entire array on the next boot.

But at this point /lib is a dangling symlink, so no elf interpreter gets
found (nor libc) and the mdadm call we do fails, leaving the array unclean.

I've written a patch restoring the old /lib after unmount, and posted it to the list for review:
https://www.redhat.com/archives/anaconda-devel-list/2010-May/msg00770.html

Once reviewed I'll commit this, so that this will be fixed for F-14. I'm afraid there is nothing we can do for F-13 to retroactively fix this.
Comment 3 Hans de Goede 2010-05-31 16:06:54 EDT
(In reply to comment #1)
> The installed F13 system can be booted exactly once, reboot fails and the
> system needs reinstallation.    

If you can reproduce this consistently please file a new bug report for this, although it might be good to first wait and see what comes out of the rescue mode bug you filed, the 2 are likely related.

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