Red Hat Bugzilla – Bug 56244
fdisk deals with only 16 partitions (IDE disk)
Last modified: 2007-11-30 17:10:30 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
Description of problem:
fdisk -l on an IDE disk shows only 16 partitions (sfdisk -l works Ok).
fdisk says it will delete partitions after 16.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Partition an IDE disk with more than 16 partitions
2. Install util-linux-2.11f-11.7.1
3. Run fdisk [-l] /dev/hdX
4. Compare with sfdisk [-l] /dev/hdX
zu /usr/share/doc/util-linux-2.11f # fdisk -l /dev/hdc
Warning: deleting partitions after 16
Disk /dev/hdc: 128 heads, 63 sectors, 3153 cylinders
Units = cylinders of 8064 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hdc1 1 3153 12712864+ 5 Extended
/dev/hdc5 1 363 1463553 83 Linux
/dev/hdc6 364 726 1463584+ 83 Linux
...(removed lines from here)
/dev/hdc15 1853 1876 96736+ 83 Linux
/dev/hdc16 1877 1912 145120+ 83 Linux
zu /usr/share/doc/util-linux-2.11f # sfdisk -l /dev/hdc
Disk /dev/hdc: 3153 cylinders, 128 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Units = cylinders of 4128768 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/hdc1 0+ 3152 3153- 12712864+ 5 Extended
/dev/hdc2 0 - 0 0 0 Empty
/dev/hdc3 0 - 0 0 0 Empty
/dev/hdc4 0 - 0 0 0 Empty
/dev/hdc5 0+ 362 363- 1463553 83 Linux
/dev/hdc6 363+ 725 363- 1463584+ 83 Linux
...(removed lines from here)
/dev/hdc15 1852+ 1875 24- 96736+ 83 Linux
/dev/hdc16 1876+ 1911 36- 145120+ 83 Linux
/dev/hdc17 1912+ 3152 1241- 5003680+ 83 Linux
zu /usr/share/doc/util-linux-2.11f #
Expected Results: /dev/hdc17 should show up with fdisk too
kernel 2.4.14 + ext3 patch
sfdisk version 3.07 (firstname.lastname@example.org, 990908)
maybe fdisk 'thinks' this is a SCSI disk, so this may be relevant:
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_CD_NO_IDESCSI is not set
advansys module not loaded when test was run
Editing the partition table with fdisk brings the warning:
Warning: deleting partitions after 16
I haven't tried to 'w', but if this warning is correct I suppose it will
lead to loss of data (deleting partitions after 16).
Oddly enough, I've downloaded the source:
installed, recompiled (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)),
and the new fdisk works fine.
...So I've dasm'ed both binaries, and yes, the original from util-linux-2.11f-
11.7.1 is broken: When it compares MAXIMUM_PARTS to print the error message, it
uses 15 instead of 59 (my source defines MAXIMUM_PARTS as 60 in fdisk.h):
from the "broken" fdisk:
0x0804a580 cmp $0xf,%edx
0x0804a583 lea 0x805daa0(%edi),%ebx
0x0804a589 jg 0x0804a530
from the recompile fdisk:
0x0804a7e0 cmp $0x3b,%edx
0x0804a7e3 lea 0x805e080(%edi),%ebx
0x0804a7e9 jg 0x0804a780
Additionaly, the fdisk binary in util-linux-2.11f-12.i386.rpm (from RH7.2) has
the same error.
IF MAXIMUM_PARTS WAS DEFINED AS 16 WHEN THE ORIGINAL BINARIES WERE COMPILED,
THIS IS A BIG PROBLEM (or so I think).
util-linux-2.11f-17.i386.rpm has the same problem
I changed MAXIMUM_PARTS from 60 to 16 because the kernel has a limit of 16
Solution: "Don't make more than 16 partitions"...?
My kernel doesn't know about this limit, since I'm running with 17 partitions
on hdc for quite a while. Wouldn't this limit apply for SCSI only?
I did a bit of research. Basically:
. The absolute limit for IDE devices is 64
. The absolute limit for SCSI devices is 16.
. If you are using the BSD disklabel partition table format, the limit is 8 (16
for OpenBSD), but this is enforced separately in the fdiskbsdlabel code.
And my conclusion, in the "640k should be enough for anyone" vein, is that
anyone who needs even 16 partitions is insane, :) and that leaving the limit at
16 will make sure SCSI works properly and hopefully not inconvenience anybody.
If you can provide good reasons why > 16 partitions is the only way to solve a
problem that applies to a lot of people, we can work some sort of solution out.
That's Ok, I am a bit insane then. I use a lot of IDE partitions in the
company's samba server basically because:
- They used to reside in different (smaller) disks (and may go back). Several
partitions give me more flexibility to move them around using labels.
- I wasn't using ext3 before, so smaller partitions made shorter fscks in the
case of power-downs.
- I'm too lazy to use quotas to limit dept. disk usage
I got worried because previous versions of RH's fdisk did allow more than 16
partitions (I did create my partitions with older RH releases). i.e. it was
working, now it's broken. People using more than 16 (like me) may not notice
the "deleting partitions above 16) warning, and end up losing data.
I also supposed that the source files would produce the same distributed
binaries, and since in the sources the MAXIMUM_PARTS is defined as 60, I
assumed there was something unintentionally wrong.
The solution (for me) is already worked out; everytime I update the util-linux
rpm I get the sources and recompile fdisk separately.
I still think that it's a too dangerous change (even if for a few insane
people) to happen with so little warning. Insane people with more than 16
partitions per disk tend to have a lot of data.
Wouldn't it be more "elegant" to enforce the 16 limit for SCSI only? Why limit
the functionality of a standard (IDE) just to ensure the other (SCSI) is user-
It's a slight pain to figure out whether IDE vs. SCSI vs. neither-of-the-above...
*** Bug 56876 has been marked as a duplicate of this bug. ***
I told you it was dangerous...
Think about this: If you leave the MAXIMUM_PARTS as it's in the source (60),
the potential damage is smaller: People with SCSI disks won't be able to CREATE
partitions above 16, since SCSI does not support them anyway, whereas people
with IDE disks and more than 16 partitions (created with "normal" fdisk
utilities) may LOOSE data which is already in the disk.
*** Bug 67581 has been marked as a duplicate of this bug. ***
Since the kernel allows 64 partitions on IDE drives, wouldn't it be a good idea
to check what kind of device is being fdisked and set MAXIMUM_PARTS accordingly?
Or revert to 60 allowed partitions and let fdisk provide a warning when
partitioning is done on a SCSI device? Or patch the kernel so it allows 64
partitions on SCSI devices? Not sure if that involves a lot of work, but maybe
it's just patching a const (like you did with MAXIMUM_PARTS).
It's quite annoying to be bound to only 16 partitions on a 80GB disk with
multiple (test) installations, including some other OSes. To install 7.3 I had to
move all this data around and put some partitions together. Sure, one could patch
the installation CD, but that is a lot of effort to circumvent a restriction
that is not really necessary (IMHO:).
Sorry for the rant, but I thought if more people would express their
"discomfort" you might actually reverse this patch :-).
None of your suggestions are practical to implement.
'Solution: "Don't make more than 16 partitions"...?' (from 2001-12-28 12:06:26
above) isn't practical either, if one needs more than 16 partitions. Neither
is: "If you have more than 16 partitions, find a distro that supports it, ours
don't, because there is no practical solution for this. IDE supports 64
partitions, but it was an error from someone else. It was only supposed to
support 16, which is enough for anyone but insane people, so we just corrected
*** Bug 74762 has been marked as a duplicate of this bug. ***
This is nuts. The kernel supports 63 partitions (on IDE) just fine so user mode
tools should deal with it, sfdisk does.
On large disk systems supporting lots of partitions are very useful, especially
on multi-boot systems (e.g. RH 7.2, RH7.3, Windoz ugh). I have 22 on my 40Gb
disk. I use partitions for:
- multi-boot (multi-os, multi-os versions)
- separate data so it can have different backup cycles
- separate directories to limit damage when something goes tries to fill disk
What's the big deal? Testing different filesystems is another reason to
I just left Mandrake because I found it too buggy for my tastes--don't send me
back for such a silly limitation. What is the problem with SCSI and 16
partitions? Does it have a bad failure mode or something? Won't it just
complain when you try to add number 17?
At least deal with a disk that already has >16 partitions on it since it must be
supported (and IDE) in that case. Report all partitions.
SCSI only supports 16 partitions, so although IDE supports more, fdisk has
this silly limit.
Hey, my floppy disk only supports 1.44MB, why then fdisk allows partitions
bigger than that?
If someone has a HUGE disk, with say, 25 partitions, and try to add some more
on available space with fdisk, he'll have all his partitions above 16
DELETED!! He's only protected by a warning. SOOOO, why not do the opposite:
Set MAXIMUM_PARTS to 64, and whenever one adds partitions above 16, you
warn: "If this is a SCSI disc, that won't work". Is that "not practical to
If 16 is the "one true limit", then why does sfdisk allow for more ?
Why does the kernel allow for more ?
Why does anaconda ( disk druid ) allow for more ?
Fix them or fix fdisk !
This was marked as "WONT FIX".
That's Ok, I don't care anymore. I'm going Debian...
*** Bug 137666 has been marked as a duplicate of this bug. ***