Red Hat Bugzilla – Bug 31778
SCSI HD geometry not initialized to 'correct' value
Last modified: 2005-10-31 17:00:50 EST
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 installed. 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 <ward@amazingmedia.com> To: testers-list@redhat.com Subject: [testers] qa309 and aic7xxx (atlas 10k firmware fun) <snip> 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.