Bug 64388 - Incorrect partition table probe with install kernel
Incorrect partition table probe with install kernel
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-03 10:01 EDT by Gary L. Jackson
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gary L. Jackson 2002-05-03 10:01:20 EDT
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.
Comment 1 Gary L. Jackson 2002-05-03 14:09:56 EDT
I forgot to mention this before, but I am booting with the latest install image.
Comment 2 Bugzilla owner 2004-09-30 11:39:33 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.