Bug 28767 - Disk druid can create invalid partition tables.
Disk druid can create invalid partition tables.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-21 22:44 EST by Ed McKenzie
Modified: 2007-04-18 12:31 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-21 10:33:10 EST
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 Ed McKenzie 2001-02-21 22:44:05 EST
During a reinstall, I deleted some adjacent logical partitions to create a
single one for / on hde7 (I didn't want to delete /home on hde5, as
important data was on it.) Disk Druid was used to edit the disk, and now
the disk layout looks like this:

[root@eem12 eem12]# /sbin/fdisk -l /dev/hde
kernel version 132096

Disk /dev/hde: 64 heads, 63 sectors, 6577 cylinders
Units = cylinders of 4032 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hde1   *         1        21     42304+  83  Linux
/dev/hde2            22      6577  13216896    5  Extended
/dev/hde5          1800      5124   6703168+  83  Linux
/dev/hde6          5125      6577   2929216+  83  Linux
/dev/hde7            22      1799   3584385   83  Linux

Partition table entries are not in disk order
[root@eem12 eem12]# 

... which cfdisk won't even open, and fdisk will list (but refuses to edit.
It seems to think the partitions overlap, when they don't.) Linux obviously
reads it fine, but that doesn't mean it's a valid partition table.
Comment 1 Michael Fulbright 2001-02-22 12:12:13 EST
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.
Comment 2 Ed McKenzie 2001-02-22 15:07:24 EST
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. :)
Comment 3 Michael Fulbright 2001-02-23 11:29:24 EST
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.
Comment 4 Ed McKenzie 2001-02-23 11:52:34 EST
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. :-/)
Comment 5 Michael Fulbright 2001-03-20 14:20:27 EST
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.
Comment 6 bcling 2001-05-14 13:08:52 EDT
Observed this invalid partition table situation with 7.1, when adding an Linux
partition after an NTFS partition.
Comment 7 Elliot Lee 2001-07-17 19:36:30 EDT
disk druid is part of anaconda - adding msf to Cc: list since I know almost
nothing about either DD or fdisk.
Comment 8 tom_cooper 2001-07-18 11:06:07 EDT
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


Comment 9 tom_cooper 2001-07-19 15:11:11 EDT
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
Comment 10 Elliot Lee 2001-08-26 17:31:36 EDT
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.
Comment 11 Brent Fox 2001-08-29 18:09:22 EDT
We can't change the way we handle partition types at this time.  Deferring to a
future release.
Comment 12 Jeremy Katz 2002-03-26 19:07:17 EST
parted is actually smart (tm) and does the right thing, so as of 7.2, this
should be doing the right thing.

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