From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; SunOS 5.6 sun4u)

Description of problem:
The install kernel incorrectly detects an OnTrack style partition table on a
normally partitioned disk (albeit with a large geometry -- CHS=148945/16/63). 
As a result, an OnTrack style partition table is getting written to the disk
during the install, thus making the other partitions on that disk (which contain
user data and are not otherwise touched by the install) invalid and impossible
to recover.

I will attach snippets from dmesg to detail what I'm seeing at the conclusion of
this report.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.  Install RH 7.1 on a host with a (I suspect) large enough disk.  The 7.1
install kernel will write a normal partition table to the disk.
2.  Boot the RH 7.2 install disk on the node.  It will incorrectly determine
that the geometry of the disk, and attempt to interpret an OnTrack partition
table on the disk with a translated geometry.
3.
	

Actual Results:  In our case, the disk was detected with an incorrect partition
table, and a translated geometry, thus rendering the existing data partition on
that disk unreadable.  Moreover, when the install completes, it formats the
first partition as the /boot filesystem (which is what it should be doing).  In
this case, though, the incorrect first partition overlays the initial sectors of
the correct extended partition, ruining the filesystem there.

Expected Results:  The right partition table should have been detected, and
there should be no translated geometry.

Additional info:

This is what I'm seeing when I boot a slightly hacked (for output purposes)
2.4.9-31 kernel on a RH 7.2 box (with the first disk, hde, already munged by the
installer):

hde: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63
hdf: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63
hdg: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63
hdh: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63
hdc: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdc: set_drive_speed_status: error=0xb4
hdc: ATAPI 40X CD-ROM drive, 128kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hde: {PTBL - heads=255} {remap #3} [PTBL] [9345/255/63] hde1 hde2 hde3 hde4
 hdf: {PTBL - heads=16} hdf1
 hdg: {PTBL - heads=16} hdg1 hdg2 hdg3
 hdh: {PTBL - heads=16} hdh1

The first part between curly braces is in msdos_partition(), after it has
attempted to determine the number of heads by reading the existing partition
table.  In later kernels, this section of code is moved to handle_ide_mess().

I see similar output from dmesg on the install kernel, before anything is
written to the disk.

The second part is in ide_xlate_1024(), where I put in a '{remap #n}' wherever
ret is set to something nonzero.

This is what I see whenI boot the same kernel on an identically configured
(hardware-wise) RH 7.1 machine:

hde: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63
hdf: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63
hdg: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63
hdh: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63
hdc: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdc: set_drive_speed_status: error=0xb4
hdc: ATAPI 40X CD-ROM drive, 128kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hde: {PTBL - heads=16} hde1 hde2 < hde5 >
 hdf: {PTBL - heads=16} hdf1
 hdg: {PTBL - heads=16} hdg1 hdg2 < hdg5 hdg6 >
 hdh: {PTBL - heads=16} hdh1

Note:  I am aware of the different partition table on hdg.  This is a result of
an intentional repartitioning of hdg on the RH 7.2 install.  There is no other
repartitioning done in my install.