Bug 56244

Oddly enough, I've downloaded the source:
util-linux-2.11f-11.7.1.src.rpm
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
partitions...

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-
error proof?

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 
that.". Jeez!

*** 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
multiply partitions.

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 
implement"?

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. ***