Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 161567 - parted/libparted recognizes only 128 scsi disks
Summary: parted/libparted recognizes only 128 scsi disks
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: parted
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: David Cantrell
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-24 15:10 UTC by Lee Schermerhorn
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version: parted-1.6.19-4.EL
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-09-13 18:28:46 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Lee Schermerhorn 2005-06-24 15:10:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4

Description of problem:
libparted [linux.c:_device_probe_type()] recognizes scsi disks via the device major number.  linux.c contains a copy of scsi disk major # definitions lifted from some antique version of <linux/majors.h>.  As a result, any scsi disk with a major # in SCSI_DISKi_MAJOR, for i=8..15 will not be recognized as a scsi disk.

Symptoms:  when labeling/partitioning a disk with one of the unrecognized major numbers, parted/partprobe will not commit the changes to the os.  No kobj will be registered, no hotplug events will be generated, no device special files will be created.  Thus, it is necessary to reboot the system to see partitions on any disk after the first 128 scsi disks discovered.  [Booting a system with > 128 disks can be painful :-(].

Adding SCSI_DISKi_MAJOR, i=8..15 and updating the SCSI_BLK_MAJOR macro to check for the additional majors allows parted/partprobe to support up to 256 disks.  Not a very satisfying solution as the sd* namespace supports ~18000 disks.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. boot a configuration with >128 scsi disks
2. use parted to label a disk with major # >= 128 [SCSI_DISK8_MAJOR]--e.g., sddy is the first one to fail.  
3. Note that no /sys/block/sddy/sddyN files are created and no /dev/sddyN device special files are created.  You can also instrument /sbin/hotplug [e.g., 

Actual Results:  Note that no /sys/block/sddy/sddyN files are created and no /dev/sddyN device special files are created.  You can also instrument /sbin/hotplug [e.g., add a script to /etc/hotplug.d/default to log the ACTION, SEQNUM, DEVPATH environment variables to syslog] to see that no hotplug events are generated for disks >= sddy.  Reboot and the /sys/block/... entry and the /dev dsf will appear.

Expected Results:  parted should have issued BLKPG/BLKPG_ADD_PARTITION ioctl() to update the kernel's knowledge of the new partition[s].  This will cause a kobj to be registered [/sys/block/... entry] and a hotplug event to be generated [for udev to consume].  /sys/block/... entry and /dev/... dsf should be created w/o reboot.

Additional info:

Similar 128 disk limits exist in other tools [e.g., sg-utils]--apparently hold overs from 2.4.x.  I will enter a separate boog for each of these that I encounter.  However, this does suggest the need for a more robust method of determining device types, limits on same.

Comment 1 David Cantrell 2006-09-13 18:28:46 UTC
This problem was addressed in the parted update included with the RHEL4 U4
quarterly update.  The notice is:

RHBA-2006:0384 - parted bug fix update

And the parted package version and release is:


If you have an RHN account, you can view the advisory here:

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