Red Hat Bugzilla – Bug 508554
Anaconda fails to see the existing F10 install
Last modified: 2009-08-10 05:43:46 EDT
Description of problem:
Anaconda does not see the existing F10 installation, does not offer an option to upgrade an existing system or to do a fresh install, and jumps straight into a fresh install path. On the ALT-F2 user shell, I can individually mount the existing F10 partitions and access them. The Anaconda kernel sees the disks and the partitions just fine. Anaconda does not.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
The system has three hard drives:
An IDE hard drive containing another operating system.
Two SCSI hard drives, Adaptec 29320 HBA, aic79xx.o kernel module. Three Linux software RAID-1 partitions, with F10.
After the "Finding storage" dialog box, Anaconda then jumps straight into the fresh install code, without prompting me an option to upgrade. The subsequent storage screen shows a single drive /dev/sda. The two SCSI drives are missing.
At this time I can:
* Flip over to the user shell the ALT-F2 tty screen
* Run mdadm --assemble --scan
* mdadm ends up creating /dev/md125, /dev/md126, and /dev/md127 (!)
* I can mount these device nodes, and access my existing F10 installation.
So, when Anaconda installer starts, there are no issues with loading aic79xx.o. The kernel sees the two SCSI drives just fine. Anaconda for some reason does not detect /dev/sdb and /dev/sdc, does not see the existing "Linux raid autodetect" partitions, and does not invoke mdadm to assemble the existing RAID partitions.
Can you attach /tmp/anaconda.log and /tmp/storage.log, please?
Created attachment 349884 [details]
Thanks for the tip where to look. Here's storage.log
The culprit is the "ignoring /dev/sdb" and "ignoring /dev/sdc" messages. They weren't ignored in F10's anaconda :-)
P.S. These, and the following attachments were obtained by:
1. Flipping to ALT-F2
2. Running mdadm --assemble --scan
3. Mounting the resulting /dev/mdXXX device node
4. Copying /tmp/*.log to my existing F10 partition
5. Rebooting into F10, and posting these files
So, everything's there, but Anaconda refuses to look. One possibility is that these partitions are on a hard drive that's attached to an Adaptec HBA that has an optional RAID personality. That's some funky Adaptec proprietary RAID, however the HBA is configured as a standard SCSI HBA. It's hardware RAID functionality is turned off -- I never used it -- and I am using Linux software raid only. Anaconda might be making a wrong decision there to leave them alone, to dmraid or some other proprietary driver to deal with, but it should not be doing that. It should be cranking up mdadm and assembling these arrays...
Created attachment 349885 [details]
Created attachment 349886 [details]
/dev/sdb and /dev/sdc, as seen by fdisk
Also, here's what fdisk says about sdb and sdc.
As you can see, these are ordinary Linux softraid partitions.
Sorry for taking so long to get back to you, the issue is that your sdb and sdc drives contain BIOS RAID metadata (they probably have been used in such a setup once upon a time). Below the standard answer / explanation for issues with stale
BIOS RAID metadata:
There has been a behavioural change between F-10 and F-11 where in F-10 drives
which contain invalid / stale dmraid (BIOS RAID) metadata / which were part of
an incomplete BIOS RAID set would be just seen as the raw disks, where as F-11
these drives are ignored.
In F-10 in cases where dmraid was detected unwantedly (in case of a complete
set, but being disabled in the BIOS for example), the BIOS RAID detection could
be avoided with nodmraid. In F-11 this option currently does not work, this is
bug 499733. Once 499733 is fixed you can workaround your issue using the
nodmraid installer cmdline option.
Note that a better solution would be to remove the unwanted BIOS RAID metadata
from the disks, this can be done using "dmraid -x", be sure to make backups
before doing this! "dmraid -x" should leave your data intact, but better safe
Also only do this if you really want your disks to not be part of a BIOS RAID
set, if for example windows is currently using the disks as a BIOS RAID set you
do not want to do this!
*** This bug has been marked as a duplicate of bug 499733 ***