Bug 28767

I've been able to edit a partition table with partition entries in the wrong
order with fdisk. Its easy to create a partition table in this way with fdisk even.

The interesting part of your report is that fdisk thinks partitions may overlap.
I have not seen this behavior. It would be helpful to have the original
partition table state, and the steps you used to reach the final state. Then I
can reproduce and debug it further.

Originally, hde5 and hde6 were hde8/9 (redhat /home and debian /, respectively), and redhat's /, swap and /usr were 5, 6, and 7 IIRC. I deleted these with 
Disk Druid and created a single large partition in their place, but apparently it decided to put the new partition (first physically) last in the table. Anyway, 
after the reinstall, I tried deleting hde5 and hde6 (big picture: resize hde5), and when I tried creating a new partition in hde5's place, fdisk got confused 
and wanted to start the new partition at cylinder 22 (occupied by hde7.) Entering the correct start cylinder (1800) gives me the overlapping partitions error.

IMHO, Disk Druid should use the first unused partition rather than always putting it at the end, particularly when a extended partition is being replaced. 
Most other operating systems (and apparently most Linux partition editors) don't seem to like illegal partition tables. :)

The current behavior of disk druid is identical to fdisk's (I tried to make it
behave similarly). If you had done the same operations with fdisk it would have
(I have confirmed this) created an out of order sequence. This is because the
logical partitions are just a single linked list of partition tables. If you put
the newly created partition at the start of the chain it would become hda5, and
push the old hda5 into being hda6. This would break anything that depended on
the device name (like /etc/fstab).

After the reinstall, when you deleted hde5 and hde6 after the reinstall, did you
use fdisk?

I want to recreate your steps precisely so I can see if I can make fdisk screw
up. Looks like a fdisk bug possibly.

I first tried cfdisk, which couldn't open the disk at all, then fdisk, which 
could list but not edit the disk.

(OT: why can I change the bug details in some browsers and not in 
others? My Mozilla 0.8 setup must be rather broken. :-/)

The fdisk in the Wovlerine beta was able to handle a partition table in this
state. I have not verified this against cfdisk.

Will assign to that component.

Observed this invalid partition table situation with 7.1, when adding an Linux
partition after an NTFS partition.

disk druid is part of anaconda - adding msf to Cc: list since I know almost
nothing about either DD or fdisk.

Here's the process I used to produce the following invalid partition table:
1. Install Win'98 on my machine
2. use partition magic to resize single partition and create extended
3. Run happily for months
4. Defrag primary partition
5. Use FIPS to resize primary partition, and create another extended partition
6. Boot from 7.1 CD
7. Use Disk Druid to delete FIPS-created partition
8. Create new /, /boot, and swap partitions in the space "formerly" occupied by
the extended partition
9. Complete the 7.1 install, and all looks grand, until I tried to boot the '98
partition.  Windows sees three partitions: the windows primary, the windows
extended, and another extended partition.  Since Windows sees the partition, it
incessantly tries to read it, and fails.  Windows no longer works properly. 
VMWare won't see the partition properly, either.

RH fdisk sees the following:

Disk /dev/hda: 255 heads, 63 sectors, 1467 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       829   6658911    c  Win95 FAT32 (LBA)
/dev/hda2          1340      1467   1028160    c  Win95 FAT32 (LBA)
/dev/hda3           830       836     56227+  83  Linux
/dev/hda4           837      1339   4040347+   5  Extended
/dev/hda5           837       869    265041   82  Linux swap
/dev/hda6           870      1339   3775243+  83  Linux

Partition table entries are not in disk order

I used Partition Magic on this drive, and it identified that the partition type
for the extended partition was wrong.  Apparently since the extended partition
crossed the 1024 cyl boundary, it needed to be of type "ExtendedX" according to
Partition Magic, or type f - Win95 EXT (LBA)

Now that I made that change, Windows boots normally.

Here's the corrected partition table:
Command (m for help): p

Disk /dev/hda: 255 heads, 63 sectors, 1467 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       829   6658911    c  Win95 FAT32 (LBA)
/dev/hda2          1340      1467   1028160    c  Win95 FAT32 (LBA)
/dev/hda3           830       836     56227+  83  Linux
/dev/hda4           837      1339   4040347+   f  Win95 Ext'd (LBA)
/dev/hda5           837       869    265041   82  Linux swap
/dev/hda6           870      1339   3775243+  83  Linux

Partition table entries are not in disk order

Hope this helps.

Regards,
Tom Cooper

OK, if I gather correctly, it sounds like you think Disk Druid needs to simply
make extended partitions with a type of 'f' instead of '5'? That should be
simple for the installer team to get to eventually, and upon resolution should
hopefully allow closing this chain of not-entirely-related bugs.

We can't change the way we handle partition types at this time.  Deferring to a
future release.

parted is actually smart (tm) and does the right thing, so as of 7.2, this
should be doing the right thing.