On Tue 16 Jan 2024 at 09:40:19 (-0500), Greg Wooledge wrote: > On Tue, Jan 16, 2024 at 09:31:54AM -0500, Felix Miata wrote: > > David Wright composed on 2024-01-16 08:05 (UTC-0600): > > > On Tue 16 Jan 2024 at 00:55:52 (-0500), Felix Miata wrote: > > >> gene heskett composed on 2024-01-15 17:56 (UTC-0500): > > > > >>> Thanks for that composition: but it will be word wrapped: > > >>> root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n' > > >>> "$(realpath "$j")" "$j" ; done > > >>> /dev/sr0 /dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865 > > >>> /dev/sdi /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146 > > >>> /dev/sdj1 /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1 > > > > > It's right here at the top. > > > > I missed that, probably because i & j look similar in the big sea of > > alphanumerics, /and/ sdi has no partitions, while sdj1 has no parent disk. > > That > > seems to smell as much like a bug somewhere as two different disks with the > > same > > serial number, a cheap SATA port card maybe. Does ...1146 get duplication > > like > > that when connected to any/every available SATA port? > > I missed it too. It actually looks like someone copy/pasted the > pathnames on the right, but then manually typed the device names on > the left, and made a typo here. Or, somehow, the device names and > the pathnames got mixed together, and someone tried to separate them > manually, and got these two crossed.
It's the sticky labels that convinced me. I had one last possibility in mind, that the serial numbers were being generated by the interfaces somehow, but they wouldn't be able to read the labels. I know nothing about Gene's interfaces, but my SD cards can appear with false by-id/ values depending on where they're plugged in: slots (on different PCs), via µSD-SD adapter, SD-USB adapter, etc. Cheers, David.
