This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1024513 - Hard drive is not detected during install of Fedora 19 x86_64
Hard drive is not detected during install of Fedora 19 x86_64
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-29 16:06 EDT by Yan Li
Modified: 2016-11-08 12:00 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-17 10:05:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
elliot.li.tech: needinfo-


Attachments (Terms of Use)
storage.log (68.30 KB, text/plain)
2013-10-29 16:06 EDT, Yan Li
no flags Details
syslog (132.07 KB, text/plain)
2013-10-29 16:07 EDT, Yan Li
no flags Details

  None (edit)
Description Yan Li 2013-10-29 16:06:02 EDT
Created attachment 817173 [details]
storage.log

Description of problem:
The installation media is a F19 x86-64 netinst CD-R that passed boot media test. Anaconda's GUI shows "No disks detected", while two hard drives are shown in dmesg as sda and sdb. SATA is configured as AHCI in BIOS.

Machine is a Colfax blade server.

HDs are two ST9500620NS.

Version-Release number of selected component (if applicable):
Official F19 netinst x86-64 CD.

How reproducible:
Always

Steps to Reproduce:
1. Boot machine by using the F19 netinst x86-64 CD
2. Select US keyboard
3. Go to select disk and see "No disks detected."
4. Press Ctrl-Alt-F2 to switch to shell and run dmesg, see two hard disks are properly detected as sda and sdb.

Actual results:
No disks detected by Anaconda.

Expected results:
Two hard drives should be detected.

Additional info:
In storage.log, sda is detected as "part of a biosraid". I have no idea why that is. In BIOS the SATA disks are set as AHCI, not RAID. The machine worked well running F18 before. This bug might be a duplicate of #947100.
Comment 1 Yan Li 2013-10-29 16:07:01 EDT
Created attachment 817174 [details]
syslog
Comment 2 David Shea 2014-01-02 16:17:47 EST
No disks are selected because you didn't select any disks. Based on the storage.log, there should be two disks available when you enter the installation destination spoke. If this not the case, reopen this bug.
Comment 3 newton21989 2014-01-12 20:55:29 EST
David, read carefully. The OP said no drives were DETECTED, not selected. If he is having the same issue I am, it's that when you go to select the drive to install to, it isn't there, even though it is detected elsewhere, such as dmesg and /dev.
Comment 4 Yan Li 2014-01-12 22:40:40 EST
(In reply to David Shea from comment #2)
> No disks are selected because you didn't select any disks. Based on the
> storage.log, there should be two disks available when you enter the
> installation destination spoke. If this not the case, reopen this bug.

That is not the case. Anaconda didn't display any disk for me to choose.
Comment 5 newton21989 2014-01-13 20:02:45 EST
After some additional research and experimenting, I have a solution, which is not to say a bug does or doesn't exist, but for my purposes, its acceptable. First, some additional context: the Anaconda installer was only showing one of three hard drives attached to the system. All three are MBR drives, as opposed to GPT.

Output from' fdisk -l' showed that the first sector of the two drives that were not appearing was 63, and for the one that was, 2048. After moving the first partition a couple MB from of the beginning of the partition table on an affected drive, it now appears in Anaconda.

The issue appears to be directly related to where the partition table starts, but as far as I'm concerned, burning a meg or two is trivial. The biggest inconvenience is waiting on the partition to resize. Also, I would expect this problem to become less common as more drives are switching to GPT and not being originally formatted under Windows XP, as was my case.

Anyway, hope this helps.
Comment 6 David Shea 2014-03-07 14:16:45 EST
The storage log attached shows sda1 and sdb1 starting at 2048 sectors, so I that is not the issue. Does this problem still occur with F20 or rawhide?
Comment 7 Yan Li 2016-11-08 12:00:52 EST
We have been using dnf upgrade since then and haven't installed any new system yet so I haven't gotten a chance to test. Closing this for now.

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