Warning! Disk serial number is not legitimate or unique

@phillxnet Thank you for your investment in time, I know how precious it is!

For some reason I haven’t looked into deeply enough the -i flag didn’t work for me and instead returned the error below:

$ sudo hdparm -i /dev/sdb

HDIO_GET_IDENTITY failed: Invalid argument

However looking at hdparm -h showed an alternative option:

 -i   Display drive identification
 -I   Detailed/current information directly from drive

Promising results on the first drive:

$ sudo hdparm -I /dev/sdb
ATA device, with non-removable media
Model Number: ST2000DM008-2UB102
Serial Number: ZFL6NWMZ
Firmware Revision: 0964
Supported: 7 6 5 4
Likely used: 7
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63

CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 3907029168
SG_IO: bad/missing sense data, sb[]: 70 00 0b 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
device size with M = 10241024: 1907729 MBytes
device size with M = 1000
1000: 2000398 MBytes (2000 GB)
cache/buffer size = unknown
LBA, IORDY(can be disabled)
Standby timer values: spec’d by Vendor, no device specific minimum
R/W multiple sector transfer: Max = 1 Current = 1
Advanced power management level: disabled
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
Advanced Power Management feature set
SET_MAX security extension
* 48-bit Address feature set
* Mandatory FLUSH_CACHE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Software settings preservation
not enabled
not locked
not expired: security count
not supported: enhanced erase
more than 508min for SECURITY ERASE UNIT.
Checksum: correct

For the remaining disks I got:

$ sudo hdparm -I /dev/sdc | grep -i -e number
Model Number: ST2000DM008-2UB102
Serial Number: ZFL6NBB2
$ sudo hdparm -I /dev/sdd | grep -i -e number
Model Number: ST2000DM008-2UB102
Serial Number: ZFL6P5MC
$ sudo hdparm -I /dev/sde | grep -i -e number
Model Number: ST2000DM008-2UB102
Serial Number: ZFL6P5PQ

This seems hopeful, what do you think?


@redplague Thanks for the persistent testing here.

It does indeed. Funny how the -i failed thought. Possibly due to some hard disk type assumption or other and good to know this. And I’m guessing the capital “… directly from drive” ‘I’ option works around this.

But what-ever this is a nice find. If you or someone else doesn’t beat me to it I think what we need there is some code testing to see if this is all we need to support these devices. My current worry is that we have elsewhere some assumption on the structure of the by-id name udev assigned.

Can’t look myself currently but it may be this is non critical. And can be addressed as an independent issue. But it’s hopeful to have found a way to split out these drives serials from their enclosure obfuscation and get their ‘real’ serials.

A quick hack, to be done on a non production system :slight_smile: , is to have your copy of get_disk_serial() use hdparm -I to retrieve the serial, instead of it’s current use of udevadmin. But I’m still a little perplexed that our initial lsblk reading of the serial is not working as intended. It’s still the default I believe.

Again I’ll have to focus in on this area of the code again soon with this new info. But do let us know if you end up doing any more investigations.

Hope that helps.