scsi_id truncates serial number

Bug #102332 reported by Anders Häggström
8
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: udev

At the moment I'm running from Ubuntu Edgy LiveCD, but I have done an installation and upgraded the whole system, but it didn't fix the bug.

Motherboard: Gigabyte GA-M55Plus-S3G
Attached disks: hda, sda, sdb, sdc, sdd, sde, sdf
"sda" to "sdd" is the same type of disk, and its the disks that does not show up correctly by udev. The other disks are attached just to show that udev is working for them.

# ls -l /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root 9 2007-04-03 01:00 ata-IBM-DJNA-351520_G80GLWDK522 -> ../../hda
lrwxrwxrwx 1 root root 10 2007-04-03 01:00 ata-IBM-DJNA-351520_G80GLWDK522-part1 -> ../../hda1
lrwxrwxrwx 1 root root 10 2007-04-03 01:00 ata-IBM-DJNA-351520_G80GLWDK522-part2 -> ../../hda2
lrwxrwxrwx 1 root root 10 2007-04-03 01:00 ata-IBM-DJNA-351520_G80GLWDK522-part3 -> ../../hda3
lrwxrwxrwx 1 root root 9 2007-04-03 01:00 scsi-1ATA_ST3320620AS_9RV -> ../../sdd
lrwxrwxrwx 1 root root 9 2007-04-03 01:00 usb-Pretec_01GB_03AD0000001471 -> ../../sde
lrwxrwxrwx 1 root root 10 2007-04-03 01:00 usb-Pretec_01GB_03AD0000001471-part1 -> ../../sde1
lrwxrwxrwx 1 root root 9 2007-04-03 01:05 usb-USB_2.0_MobileDisk_N4ST_FF05051700876 -> ../../sdf
lrwxrwxrwx 1 root root 10 2007-04-03 01:05 usb-USB_2.0_MobileDisk_N4ST_FF05051700876-part1 -> ../../sdf1
lrwxrwxrwx 1 root root 10 2007-04-03 01:05 usb-USB_2.0_MobileDisk_N4ST_FF05051700876-part2 -> ../../sdf2

The bug seems to ocur because udev does not print the correct ID of the sata-disks (sda -> sdd). It only print the type and then the first three letters of the ID, which is the same for my disks according to smartctl.
I have doubblechecked the correct type and ID fysically on the disks and smartctl find the correct ones.

Revision history for this message
Anders Häggström (hagge) wrote :

# dmesg

Revision history for this message
Anders Häggström (hagge) wrote :

# smartctl -i /dev/hda

Revision history for this message
Anders Häggström (hagge) wrote :

# ls -l /dev/disk/by-id

Revision history for this message
Anders Häggström (hagge) wrote :

# ls -l /dev

Revision history for this message
Anders Häggström (hagge) wrote :

# smartctl -i /dev/sda

Revision history for this message
Anders Häggström (hagge) wrote :

# smartctl -i /dev/sdb

Revision history for this message
Anders Häggström (hagge) wrote :

# smartctl -i /dev/sdc

Revision history for this message
Anders Häggström (hagge) wrote :

# smartctl -i /dev/sdd

Revision history for this message
Anders Häggström (hagge) wrote :

# smartctl -i /dev/sde

Revision history for this message
Anders Häggström (hagge) wrote :

# smartctl -i /dev/sdf

Revision history for this message
Anders Häggström (hagge) wrote :

# uname -a

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Please run /lib/udev/vol_id (as root) for each of the disks (giving the dev path as an argument) and provide the output

Changed in udev:
status: Unconfirmed → Needs Info
Revision history for this message
Anders Häggström (hagge) wrote :

I see no hardware-ID anywhere in the output. The only thing it confirms is that I'm using encryption on the disks (sda -> sdd). And yes, I do use encryption and I do it without a partitiontable.
The four disks are part of an encrypted raid5-array (/dev/md0) which is not attached/mounted at the moment.
I did not think the missing partitiontable or the encryption messed up udev's ability to locate/find the hardware-id of the disks. Am I wrong about that?

Btw, why isn't encrypted disks shown in /dev/disk/by-uuid? It looks like they have a proper UUID.

# /lib/udev/vol_id /dev/hda
{Empty output}

# /lib/udev/vol_id /dev/sda
ID_FS_USAGE=crypto
ID_FS_TYPE=crypto_LUKS
ID_FS_VERSION=
ID_FS_UUID=85f64d57-0de1-4a82-98b6-5ae6d686f9ef
ID_FS_LABEL=
ID_FS_LABEL_SAFE=

# /lib/udev/vol_id /dev/sdb
ID_FS_USAGE=crypto
ID_FS_TYPE=crypto_LUKS
ID_FS_VERSION=
ID_FS_UUID=b52bc279-4d18-4d30-8acf-2fdb883ad963
ID_FS_LABEL=
ID_FS_LABEL_SAFE=

