Bug 31778
Summary: | SCSI HD geometry not initialized to 'correct' value | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | R P Herrold <herrold> |
Component: | kernel | Assignee: | Doug Ledford <dledford> |
Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 7.1 | CC: | dkl |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-03-30 21:03:08 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
R P Herrold
2001-03-14 15:14:31 UTC
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> To: testers-list 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. |