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
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??
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.
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.
Created attachment 349489 [details] /tmp/anacdump.txt after running a killall -USR2 on the anaconda process
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
Seeing the dmraid messages, I figured I would try the "nodmraid" option during boot, still, with no luck.
(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.
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.
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
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.
Created attachment 349605 [details] Output of blkid ran on non-working install of FC11
Created attachment 349606 [details] Output of fdisk -l on non-working FC11 install
Attached output of fdisk -l and blkid on computer.
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.
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.
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.
Created attachment 349776 [details] Sanatized anaconda.log
Created attachment 349778 [details] storage.log
Created attachment 349779 [details] Output from fdisk -l
Created attachment 349781 [details] anacdump.txt
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.
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.
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.
Created attachment 350654 [details] anacdump.txt Thi is my anacdump.txt file. A suggestion for installing Fedora 11 without anaconda???
(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.
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.
(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.
(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.
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??? :-)
(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.
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 ***