Bug 505488

Summary: spurious biosraid metadata prevents disk scan
Product: [Fedora] Fedora Reporter: Kevin B <fretless_kb>
Component: anacondaAssignee: David Lehman <dlehman>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 11CC: diego.p77, hdegoede, maurizio.antillon, MikeDawg, rmaximo, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-16 14:19:32 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
/tmp/anacdump.txt after running a killall -USR2 on the anaconda process
none
Output of blkid ran on non-working install of FC11
none
Output of fdisk -l on non-working FC11 install
none
Sanatized anaconda.log
none
storage.log
none
Output from fdisk -l
none
anacdump.txt
none
blkid output
none
anacdump.txt none

Description Kevin B 2009-06-12 01:07:23 EDT
Description of problem:
During Installation (from .iso) process no hard drive is recognized. This  system is currently running Fedora 10 and during boot the hard drive is recognized but after stepping through the install screens when presented with the install to screen there are no HD shown and selecting next results in an error no media found to install to.

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

How reproducible:
try to install from .iso (DVD)

Steps to Reproduce:
1.
2.
3.
  
Actual results:
No Media discovered to install to

Expected results:
Should see the 100 G HD

Additional info:
Drive is Samsung SP1213C SV100-25
Processor AMD Athalon 64 x2 Dual Core 4000+ w/ 2Gb RAM
Comment 1 diego 2009-06-15 13:17:08 EDT
I have the same problem with my hardware. I have the same Processor, but the hard drive is a Samsung PATA 400GB. When anaconda try to find hard drive for partitioning, it doesn't see it. But if I change the tty (tty2 -> crtl+alt+f2), and use fdisk -l command, the hard drive is present, and I can create partition, filesystem etc.. I thing it's an anaconda problem, because, if i use Fedora 10 (and relative anaconda version), I don't see this problem. 
Now ... what do I do for installin Fedora 11 on my machine??
Comment 2 Mike 2009-06-25 00:17:27 EDT
I'm also having this problem.  I am experiencing this problem on a Dell OptiPlex 330.  It detects, and allows options to install on /dev/sdb (SATA1), however, anaconda doesn't "see" /dev/sda (SATA0).

I am trying to install Fedora Core 11 x86_64.  To verify the problem doesn't exist with the drive, or the controller, I tried booting/installing Fedora Core 10 x86_64, and anaconda detected the HD, and presented install options for /dev/sda (SATA0).  

Looking at dmesg I see that the kernel in FC11 is detecting the first HD, /dev/sda, however it seems anaconda doesn't want to present it as an install option.  The only possible pertinent info I could see in dmesg is:

  Driver 'sd' needs updating - please use bus_type methods



Specs for Dell OptiPlex 330:

