Skip to main content
added 1566 characters in body
Source Link
dirkt
  • 17k
  • 3
  • 35
  • 39

Partial answer:

There are quite a few different ways to get the drive serial number. (Read the ATA, ATAPI and USB storage specs for details).

If you want to find out which particular way is used for the symbolic links, you need to dive into udev, find out which command is used to create those links (very likely blkid), find your version of blkid, and read the source code for it.

That said, the likely culprit for the odd behavior are the different USB-to-SATA bridge chips in your enclosures.

To verify that this chip is the culprit, take the real hard drive out of the closure, connect it via SATA to your mainboard, and see what serial you get.

Errors like duplicating the first letter (SSamsung) or reversing the serial are typical bugs in the firmware for those chips that no one bothered to correct (or maybe no one noticed).


So I had a quick look what it does on my system (old Devuan, which is Debian without systemd): The udev-rules are in

/lib/udev/rules.d/60-persistent-storage.rules

and they call scsi_id (and not blkid), which is in /lib/udev/scsi_id and not in one of the normal places for binaries.

I couldn't get it to produce output from the commandline, but the man page says

scsi_id queries a SCSI device via the SCSI INQUIRY vital product data (VPD) page 0x80 or 0x83 and uses the resulting data to generate a value that is unique across all SCSI devices that properly support page 0x80 or page 0x83.

and it goes on

Identifiers based on page 0x80 are prefixed by the character 'S', the SCSI vendor, the SCSI product (model) and then the the serial number returned by page 0x80.

So that explains your S, which is actually not a duplication of the first letter.

And as far as I know, the vital product page is not the way to get the manufacturer and serial information in most other parts of Linux, so I wouldn't be surprised if your serial reversal is an actual firmware bug either in the harddisk or the USB-SATA-bridge.

You can check this by installing sg3_utils and directly issuing the INQUIRY commands (with --page) to your device (try both in and out of the enclosure).

I don't have a variety of distributions installed, so I have no idea how udev differs on Ubuntu Focal or Debian with systemd.

Partial answer:

There are quite a few different ways to get the drive serial number. (Read the ATA, ATAPI and USB storage specs for details).

If you want to find out which particular way is used for the symbolic links, you need to dive into udev, find out which command is used to create those links (very likely blkid), find your version of blkid, and read the source code for it.

That said, the likely culprit for the odd behavior are the different USB-to-SATA bridge chips in your enclosures.

To verify that this chip is the culprit, take the real hard drive out of the closure, connect it via SATA to your mainboard, and see what serial you get.

Errors like duplicating the first letter (SSamsung) or reversing the serial are typical bugs in the firmware for those chips that no one bothered to correct (or maybe no one noticed).

Partial answer:

There are quite a few different ways to get the drive serial number. (Read the ATA, ATAPI and USB storage specs for details).

If you want to find out which particular way is used for the symbolic links, you need to dive into udev, find out which command is used to create those links (very likely blkid), find your version of blkid, and read the source code for it.

That said, the likely culprit for the odd behavior are the different USB-to-SATA bridge chips in your enclosures.

To verify that this chip is the culprit, take the real hard drive out of the closure, connect it via SATA to your mainboard, and see what serial you get.

Errors like duplicating the first letter (SSamsung) or reversing the serial are typical bugs in the firmware for those chips that no one bothered to correct (or maybe no one noticed).


So I had a quick look what it does on my system (old Devuan, which is Debian without systemd): The udev-rules are in

/lib/udev/rules.d/60-persistent-storage.rules

and they call scsi_id (and not blkid), which is in /lib/udev/scsi_id and not in one of the normal places for binaries.

I couldn't get it to produce output from the commandline, but the man page says

scsi_id queries a SCSI device via the SCSI INQUIRY vital product data (VPD) page 0x80 or 0x83 and uses the resulting data to generate a value that is unique across all SCSI devices that properly support page 0x80 or page 0x83.

and it goes on

Identifiers based on page 0x80 are prefixed by the character 'S', the SCSI vendor, the SCSI product (model) and then the the serial number returned by page 0x80.

So that explains your S, which is actually not a duplication of the first letter.

And as far as I know, the vital product page is not the way to get the manufacturer and serial information in most other parts of Linux, so I wouldn't be surprised if your serial reversal is an actual firmware bug either in the harddisk or the USB-SATA-bridge.

You can check this by installing sg3_utils and directly issuing the INQUIRY commands (with --page) to your device (try both in and out of the enclosure).

I don't have a variety of distributions installed, so I have no idea how udev differs on Ubuntu Focal or Debian with systemd.

Source Link
dirkt
  • 17k
  • 3
  • 35
  • 39

Partial answer:

There are quite a few different ways to get the drive serial number. (Read the ATA, ATAPI and USB storage specs for details).

If you want to find out which particular way is used for the symbolic links, you need to dive into udev, find out which command is used to create those links (very likely blkid), find your version of blkid, and read the source code for it.

That said, the likely culprit for the odd behavior are the different USB-to-SATA bridge chips in your enclosures.

To verify that this chip is the culprit, take the real hard drive out of the closure, connect it via SATA to your mainboard, and see what serial you get.

Errors like duplicating the first letter (SSamsung) or reversing the serial are typical bugs in the firmware for those chips that no one bothered to correct (or maybe no one noticed).