Bug 116289
| Summary: | BLKPG_ADD_PARTITION op of BLKPG ioctl doesn't let you add partitions >= 1TB | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Robin Battey <zanfur> | ||||
| Component: | kernel | Assignee: | Peter Martuccelli <peterm> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3.0 | CC: | cnguyen.ext, jkeating, lance, me, michael, petrides, riel, root, steve_chaffee, tao | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-05-18 13:27:19 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 103541, 116286, 121609, 132991 | ||||||
| Attachments: |
|
||||||
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 investigation required. 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. http://rhn.redhat.com/errata/RHSA-2005-294.html (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. > > http://rhn.redhat.com/errata/RHSA-2005-294.html 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 server+client+tape drives: ftp://ftp.legato.com/legato/scg/legato_scg.pdf 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. BTW Glad to read you extended RHEL 3 support until 2010.;) |
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 7.23 [en] 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): How reproducible: Always 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 /dev/sda. ..." 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 available immediately. Additional info: 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 afterwards.