Find the answer to your Linux question:
Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    [solved] udev mapping fails for disk with no serial number

    Having spent several hours reading up on this and making little progress I would be most grateful to anyone who can offer insight.

    I have a number of SATA disks attached to a motherboard and would like them to be designated sda, sdb... in line with the board's silkscreen designation SATA1, SATA2... etc. udev sounds (correct me if this assumption is invalid) like the perfect tool to accomplish such a mapping, but instead I've wandered into a thicket of confusion.

    The first problem is that udevadm info does not yield a disk's serial number as an attribute as it is so often expected to do in pretty much every piece of documentation Google offers. ENV{ID_SERIAL} or ENV{ID_SERIAL_SHORT} is a known workaround, but using this fails to match unless the rules file has a very high number. And from what I can see in the existing rules files this kind of mapping should be done as early as possible so that subsequent work e.g. making disk/by-id links, will point to the correct sd* files.

    Two questions have come out of this:
    1 - Why does udevadm info refuse to present the serial number of a SATA disk (I've tried an SSD and an HD on every SATA port on the board) as an attribute available to udev rules through ATTR{}, but hdparm -I can always display the serial number, and so can udevadm through ENV{ID_SERIAL[_SHORT]} but only once the system is fully booted?

    2 - How and when does ENV{ID_SERIAL[_SHORT]} become populated? It's not available in early (low numbered) rules files but is in late (high numbered) rules files.

    If anyone knows how to get access to the serial number through ENV{} earlier, or how to get it into ATTR{} at all, that would be very helpful. This is on Slackware 13.37. Thanks!
    Last edited by slackuser780; 07-13-2012 at 02:52 AM.

  2. #2
    While I can't offer an explanation for ID_SERIAL and ID_SERIAL_SHORT not being available through ATTR{}, I now understand that it is possible to get at these values through ENV{} earlier than the standard rules allow. As udev documentation is as sparse as it is distributed, hopefully this will help someone else in the future.

    To remap SATA disks by serial number:

    1. Create a low-numbered rule file e.g. 10-sata-disk.rules

    2. Make use of the external "ata_id" program that comes with udev to extract the serial number and other information from a device. This works in two stages: ata_id --export will produce a list of key/value pairs on stdout, one pair per line, which will include ID_SERIAL and ID_SERIAL_SHORT. The IMPORT directive available to udev rules is set up to receive key/value pairs in this manner and add them to the environment for later access through ENV{}. IMPORT{program}="ata_id --export $tempnode" will run ata_id against the device ($tempnode) for which the kernel has issued an event, extract its serial number, and import it into the udev database. The serial number will now be available to subsequent rules through ENV{ID_SERIAL} and ENV{ID_SERIAL_SHORT}. Complete rule:

    SUBSYSTEM=="block", SUBSYSTEMS=="scsi", ACTION=="add", ATTRS{vendor}=="ATA", IMPORT{program}="ata_id --export $tempnode"

    3. With ENV{ID_SERIAL_SHORT} now available to uniquely identify a disk, map it to the device name of your choosing - ":=" is used instead of "=" so that later rules cannot override this choice:


    4. [optional] Add symlinks that correspond to the motherboard port's silkscreen and disk type
    SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="XXXXXXXXXX", SYMLINK+="sata1 seagate-hd"
    SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="YYYYYYYYYYY", SYMLINK+="sata2 western-digital-hd"
    SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="ZZZZZZZZZZ", SYMLINK+="sata3 hitachi-hd"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts