From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408

Description of problem:
    Observing an install of Red Hat Linux 7.3 on a particular machine, and it
consistently hangs, no matter the mode, including expert and text expert.

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


How reproducible:
Always

Steps to Reproduce:
1. create partitions with 7.0
2. upgrade or install with 7.3
	

Actual Results:  It hangs right after selecting fdisk partitioning, via either
Disk Druid or fdisk.  That is, neither partitioning tool starts; anaconda hangs
first.

Expected Results:  The installer should've accepted the partitions and continued
on with life.

Additional info:

    Red Hat Linux 7.0 installed just fine on various partitions.  For
kicks, I borrowed a Mandrake and SuSE install set, which to my chagrin also
worked.  Red Hat Linux 7.1 and 7.2 also fail.

    If I use VC2 and run fdisk in the shell, it works just fine, although it
complains about partitions not being aligned on cylinder boundaries on hdb.

    The system has two drives, one 30G and one 40G.  The latter, hdb, has
nominal disk geometry which apparently is not matched to the partition table. 
It appears that something in Red Hat 7.1 and later hangs hard in this situation.
 Whether it's anaconda or not, I don't know.  By 'hangs hard' I mean to say that
the system does not respond to C-A-F{1,2,3,4,DEL}.

    There was a suggestion in one bug report that "expert" mode would help, but
that does not seem to be the case.

    I want to upgrade, but I don't want to have to trash the disk.  I have tried
to persuade the BIOS to select a different geometry, to make fdisk happy, to no
avail.  I tried various combinations.  This is the only one which matches the
partitioning:

            expert text nofb hdb=181504,7,63

    The problem persisted.  In tty2, I got the same output as under SuSE 6.4. 
Basically, the physical geometry is what fdisk uses, not the logical geometry
set by the command line.  I tried varying the BIOS definition of the geometry,
but the closest I could come was hdb=45376,28,63.  The BIOS stores the cylinder
count in 16 bits, so any larger cylinder count is truncated.

     I wasn't able to capture the fdisk output directly on floppy, but none of
the partitions overlap each other, and the output looked normal aside from
reporting the logical geometry to match the command line, and still using the
physical geometry to check alignments.

    One of the seemingly more probable scenarios detailed when we used libfdisk
as the partitioning backend the partition tables were being created incorrectly
under some conditions.  And now, with parted, the same conditions aren't
tolerated.  It *seems* like it ought to just warn about the mismatch, since it
has no real impact under Linux.