Bug 200162 - Anaconda fails with VT6420 SATA controller
Anaconda fails with VT6420 SATA controller
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Peter Jones
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2006-07-25 16:31 EDT by Peter TB Brett
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-27 17:01:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg output (16.91 KB, text/plain)
2006-07-25 16:32 EDT, Peter TB Brett
no flags Details
lspci output (1.95 KB, text/plain)
2006-07-25 16:33 EDT, Peter TB Brett
no flags Details

  None (edit)
Description Peter TB Brett 2006-07-25 16:31:21 EDT
Description of problem:

Anaconda as distributed with FC5 has problems with VT6420 SATA controller on 
both x86-64 and i386.

How reproducible:

Start FC5 installation process.  At the stage where hard disks are detected 
before partitioning, Anaconda fails to detects my two SATA drives 
(ST3200826AS) separately, but shows a single device /dev/mapper/via_chghhejjca

Anaconda repeatedly shows the message:

  Invalid partition table on /dev/mapper/via_chghhejjca -- wrong 
  signature 2150

Switching to a virtual console to view dmesg output shows that the kernel has 
detected the controller and hard drives correctly, and that the partition 
table has been read and /dev nodes assigned for the partitions.

Finally, anaconda fails complaining that no suitable medium exists for 
installation, and reboots the system.

Steps to Reproduce:
1. Boot from FC5 installation CD
2. Wait

Additional info:

dmesg and lspci output from FC4 running on the same hardware are attached 
(kernel 2.6.17-1.2142_FC4 x86_64).
Comment 1 Peter TB Brett 2006-07-25 16:32:32 EDT
Created attachment 133019 [details]
dmesg output
Comment 2 Peter TB Brett 2006-07-25 16:33:12 EDT
Created attachment 133020 [details]
lspci output
Comment 3 Jeremy Katz 2006-07-25 16:36:53 EDT
Does booting with 'linux nodmraid' help?
Comment 4 Peter TB Brett 2006-07-26 01:10:00 EDT
Works perfectly -- thank you very much for your (extraordinarily) prompt 

Can I please suggest that this is either fixed, or the workaround added to the 
release notes in the next release?
Comment 5 Peter Jones 2006-07-27 17:01:59 EDT
You've set this drive up as a RAID in your BIOS, and anaconda is reading that
data and behaving accordingly.  The RAID metadata needs to be removed in BIOS
prior to installation if you don't want to use it.
Comment 6 Peter TB Brett 2006-07-27 18:14:48 EDT
The VT6420 has two mutually exclusive operating modes: RAID controller and  
simple SATA controller.  These modes are switchable in my BIOS.

When I initially installed the system, I configured the drives as a RAID 
array. However, when I tried to install with FC4, I was forced to reconfigure 
them into simple SATA mode because FC4 had no support for the VT6420 in RAID 
mode -- only the Windows XP drivers supported it.

Reading documentation, it seems to me that the observed failure arises from 
having RAID disabled in the BIOS while dmraid (correctly) detects stale 
metadata, leading to anaconda trying to read from a non-existent array.

Is there anyway that the installation system could be made to handle this 
situation without crashing with obscure error messages?

Request reopen (I'll resubmit a slightly different report if you like).

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