Bug 714951

Summary:	udev's path_id does not handle isci managed devices
Product:	Red Hat Enterprise Linux 6	Reporter:	Przemyslaw Hawrylewicz-Czarnowski <przemyslaw.hawrylewicz.czarnowski>
Component:	udev	Assignee:	Harald Hoyer <harald>
Status:	CLOSED ERRATA	QA Contact:	qe-baseos-daemons
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.1	CC:	azelinka, ed.ciechanowski, jscotka, krzysztof.wojcik, pknirsch, ykawada
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Prior to this update, the path_id utility did not create symbolic links for iSCSI (Internet SCSI) devices. As a consequence, udev did not create a symbolic link in the /dev/disk/by-path/ directory and the device could not be accessed by this path. This bug has been fixed, udev now follows the naming scheme of its upstream version 171, and symbolic links for iSCSI devices are now created in the following format: "ip-[address]:[port]-iscsi-[target]-[lun]". In this format, [lun] represents the logical unit number of the device. Lun numbers < 256 are displayed as "lun-x". Lun numbers >= 256 use the lun number format previously used in fibre channel by-path links, 0xabcd012300000000. This lun numbering scheme is implemented for sas, fibre channel, iscsi.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-12-06 16:27:10 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Przemyslaw Hawrylewicz-Czarnowski 2011-06-21 12:07:21 UTC

Description of problem:
/dev/disk/path-id/ links for isci managed devices does not exist. Problem is caused by udev's internal utility - path_id which is responsible for generating names of such links.
Starting from version 143 path_id is now a C program instead of previous shell script, and that rework spoiled that util - it stopped working.
Version 168 corrects this problem and path_id creates names for links again.
Quick look at changes revealed that path_id part responsible for sas devices has been reworked in commit c122b6fadfad94fc66c89390ac2354418a45ded7.

Version-Release number of selected component (if applicable):
versions 143-167 of udev does not handle isci sas devices correctly.

How reproducible:
always

Steps to Reproduce:
1. attach device to isci controller
2a. go to /dev/disk/path-id
2b. use /lib/udev/path_id <DEV-PATH> eg for disk in slot #0 of isci host:
/lib/udev/path_id /devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/0000:03:00.0/host6/port-6:0/end_device-6:0/target6:0:0/6:0:0:0/block/sdX
 
Actual results:
path_id does not show any string and exits with code 1.

Expected results:
show sth like:
ID_PATH=pci-0000:03:00.0-sas-0x<SAS-ADDRESS>-lun-0
exit code == 0

Comment 4 Harald Hoyer 2011-07-25 14:28:51 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
path_id did not create a symbolic link for SAS devices without enclosure.
The udev update now follows the naming scheme of the upstream udev version 171.
For iSCSI devices path_id now creates a symbolic link, which has the form ip-<addr>:<port>-iscsi-<target>-<lun>".

Lun numbers < 256 are displayed as "lun-x".  Lun numbers >= 256 use the lun number format previously used in fibre channel by-path links, 0xabcd012300000000. This lun numbering scheme is implemented for sas, fibre channel, iscsi.

Comment 6 Harald Hoyer 2011-08-04 08:23:13 UTC

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,5 +1,4 @@
-path_id did not create a symbolic link for SAS devices without enclosure.
-The udev update now follows the naming scheme of the upstream udev version 171.
-For iSCSI devices path_id now creates a symbolic link, which has the form ip-<addr>:<port>-iscsi-<target>-<lun>".
+path_id did not create a symbolic link for iSCSI devices.
+For iSCSI devices path_id now creates a symbolic link, which follows the naming scheme of the upstream udev version 171 and has the form ip-<addr>:<port>-iscsi-<target>-<lun>".
 
 Lun numbers < 256 are displayed as "lun-x".  Lun numbers >= 256 use the lun number format previously used in fibre channel by-path links, 0xabcd012300000000. This lun numbering scheme is implemented for sas, fibre channel, iscsi.

Comment 7 Tomas Capek 2011-08-08 09:43:56 UTC

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,4 +1,7 @@
-path_id did not create a symbolic link for iSCSI devices.
-For iSCSI devices path_id now creates a symbolic link, which follows the naming scheme of the upstream udev version 171 and has the form ip-<addr>:<port>-iscsi-<target>-<lun>".
+Prior to this update, the path_id utility did not create symbolic links for iSCSI (Internet SCSI) devices. As a consequence, udev did not create a symbolic link in the /dev/disk/by-path/ directory and the device could not be accessed by this path. This bug has been fixed, udev now follows the naming scheme of its upstream version 171, and symbolic links for iSCSI devices are now created in the following format: "ip-[address]:[port]-iscsi-[target]-[lun]". In this format, [lun] represents the logical unit number of the device.
+
+
+
+
 
 Lun numbers < 256 are displayed as "lun-x".  Lun numbers >= 256 use the lun number format previously used in fibre channel by-path links, 0xabcd012300000000. This lun numbering scheme is implemented for sas, fibre channel, iscsi.

Comment 9 errata-xmlrpc 2011-12-06 16:27:10 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1649.html