Bug 395881 - Anaconda makes a RAID 1 system upgrade to Fedora Core 8 unbootable
Anaconda makes a RAID 1 system upgrade to Fedora Core 8 unbootable
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Joel Andres Granados
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-11-22 12:04 EST by Solaus Galti
Modified: 2008-01-31 05:48 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-31 05:48:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
fstab (684 bytes, text/plain)
2007-11-22 12:04 EST, Solaus Galti
no flags Details
mdadm.conf with the part created by anaconda and the part added by me to enable booting (692 bytes, text/plain)
2007-11-22 13:04 EST, Solaus Galti
no flags Details
create the file using mdadm (925 bytes, patch)
2008-01-30 15:06 EST, Joel Andres Granados
no flags Details | Diff

  None (edit)
Description Solaus Galti 2007-11-22 12:04:01 EST
Description of problem:

The booting stops with a kernel panic immediately after the upgrade of my Fedora
7 on a x64_86 system with 2 disks in Linux RAID 1.

The symptom was clearly indicating that the kernel cannot mount the root
directory. Suspecting that the RAID kernel modules were not included in the
initrd image I booted in the repair mode the installation cd and recreated the
initrd image. It didn't help.

After some further investigation I figure out what was the problem. The system
did not have previously a /etc/mdadm.conf file. Fedora 7 was every time matching
the physical raid volume between themselves.

For some reason during the upgrade process anaconda created the /etc/mdadm.conf
file but decided to list there only the volumes that where listed nominally in
my /etc/fstab: /dev/md1 and /dev/md2. For the rest of the md volumes anaconda
did not create entries in the new /etc/mdadm.conf file.  Among those volumes was
 /dev/md4 which was hosting a LVM on which the root partition actually was.

During the boot because the /etc/mdadm.conf file existing, I assume the kernel
was not doing anymore the discovery and thus never finding the LVM on which the
root was.

Version-Release number of selected component (if applicable):
Official Fedora 8 installation disk

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Solaus Galti 2007-11-22 12:04:01 EST
Created attachment 267111 [details]
Comment 2 Solaus Galti 2007-11-22 13:04:23 EST
Created attachment 267181 [details]
mdadm.conf with the part created by anaconda and the part added by me to enable booting
Comment 3 Rolf Fokkens 2007-12-10 13:43:45 EST
Same problem here. After the upgrade /etc/mdadm.conf seems to be incomplete,
missing the root partition. The last entry was missing after the upgrade, being
a raid5 array:

# mdadm.conf written out by anaconda
DEVICE partitions
ARRAY /dev/md3 level=raid1 num-devices=2 uuid=ece6ee77:b276bc1d:0239ad48:694e45d0
ARRAY /dev/md2 level=raid1 num-devices=2 uuid=713dcb38:131f75e0:ceada547:9ddc1617
ARRAY /dev/md4 level=raid5 num-devices=3 uuid=58698548:5f378ab7:fed52f1c:7cd4a3fd

Boot failed as this was the root partition
Comment 4 Joel Andres Granados 2008-01-28 15:25:37 EST
fresh fc7 installs have the /etc/mdadm.conf.  did you upgrade from fc6 to fc7
and then to fc8?  maybe anaconda is overwriting said file.  running some tests...
Comment 5 Joel Andres Granados 2008-01-28 16:09:21 EST
yep, as I suspected.  the file gets overwriten.  Anaconda thinks that fstab is
god :)
Comment 6 Joel Andres Granados 2008-01-30 15:06:17 EST
Created attachment 293478 [details]
create the file using mdadm

This is the patch for rawhide.	posted on the devel list to see what the
community says.

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