Bug 234170

Summary: udev doesn't create block device for major 68 minor 0 as it forces the name to /dev/capi20
Product: Red Hat Enterprise Linux 4 Reporter: Simone Gotti <simone.gotti>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.4CC: andriusb, coughlan, 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: 2007-06-05 22:27:22 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:

Description Simone Gotti 2007-03-27 15:36:04 UTC 
Description of problem:

I cannot find a similar issue on bugzilla. Perhaps it's related to bug #167291.
Sorry if it's duplicated.

On a system with RHEL4-U4 and a lot of scsi devices the block device /dev/sdbm
that has major 68 and minor 0 isn't created (noticed because multipath -l
reports only 3 paths instead of 4). Looking at /etc/udev/rules.d/50-udev.rules
this major is forced to be called capi20:

SYSFS{dev}="68:0",              NAME="capi20"

[root@itradedb03c ~]# udevinfo -q all -p /block/sdbm
P: /block/sdbm
N: capi20
T: b
M: 060660
S:
O: root
G: uucp
F: /etc/udev/rules.d/50-udev.rules
L: 67
U: 2834
R: 0

Removing this line fixed it.

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

udev-039-10.15.EL4

How reproducible:

The system was just installed didn't rebooted. But I think it'll always happen.
  
Actual results:

/dev/sdbm (the block device that has major 68 and minor 0 isn't created because
overrided by /dev/capi20) 

Expected results:

/dev/sdbm created.
Comment 2 RHEL Program Management 2007-05-18 16:25:20 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 3 Andrius Benokraitis 2007-06-05 22:27:22 UTC 
Simone, it looks like IBM has already found this issue and is working to resolve
this for RHEL 4.6.

*** This bug has been marked as a duplicate of 202792 ***