Executive summary: This is low priority and rare, related to CHS geometry
changes in hard drives previously used in 'other' operating systems
I was installing RH 7.0 (trade show GPL version) to a HP
NetServer 5/100 LC- 100MHz Pentium, 192M ram, Adaptec onboard
SCSI controller (AIC-7xxx type) - Bios id's as "Adaptec
AIC-7770 BIOS V2.12S Release", onboard video, preparatory to
doing upgrade testing.
I grabbed a SCSI-II drive - a Quantum Fireball_TM2110S - a 2 G
drive, which had previously been set in a Mac scsi chain. I
rejumpered to drive number 0, added a SCSI CD at ID 4, and
Completed normally, and I built a boot floppy ... from which I
intended to initially boot on first reboot.
It never reached the floppy.
At the end of the SCSI Bios controller initialization phase,
it stops with the message:
!!! WARNING !!!
A drive larger than 1 gigabyte has been detected with 64 head / 32 sector
partitioning. This drive is not compatible with the 255 head / 63 sector
translation which has been enabled on this adapter. Data could be
corrupted! Please check your system setup!
(They must have had a special on exclaimation points at
Adaptec that week ...)
The controller returns short read errors, regardless of wheter started from
HD or recovery floppy -- fsck trashes drive content as it attempts recovert
-- completely disabling uintil the drive geometry is fixed
Proper solution was to manually go into fdisk expert mode, and change Heads
and Sectors as indicated ...
It is a bug in that then the GUI install offered to 'initialize' the drive,
it did not check for and determine the problem with the drive CHS geometry.
grrr ... I THOUGHT that was the fix -- Xpert - set C and H -- but this did NOT
do it either --- dunno WHAT the correct solution is ...
From testers list ...
Date: Thu, 15 Mar 2001 20:04:01 -0500 (EST)
From: Ward Fenton <email@example.com>
Subject: [testers] qa309 and aic7xxx (atlas 10k firmware fun)
Updated firmware for the drive seems to have solved all issues. Its
interesting to note that with 2.4.2-ac20 and aic7xxx 6.1.7 I was fine with
a seagate cheatah 36lp drive but couldn't save the changes I was making
with fdisk to the quantum drives.
I was unable to change Heads and Sectors to the larger CHS geometry requested by
the controller BIOS message on my office netserver 5/100LC
Note that with Qauntum drives, he too is having fdisk commit changed to hard
drive problems with the Adaptec driver ... common elements -- Adaptec
controller - Qwuantum drives - fdisk
... intesresting -- dunno if it is significant ...
Assigning to an engineer.
Errr...I'm not quite sure what the problem is. In your last post, you said that
a firmware update resolved the problem. Do you consider this issue resolved or
is there still a problem with the Red Hat Installer?
No ... That was Ward's experience (is not he the alternative AIC7xxx developer
from the BSD tree at Adaptec<?>) ...
MY experience is below the lines ot "=============" -- my fault, in being less
than clear. Sorry ...
That is: I am unaware of a BIOS upgrade procedure as Ward outlines, and still
expereince the issue ... My post was to suggest that there may be some
interaction with Quantuum drives, the RH(Linux) variant AIC7xxx driver, and the
AIC-2940 controller series being NOT committing indicated CHS change
information, and yet NOT returning an error code which is being caught ..
So, I 'verify' that the issue still exists ...
Dave, do we have the hardware to reproduce this?
If there is a problem with the Adaptec AIC7xxx driver, then the component should
be changed to the kernel...that's kind of outside the context of the installer.
Frankly, I don't know what is causing this problem. As you said in your first
post, it seems to be a pretty rare problem. Changing component to kernel.
There are two distinct issues here. First, that the aic7xxx driver doesn't
write out the master boot record and partition table on some quantum drives. As
reported in the text of the bug, that was resolved by a firmware update (to the
drive, not the SCSI BIOS or the driver, so it is a bug in the Quantum drives).
So that issue is NOTABUG.
The second issue was related to drive geometry issues and the installer. Drive
geometry is determined by the Adaptec controller BIOS. It is not changeable.
When transferring a drive from another controller to an Adaptec controller,
there is *NO* guarantee that the Adaptec BIOS will be able to read from that
drive. Once you get past the BIOS to a fully booted linux kernel, the kernel
level aic7xxx driver is smart enough to read the existing partition table to see
what the geometry was perviously and use the drive according to that geometry.
So, if the drive isn't a boot drive, then it can typically be transferred,
otherwise it can't (unless the other controller happens to use the same geometry
as the Adaptec controller). This is an issue that would have to be addressed
with Adaptec, there is nothing that can be done short of installing a new BIOS
on the Adaptec controller. The part about the installer then was that the
installer didn't detect and correct this situation. In fact, the installer
*can't* detect and correct this situation. There was a reason that the warning
message from the Adaptec BIOS was displayed so prominently. The BIOS is the
only section of code able to detect this problem properly, and the Adaptec BIOS
doesn't fix it. The only real solution is to zero out the first 1k of the
drive, then install on it from scratch. So, since the installer can't detect
this situation, I'm resolving this as NOTABUG as well.