Description of Problem:
Installer when I selected upgrade and pressed next broaght up a dialob box
informing error in hda /b partitioan tables. According to message prompt
partitition table indicates partitions do not end on cylinder boundaries.
Said to to specifiy drive geomety at boot time for installer and worked
through that process with redhat technicion and same problem. hence this
bug report. The system has two physical drives HDA and HDB HDA is a
windows 95 drive and HDB is a 15gb drive divided equally between windows 95
and Linuxf file systems. According to hdparm under redhat 7.0
hda=8306,15,63 hdb=16383,16,63. I initially installed linux at 6.2 and
upgraded previously to 7.0 without incident.
Steps to Reproduce:
1. this problem shows up when you at the screen 4-4 on page 44 of the x86
installation guide and you select upgrade and press the next button.
I'm stuck like a rat!
I am the tech who helped the gentleman.
I had a similar call earlier in the week, so I suspect he is not the only one to
have this problem. The pther person also had two disks and hda had Windows while
hdb had Linux 7.0...
Let me know if you need more info from me...
I too seem to be experiencing this problem. I have two 36GB hard disks running
through an AMI MegaRAID Express 500 controller. When I try to do a fresh 7.1
install, I get a dialogue warning 'error in partition tables'. A fresh 7.0-
respin installed fine previously. Please help!
Did either of you install any of the public betas for 7.1?
One option, although not attractive if you have valuable data on your disk, is
to wipe all the partitions off the drive with something like fdisk or partition
magic, and then do the installation.
Is it possible that there is a problem with the cylinder check? I had the
gentleman put in his disk parameters and it refused to work...
According to the release note it says:
"Disk Druid now detects partition table inconsistencies, such as partitions that
do not end on cylinder boundaries. This can be caused if the geometry of a hard
disk drive is detected differently than when the drive was originally
partitioned. In these cases, we recommend that you use the fdisk program to more
closely inspect these inconsistencies, or choose to skip the drive entirely. "
Is there information that can be gleened from fdisk that will eanable him to
I also had similar difficulties installing RH 7.1. Installation program always corrupted partition tables. Only reason for this I have found was overclocking.
After I stopped overclocking cpu and fixing (cleaning) partition tables the installation process worked fine and partitions were ok. It seems to be that RH
7.1 doesn't tolerate any overclocking because when I overclocked the cpu again after succesfull installation the partition tables were messed up after few
minutes uptime. Again installation program worked fine without overclocking and now RH 7.1 runs fine. No overclocking anymore!
I hope that this information helps someone.
An email received from Phil Cobbin:
I ain't thrilled with your suggested on bug # 40325. Who you kiddin,
wipe out over 20 gb of data....dream on. My system works fine on 7.0
and this sounds like anaconda was not bombproofed to handle multipe
physical drives, let alone mixed systems. Redhat is not going to make
much of a dent on microsloth sites if you guys keep this up. I haven't
heard crap from you people. Is redhat going to seriously work to fix
the problem or do I have to start filing complaints with the federal
If your not going to fix the problem please advise whether or not the
sources shipped on the cd are real for purposes of building a 2.4 kernal
In my previous post I said that wiping the drive and starting over was *not
attractive* if you have a drive that you can't afford to wipe. So, in your
case, it's not a good option, but it is an option nontheless.
Also, you say that you "haven't heard crap" from us, but you didn't answer my
question from 2001-05-14, which was this: Did you ever install any of the
public betas for Red Hat Linux 7.1? The way that the kernel handled drive
geometry and partition tables changed between the betas and the final release,
so we have seen this issue with systems that tried to upgrade from, say, public
beta 1 (Fisher) to final (Seawolf).
Try booting with the 'linux expert' command line option and see if this fixes
the problem. Somehow, your existing partition table got messed up, and the 2.4
kernel is complaining that the partition table is inconsistent. Using expert
mode will tell the kernel to ignore the error.