# /lib/udev/vol_id /dev/sdc
ID_FS_USAGE=crypto
ID_FS_TYPE=crypto_LUKS
ID_FS_VERSION=
ID_FS_UUID=6e84c4b3-4a04-4afd-90ff-38ef5f15c300
ID_FS_LABEL=
ID_FS_LABEL_SAFE=

# /lib/udev/vol_id /dev/sdd
ID_FS_USAGE=crypto
ID_FS_TYPE=crypto_LUKS
ID_FS_VERSION=
ID_FS_UUID=c7665c2a-6930-42d3-841a-06b551fe2ab5
ID_FS_LABEL=
ID_FS_LABEL_SAFE=

# /lib/udev/vol_id /dev/sde
{Empty output}

# /lib/udev/vol_id /dev/sdf
{Empty output}

Revision history for this message
Anders Häggström (hagge) wrote :

I have investigated the bug further and it seems like the program "scsi_id" have a maximal lenght of its output-varialbes and thats why the ID is cut after three letters. The disk-type-variable is part of the id-variable and together they are too long.

I attach the output from udevtest, where you can see the variable "SERIAL_ID" is cut from the output of "scsi_id"

Revision history for this message
Anders Häggström (hagge) wrote :

# udevtest /block/sdb

Revision history for this message
Anders Häggström (hagge) wrote :

# udevtest /block/sdc

Revision history for this message
Anders Häggström (hagge) wrote :

# udevtest /block/sdd

Revision history for this message
Anders Häggström (hagge) wrote :

The actual output from scsi_id is as follows:
# /lib/udev/scsi_id -g -x -s /block/sda
ID_VENDOR=ATA
ID_MODEL=ST3320620AS
ID_REVISION=3.AA
ID_SERIAL=1ATA_ST3320620AS_9RV
ID_TYPE=disk
ID_BUS=scsi

And in my opinion it should be:
# /lib/udev/scsi_id -g -x -s /block/sda
ID_VENDOR=ATA
ID_MODEL=ST3320620AS
ID_REVISION=3.AA
ID_SERIAL=9RV01S5H
ID_TYPE=disk
ID_BUS=scsi

When that is corrected the udev rule (/etc/udev/rules.d/65-persistent-storage.rules) should be something similar to this:
KERNEL=="sd*[!0-9]|sr*|dasd*[!0-9]", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_MODEL}_$env{ID_SERIAL}"
KERNEL=="sd*[0-9]|dasd*[0-9]", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_MODEL}_$env{ID_SERIAL}-part%n"

Revision history for this message
Anders Häggström (hagge) wrote :

Here is a bash-script I wrote as a temporary workaround for the broken scsi_id.
It works for me together with the modified udev-rule I posted earlier.

The script is using smartctl as backend to get the information instead of sysfs or scsi_id.

I also found the "ID_REVISION" fail to detect the correct value, at least if you compare to smartctl.

Revision history for this message
Anders Häggström (hagge) wrote :

I forgot some info...

The script needs to be run as root, because smartctl only work as the rootuser.

The script has one, and only one argument. The argument is the path tho the drive that is bypassed to smartctl.
Like this:
# ./smartctl_id.sh /dev/sda

And to use the modidified udev-rules together with "smartctl_id" you need to edit the import-lines from scsi_id to smartctl_id.
The old lines:
KERNEL=="sd*[!0-9]|sr*|st*", ENV{ID_SERIAL}=="", IMPORT{program}="scsi_id -g -x -s %p -d $tempnode"
KERNEL=="sd*[!0-9]|sr*|st*", ENV{ID_SERIAL}=="", IMPORT{program}="scsi_id -g -x -a -s %p -d $tempnode"
Should be exchanged with this line:
KERNEL=="sd*[!0-9]|sr*|st*", ENV{ID_SERIAL}=="", IMPORT{program}="smartctl_id.sh /dev/%k"

Revision history for this message
Anders Häggström (hagge) wrote :

I just found that my usb devices (sde & sdf) became double named with my code change. I tailed it down to usb_id that also have a messed up output. The difference between scsi_id and usb_id is that usb_id does not cut the output at a fixed length, so it's not a large trouble, it just produce very long symlinks with the ID_MODEL twice.

Changed in udev:
status: Needs Info → Unconfirmed
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Does this bug need to be private? It prevents us from sharing it amongst people who may be able to help

Changed in udev:
importance: Undecided → Low
status: Unconfirmed → Confirmed
Revision history for this message
Anders Häggström (hagge) wrote :

Not really.. If it is a large obstacle for the bug fixing
progress you can change the setting. and make it non-private.

// Anders

Revision history for this message
Anders Häggström (hagge) wrote :

I have now installed/upgraded to Feisty and can confirm that the bug does not affect Feisty.

Changed in udev:
status: Confirmed → Fix Released
To post a comment you must log in.