Bug 513257 - Sata disks not identified by stable Fedora 11 upgrade or install
Summary: Sata disks not identified by stable Fedora 11 upgrade or install
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 11
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-22 17:58 UTC by Tony
Modified: 2010-06-28 13:47 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-06-28 13:47:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg log from working F10 installation (38.94 KB, text/plain)
2009-07-22 17:58 UTC, Tony
no flags Details
Anaconda dump from preupgrade attempt to install F11 (62.12 KB, text/plain)
2009-07-22 18:00 UTC, Tony
no flags Details
anaconda / kickstart log files (70.00 KB, application/octet-stream)
2009-07-31 20:22 UTC, W Agtail
no flags Details

Description Tony 2009-07-22 17:58:25 UTC
Created attachment 354758 [details]
dmesg log from working F10 installation

Description of problem:

Attempting to upgrade from Fedora 10 to Fedora 11 using preupgrade or local verified DVD media fails at the point of selecting storage.  Problem also occurs with i686 version DVD media.

Version-Release number of selected component (if applicable):
Latest release for Fedora 11 and preupgrade as at the time of writing.

How reproducible:
Either - boot machine with Leonidas release media (X86_64 or i686) in boot drive; attempt preupgrade from Cambridge.

Steps to Reproduce:
1. Boot machine with installation media in drive or reboot once preupgrade download completes.
2. Follow defaults to the point where storage partitioning occurs or to point where kickstart configuration from preupgrade cannot be found
3. Error message stating no drives found shown - no traceback is generated just the error (skipping the kickstart configuration to follow a manual install by choosing cancel gives the same error after accepting all defaults).
  
Actual results:
Error message stating no drives found

Expected results:
Partitions displayed with choice to upgrade existing installation


Additional info:

Machine is based on xfx force7 750a sli motherboard, 4Gb ram, AMD 9650 phenom quad core processor with WD 160Gb Sata drive (holding F10 install) and WD 750Gb Sata drive which has been zeroised via dd if=/dev/zero of=/dev/sdb bs=1M from an F10 tty.

Raid is disabled in the bios. I've tried the dmraid -r /dev/sda -E and dmraid -r /dev/sdb suggestions and recieved reports that there is no raid defined on either disk.

I suspect I need something like an updates.img file on boot but I'm not really sure how to go about finding one or how to use it when I do (I've been trying for several days to find something useful).

Attached are a couple of diagnostic files but if I can supply anything more useful please let me know.

Regards

Comment 1 Tony 2009-07-22 18:00:37 UTC
Created attachment 354759 [details]
Anaconda dump from preupgrade attempt to install F11

Comment 2 David Lehman 2009-07-22 19:56:39 UTC
It looks to me like you have some kernel and/or hardware issues. I see several occurrences of the following sequence of system log entries:

<6>ata2: SATA link up <unknown> (SStatus 103 SControl 310)
<4>ata2.00: qc timeout (cmd 0xec)
<4>ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)


You can verify that the kernel does not see your disks by running either of the following commands from tty2 during F11 installation:

  cat /proc/partitions

  ls /sys/class/block/

Comment 3 Tony 2009-07-22 21:17:30 UTC
It is possible that I have an outstanding bios issue - booting with F10 install media detects both hard drives correctly though.

As requested output from /proc/partitions shows ...

major minor  #blocks  name

   7        0     113664 loop0

Output from /sys/class/block lists a single sr0, eight loop devices and 16 ram devices (I can paste but that appears to confirm that the disks cannot be seen by the kernel).

Is there anything else I can attach that could help?

Regards

Comment 4 W Agtail 2009-07-31 20:19:12 UTC
Hi

I have a similar issue. I used to run Fedora 7 and am currently trying to install Fedora 11 x86_64, either from DVD or PXE.

Kickstart fails with error message "Specified nonexistent disk sda in driverorder command"

ALT F3, shows (see attached storage.log):
storage.log:[2009-07-31 19:55:23,924]    DEBUG: type detected on 'sda' is 'silicon_medley_raid_member'

I have two 160GB disks which are not in any hardware raid setup.
I am able to see disks with fdisk -l from alt-f2 screen.

Please refer to attached bug.tar for various logs from /tmp.

Any ideas?
I just tried rawhide, which failed during network devices, so I guess rawhide is far too early to test?

Regards.

Comment 5 W Agtail 2009-07-31 20:22:23 UTC
Created attachment 355858 [details]
anaconda / kickstart log files

Refer to my comments below. Thanks. This is a tar ball of various anaconda logs in /tmp.

Comment 6 Steve Fraser 2010-01-11 02:30:10 UTC
This may be better suited to a new bug, however I expect the problem to be the same.

Fedora 12 failing to identify SATA devices on NVIDIA XFX 750a motherboard. (2 Western Digital drives in RAID 0).

--snip of dmesg--
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: qc timeout (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata4.00: qc timeout (cmd 0xec)
ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: qc timeout (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: limiting SATA link speed to 1.5 Gbps
ata4.00: qc timeout (cmd 0xec)
ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata4: limiting SATA link speed to 1.5 Gbps
ata2: SATA link up <unknown> (SStatus 103 SControl 310)
ata4: SATA link up <unknown> (SStatus 103 SControl 310)
ata2.00: qc timeout (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata4.00: qc timeout (cmd 0xec)
ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
--snip--

No sign of the drive after boot. Install is currently on an IDE drive (/dev/sda)

# cat /proc/partitions
major minor  #blocks  name

   8        0  160086528 sda
   8        1   93335728 sda1
   8        2    1951897 sda2
   8        3     819200 sda3
   8        4          1 sda4
   8        5   12582912 sda5
   8        6   51387391 sda6

# ls /sys/class/block/
loop0  loop2  loop4  loop6  ram0  ram10  ram12  ram14  ram2  ram4  ram6  ram8  sda   sda2  sda4  sda6
loop1  loop3  loop5  loop7  ram1  ram11  ram13  ram15  ram3  ram5  ram7  ram9  sda1  sda3  sda5  sr0


This exact hardware works fine in Windows XP 32 bit, 64 bit, Windows 7, and worked a while back on Fedora 8.

Please advise if there's anything further I can do to assist.

Comment 7 Joshua 2010-02-03 17:15:11 UTC
My computer with a XFX GeForce 8200 MCP Socket AM2+ Motherboard has been having similar problems, it won't initialize on fedora 11 or 12.

Comment 8 Bug Zapper 2010-04-27 15:51:44 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Bug Zapper 2010-06-28 13:47:11 UTC
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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