Bug 508554

Summary: Anaconda fails to see the existing F10 install
Product: [Fedora] Fedora Reporter: Sam Varshavchik <mrsam>
Component: anacondaAssignee: Hans de Goede <hdegoede>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: rmaximo, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-08-10 05:43:46 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
/dev/sdb and /dev/sdc, as seen by fdisk none

Description Sam Varshavchik 2009-06-28 10:47:45 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):


How reproducible:


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.
Comment 1 Andy Lindeberg 2009-06-29 11:35:27 EDT
Can you attach /tmp/anaconda.log and /tmp/storage.log, please?
Comment 2 Sam Varshavchik 2009-06-29 18:32:06 EDT
Created attachment 349884 [details]

Thanks for the tip where to look. Here's storage.log

The culprit is the "ignoring /dev/sdb[123]" and "ignoring /dev/sdc[123]" 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...
Comment 3 Sam Varshavchik 2009-06-29 18:32:36 EDT
Created attachment 349885 [details]
Comment 4 Sam Varshavchik 2009-06-29 18:34:41 EDT
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.
Comment 5 Hans de Goede 2009-08-10 05:43:46 EDT
Hi Sam,

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
then sorry.

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 ***