How can static names be assigned for SCSI devices using udev in Red Hat Enterprise Linux 5?

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux 5
  • udev
  • FC and SCSI storage device

Issue

  • How can I assign static names for SCSI devices using udev in Red Hat Enterprise Linux 5?

Resolution

The udev rules in this article will only work on Red Hat Enterprise Linux 5. The udev rule syntax has changed slightly between the versions of udev on Red Hat Enterprise Linux 5.

  1. The first step is to acquire the unique identifier of the SCSI device. To get the unique identifier of say, /dev/sdc, run this command1:

    # /sbin/scsi_id -g -u -s /block/sdc                ; for disks
# /sbin/scsi_id -g -u -s /class/scsi_tape/nst0     ; for tapes
    • The output will look something like the following:
    [root@rhel5 rules.d]# /sbin/scsi_id -g -u -s /block/sdc
3600a0b800013275100000015427b625e

[root@rhel5 rules.d]# /sbin/scsi_id -g -u -s /class/scsi_tape/nst0
SHP_C7438A_HU110180G4

    • The scsi_id command issues a SCSI INQUIRY command to the device to access the vital product data (VPD) page 0x83 data, which contains, amongst other information, the device World Wide IDentifier (WWID). If page 0x83 does not exist on the device then page 0x80 data is used which contains the unit serial number. Because the unit serial number may not be unique across vendors, other information from the standard inquiry page are utilized to create a unique identifier.

    • The result of the scsi_id command (the long string of characters) is the unique identifier (WWID or serial number based) of the device that is currently mapped to /dev/sdc (/sys/block/sdc). This unique identifier will be the same for each path to the device and for each partition on the device. The unique identifier will not change if other devices are added to or removed from the system. However the mapping of the device to /dev/sdc could change. This is why there is a need to create a static device name. The unique identifier is what the udev device names will be keyed off of.

  2. Create the /etc/udev/rules.d/20-names.rules file.

    a) Rules can be added for creating a persistent symbolic link to the device. Within this file, the naming rule will be added. Rules will have the following format:

    KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="{UniqueIdentifier}",
SYMLINK+="devicename%n"
    • This will cause the system to check all SCSI devices which match /dev/sd* and to be checked for the given unique identifier. When it finds a matching device, it will create a device node named /dev/devicename. If there are any partitions on the device they will created as /dev/devicename1 for the first partition, /dev/devicename2 for the second partition, and so on. Now to write the actual rule. Replace the strings {UniqueIdentifier} and devicename with the actual unique identifier string retrieved above and the desired name for the device. In our example, the rule would look as follows:
    KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="3600a0b800013275100000015427b625e",
SYMLINK+="mydevice%n"
    • This rule creates the symbolic link /dev/mydevice for the SCSI device with a unique identifier matching 3600a0b800013275100000015427b625e. Any partitions on this device will be assigned the device names /dev/mydevice1, /dev/mydevice2 etc. This results in an special device file entry of:
    lrwxrwxrwx 1 root root      4 Feb  7 14:08 /dev/mydevice -> sdc

    b) Rules can be added for creating a persistent alternate device name for the device. Within this file, the naming rule will be added. Rules will have the following format:

    KERNEL=="nst[0-9]*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u", RESULT=="{UniqueIdentifier}",
NAME="rmt0"
    • This will cause the system to check all SCSI devices which match /dev/nst* and to be checked for the given unique identifier. When it finds a matching device, it will create a device node named /dev/rmt0. This results in a special device file entries of the following for the original and new, persistent, device name:
    crw-rw ---- 1 root disk 9, 128 Feb 7 14:08 /dev/nst0  
crw-rw ---- 1 root disk 9, 128 Feb 7 14:07 /dev/rmt0
    • In this case, independent of what the nst* name the device has, the rmt0 will always be associated with the device with the unique identifier "SHP_C7438A_HU110180G4".

  3. To test the rule, use the udevtest command like so:

    [root@rhel5 rules.d]# udevtest /block/sdc | grep mydevice
udev_rules_get_name: add symlink 'mydevice'
udev_node_add: creating symlink '/dev/mydevice' to 'sdc'
    • If /dev/sdc has partitions on it, run this command to test a device will be created for /dev/sdc1:
    [root@rhel5 rules.d]# udevtest /block/sdc/sdc1 | grep mydevice
udev_rules_get_name: add symlink 'mydevice1'
udev_node_add: creating symlink '/dev/mydevice1' to 'sdc1'
    • Note: If an old udev package is installed, the symbolic link for each partition might not be created. In such a case, it should be added one more line which uses "all_partitions" option to the rule file:
    KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="3600a0b800013275100000015427b625e",
SYMLINK{all_partitions}+="mydevice%n"

  4. Finally, echo change into the underlying device's uevent directory to have udev create the device(s):

    [root@rhel5 rules.d]# echo change > /sys/block/sdc/uevent
[root@rhel5 rules.d]# echo change > /sys/block/sdc/sdc1/uevent
[root@rhel5 rules.d]# echo change > /sys/class/scsi_tape/nst0/uevent

Verify that the device(s) /dev/mydevice* have been created and are symbolic links to to /dev/sdc*.

As long as the device with the unique identifier 3600a0b800013275100000015427b625e is attached/visible to Red Hat Enterprise Linux, it will always be statically bound to the name /dev/mydevice by udev.

Comments

Referrence Links:

1

The above command " -u -s /block/sdc" : generates a unique id for the /block/sdc (/dev/sdc). The mount point must not be included. So, use /block/sdc, not /sys/block/sdc.

Diagnostic Steps

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.