Chipset:  Intel G31 Express
I'm unsure the chipset of the SATA controller.
Comment 3 David Lehman 2009-06-25 11:07:07 EDT
In order to do anything with this report I will need some more information. Once you reach the point where there are no drives shown, please switch to tty2 (ctl + alt + f2), then run 'killall -USR2 anaconda'. This will generate a file named /tmp/anacdump.txt -- please use scp or other means to transfer the file somewhere and attach it to this bug report. Thanks.
Comment 4 Mike 2009-06-25 20:24:48 EDT
Created attachment 349489 [details]
/tmp/anacdump.txt   after running a killall -USR2 on the anaconda process
Comment 5 Mike 2009-06-25 20:25:43 EDT
Attached a file for what is happening in my case.  Please let me know if I am posting this under a pertinent ticket, or if I should create a new ticket for my case.  Thanks
Comment 6 Mike 2009-06-25 20:32:40 EDT
Seeing the dmraid messages, I figured I would try the "nodmraid" option during boot, still, with no luck.
Comment 7 David Lehman 2009-06-26 14:55:14 EDT
(In reply to comment #5)
> Attached a file for what is happening in my case.  Please let me know if I am
> posting this under a pertinent ticket, or if I should create a new ticket for
> my case.  Thanks  

Since I still have no information from the other reporters I cannot say if your problem is different from theirs.

In the meantime, can you describe the layout of your disks? We seem to have detected sda as a DDF raid member, which explains to some extent it not showing up.
Comment 8 Mike 2009-06-26 15:12:00 EDT
I'm not 100% sure what you mean by layout of the disks.

I was going to be clever, and get you the anacdump.txt from what a FC10 install looks like, however, when I run the killall -USR2 anaconda, it switches to runlevel 6 or 0.  

Do you think an anacdump.txt from a successful FC10 install would show you more?

What I can tell you, is that SDA is a 250G Seagate SATA disk, SDB is a 250G Maxtor SATA disk.  SDA as expected, is plugged in to SATA Controller spot 0 and SDB is plugged into SATA controller spot 1.

SDA is currently formatted with NTFS.  Please let me know what you would like me to do in order to show you more information.
Comment 9 Mike 2009-06-26 15:15:47 EDT
I can tell you, that I initially ran into this problem while trying to upgrade to FC11 from FC10.  After the reboot required to start the install of the new FC11, I got the error message that it couldn't find the root partition, which would make sense, if it couldn't find /dev/sda
Comment 10 David Lehman 2009-06-26 16:52:21 EDT
Udev (vol_id) detects sda as being formatted as DDF RAID. I'm curious what the output of 'blkid' and 'fdisk -l' look like.

FWIW I think vol_id was dropped from udev in favor of blkid, which has been moved from e2fsprogs into util-linux-ng.
Comment 11 Mike 2009-06-26 17:03:29 EDT
Created attachment 349605 [details]
Output of blkid ran on non-working install of FC11
Comment 12 Mike 2009-06-26 17:04:07 EDT
Created attachment 349606 [details]
Output of fdisk -l on non-working FC11 install
Comment 13 Mike 2009-06-26 17:04:28 EDT
Attached output of fdisk -l and blkid on computer.
Comment 14 David Lehman 2009-06-26 17:21:07 EDT
Mike, it looks like udev/vol_id is detecting spurious ddf metadata on sda. This causes anaconda to treat it like a member of a ddf raid array, and therefore not show it as a disk for installation. Basically, this looks like a bug in udev. However, since we are moving to blkid in rawhide, fixing udev may not be worth pursuing.
Comment 15 Mike 2009-06-26 18:03:10 EDT
Is there any way to remove the spurious ddf metadata on sda?  The odd thing is, I have since tried a different HD; a 250 GB Western Digital, and same thing is happening.  

I'd have to assume that it is something like the controller that is presenting the metadata, and not the drive itself.
Comment 16 Steve Berg 2009-06-29 08:36:51 EDT
I beleive I'm seeing this same problem.  I use pxeboot to do a kickstart install, everything comes up fine until I get to partitioning.  At that point only /dev/sdb is seen by anaconda.  From the console I can see all four drives and I can assemble the software RAID array's just fine.  I'll attach the storage.log, anaconda.log and the output from fdisk -l to help out.
Comment 17 Steve Berg 2009-06-29 08:41:32 EDT
Created attachment 349776 [details]
Sanatized anaconda.log
Comment 18 Steve Berg 2009-06-29 08:45:05 EDT
Created attachment 349778 [details]
storage.log
Comment 19 Steve Berg 2009-06-29 08:45:33 EDT
Created attachment 349779 [details]
Output from fdisk -l
Comment 20 Steve Berg 2009-06-29 09:31:24 EDT
Created attachment 349781 [details]
anacdump.txt
Comment 21 Steve Berg 2009-06-29 09:32:41 EDT
Created attachment 349782 [details]
blkid output

This is output from blkid under Fedora 10 running normally and a Fedora 11 installation on the same system.
Comment 22 Steve Berg 2009-06-30 08:53:18 EDT
Looks like my situation was caused by some metadata still on three of the harddrives from an old hardware raid setup.  I got the metadata deleted using dmraid and an install this morning went smoothly.
Comment 23 Mike 2009-07-02 11:03:54 EDT
It looks like my problem was also caused by some metadata being on the HD.  However, I was unable to remove the metadata using dmraid -E.  It got to the point where I low-level formatted the HD, and was then able to install FC11.
Comment 24 diego 2009-07-06 13:47:44 EDT
Created attachment 350654 [details]
anacdump.txt

Thi is my anacdump.txt file. A suggestion for installing Fedora 11 without anaconda???
Comment 25 David Lehman 2009-07-06 15:14:07 EDT
(In reply to comment #24)
> Created an attachment (id=350654) [details]
> anacdump.txt
> 
> Thi is my anacdump.txt file. A suggestion for installing Fedora 11 without
> anaconda???  

First you could try removing the spurious metadata using dmraid -E as others have done.

Alternatively, I think that there may be a procedure for upgrading an F10 system to F11 using yum documented somewhere.
Comment 26 Mike 2009-07-06 15:53:23 EDT
The upgrade procedure fails with the same results as the initial FC11 install.  Your only option in the upgrade is to successfully remove the dmraid data using dmraid -E.
Comment 27 David Lehman 2009-07-07 02:41:31 EDT
(In reply to comment #26)
> The upgrade procedure fails with the same results as the initial FC11 install. 
> Your only option in the upgrade is to successfully remove the dmraid data using
> dmraid -E.  

I was referring to upgrade using yum -- not anaconda.
Comment 28 Mike 2009-07-07 07:58:04 EDT
(In reply to comment #27)
> (In reply to comment #26)
> > The upgrade procedure fails with the same results as the initial FC11 install. 
> > Your only option in the upgrade is to successfully remove the dmraid data using
> > dmraid -E.  
> 
> I was referring to upgrade using yum -- not anaconda.  

The very first install of FC11 that I attempted was using the "preupgrade" utility, which I believe is the yum process.  This upgrade failed for me, probably for the same reason all the other upgrades failed, because of the spurious dmraid data on the disk.
Comment 29 diego 2009-07-07 10:45:31 EDT
Ok, I run dmraid -r /dev/sdb -E and anaconda find the harddrive. Now I install Fedora 11. Thank you at all. 
P.S.: But It's possible to autodeterminating the raid metadata via anaconda and removing it via gui??? :-)
Comment 30 David Lehman 2009-07-07 15:28:19 EDT
(In reply to comment #28)
> (In reply to comment #27)
> > (In reply to comment #26)
> > > The upgrade procedure fails with the same results as the initial FC11 install. 
> > > Your only option in the upgrade is to successfully remove the dmraid data using
> > > dmraid -E.  
> > 
> > I was referring to upgrade using yum -- not anaconda.  
> 
> The very first install of FC11 that I attempted was using the "preupgrade"
> utility, which I believe is the yum process.  This upgrade failed for me,
> probably for the same reason all the other upgrades failed, because of the
> spurious dmraid data on the disk.  

That's because preupgrade uses anaconda. I was talking about strictly using yum, not in conjunction with anaconda.
Comment 31 Hans de Goede 2009-09-16 14:19:32 EDT
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 ***