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):
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.
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.
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: