#StackBounty: #linux #ubuntu #hard-drive #usb #udev Disk drive serial number reversed in /dev/disk/by-id/scsi-*

Bounty: 250

I’m using Ubuntu 20.04 with USB external drives and experiencing a rather odd bug. I’ve got a bunch of USB enclosures for hard disk drives here (or rather sold as external drives):

  • Samsung Portable SSD T5 (mSATA to USB with UASP internally)

    S/N reported to kernel (as per dmesg & lsusb -v): 12345688ACF4

    (This is a bogus disk serial over USB, different from label and SMART data.)

  • Samsung Portable SSD T7 (NVMe to USB with UASP internally)

    (Reports correct disk serial over USB; identical to SMART data and disk label.)

  • StarTech USB 3.1 gen2 enclosure for SATA hard disk drive, with UASP

    (Reports correct disk serial over USB; identical to SMART data and disk label.)

  • Ewent EW7017 USB to SATA dongle with UASP

    (Reports bogus disk serial 000000004BA8 over USB, it’s always the same.)

  • WD Elements USB hard disk drive without UASP

    (Reports bogus disk serial over USB.)

All these are single-disk to USB enclosures basically.

Their serial number reported over USB to the kernel is sometimes wrong, but that seems a hardware issue with them. It’s not something we can solve and my question is about something else.

When adding a drive, a convenient link is created for them in /dev/disk/by-id/:

├── dm-name-dm_crypt-0 -> ../../dm-0
├── scsi-SSamsung_Portable_SSD_T5_4FCA88654321 -> ../../sdb
├── scsi-SSamsung_Portable_SSD_T5_4FCA88654321-part1 -> ../../sdb1

This is really cool, as it allows me to be sure I’m working on the correct drive rather than a dangerous assumption sdb would be the correct drive.

As you can see the string scsi-SSamsung_Portable_SSD_T5_4FCA88654321 contains two errors, though:

  1. The manufacturer name is prepended with an S.
  2. The serial number is reversed; 12345688ACF4 became 4FCA88654321.

The same happens with the T7 drive.

The StarTech enclosure does not have the serial reversion:

├── scsi-STOSHIBA_MQ01ABB200_1234ABCD -> ../../sdb

Same for the Ewent one:

├── scsi-SWDC_WD20_NPVX-00EA4T0_000000004BA8 -> ../../sdb

The Western Digital non-UASP drive does not suffer from any of the two problems:

└── usb-WD_Elements_1048_1234ABCD-0:0 -> ../../sdb

Also sometimes it’s an i prepended instead of an S, depending on the manufacturer.

Why is this? What piece of software is responsible for these errors?

I am also using a more professional hot plug storage enclosure and this one works fine with those drives. So, it seems purely over USB or UASP that this goes bonkers.

Even weirder; when using the same hardware on Debian Linux 10/Buster, it works fine (ata instead of scsi by the way! and yes UASP is enabled scsi host4: uas in dmesg):

├── ata-TOSHIBA_MQ01ABB200_1234ABCD -> ../../sdb

So, is this an Ubuntu bug after all?

Get this bounty!!!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.