Red Hat Bugzilla – Bug 116289
BLKPG_ADD_PARTITION op of BLKPG ioctl doesn't let you add partitions >= 1TB
Last modified: 2007-11-30 17:07:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera
Description of problem:
When using parted to create any partition of size greater than or
equal to 1TB, I get an error message stating that there was an error
informing the kernel about the changes. After stepping through the
process with gdb, I can see that parted is not the faulty one here,
as it's passing the correct values to the kernel, using the
BLKPG_ADD_PARTITION op of the BLKPG ioctl.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. find a terabyte server to play with (this is the hardest part)
2. run "parted /dev/sda mkpart primary 0 1048576"
3. watch the fireworks
Actual Results: "Error informing kernal about changes made to
The partition is written to disk, but the kernel doesn't know about
it until a reboot.
Expected Results: No error message, and the partition to be
This is especially debilitating when installing RHEL (or anything
that uses anaconda) on a terabyte server. If I create any partitions
over 1TB, the install crashes. The workaround I've been using is to
not create the partition during the install, and use fdisk
RHEL3 is limited to 1Tb for other reasons anyway (with the exception
of some select and specially tested and certified setups, which
includes the software used to access it)
Created attachment 97838 [details]
patch to fix TB limit for BLKPG_ADD_PARTITION ioctl in 2.4 kernels
Looking at drivers/block/blkpg.c:66, at the add_partition function, I notice
that it stuffs the sector count from ppstart and pplength, signed long longs
(which are correct), to a pstart and plength, signed longs, giving it a limit
of 1TB (2^31 * 512). Looking at include/linux/genhd.h:45, at struct partition,
is should be using an unsigned long, which gives the correct limit of 2TB (2^32
* 512). The check for equality between the long long and the long is what's
causing the false negatives. I've verified that changing pstart and plength to
unsigned longs fixes the issue, and I've attached the patch. This problem/fix
are not restricted to RHEL, so I've made the diff against the standard kernel
source, as to be more universal. The same issue is in the 2.6 kernels.
I have gotten the same errors as was originally reported
but I am trying to reinstall and I am not trying to create
any partitions even near 1TB. The system does however
have +1TB partitions on disks other than the system disk.
I want to leave these partitions completely alone. Would
the bug and fix apply to this situation. Please advise.
*** Bug 121462 has been marked as a duplicate of this bug. ***
*** Bug 121710 has been marked as a duplicate of this bug. ***
*** Bug 123094 has been marked as a duplicate of this bug. ***
*** Bug 122445 has been marked as a duplicate of this bug. ***
This will be fixed in RHEL4.
Reopened for RHEL3 update issue
Tested patch, parted still reported invalid information. Additional
I ran into this as well. Make sure to dd over the MBR with zeros,
then run parted to create the new label ("parted /dev/device mklabel
msdos"), and then try to run parted. If I tried this without first
blanking the MBR after attempting with the broken SYSCTL, I received
an error message.
Added parted Bugzilla entry #135468.
Meanwhile, how do those of us trying to use RHEL3 install on systems
with existing 4TB or larger filesystems? I just spent 3 hours trying
to install RHEL 3AS update 4 on a system with multiple 1.4TB
filesystems, to no avail.
This is a serious problem. Why hasn't it been addressed? Are we not
supposed expected install RHEL 3AS on file servers?
*** Bug 144990 has been marked as a duplicate of this bug. ***
A fix for this problem has just been committed to the RHEL3 U5
patch pool this evening (in kernel version 2.4.21-27.17.EL).
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
(In reply to comment #22)
> An advisory has been issued which should help the problem
> described in this bug report. This report is therefore being
> closed with a resolution of ERRATA. For more information
> on the solution and/or where to find the updated files,
> please follow the link below. You may reopen this bug report
> if the solution does not work for you.
Argh, was under the impression the recent kernel update would allow to lift the
2TB limit, which isn't an issue using jfs. IIRC ext3 is limited to 1.3TB on RHEL
3, even if you can create a 2TB fs, be warned it takes ages.
Allowing larger blockdevices (16TB should be fine) and more SCSI sg* devices
then only 256 would be most welcome!
Michael, the 2-TB limit will never be raised in RHEL3 because of kABI
restrictions. I believe RHEL4 does not have this limit.
Enrie, yep you are quite right, after looking a bit more about the issue, it
doesn't work out on kernel 2.4, already test installed 4.0. Good job, my 3.0 .ks
files worked with very little modifycation.;)
But alas, I'll go nowhere with 4.0, until it's in this .pdf under
In addition, still grievously missing an online extendable FS in the supported
kernel. IIRC there was a project to add online resize to ext3, sounded promising
from the mailing-list, but never found the time to test it out. Jfs seems to
have improved greatly in RHEL 3 unsupported package.
Glad to read you extended RHEL 3 support until 2010.;)