Device identification in case of same SN

  • Have two SATA to USB adapters (Orico 27UTS)
    Their SN and ID is the same, bc of that OVM apply setting to both HDD when editing on of that


    Is the way to apply unique ID for correct identification or need to change one of adapters with other brand?

  • It might not matter having two devices with the same S/N. The filesystem UUIDs will be unique.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • Have two SATA to USB adapters (Orico 27UTS)
    Their SN and ID is the same,

    Two different devices with the same serial number ?( Curious


    Normally different disks have unique UUIDs. Did you have cloned the drives with a tool before?


    You should do a full wipe of both drives.

    OMV 3.0.100 (Gray style)

    ASRock Rack C2550D4I C0-stepping - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1) - Fractal Design Node 304 -

    3x WD80EMAZ Snapraid / MergerFS-pool via eSATA - 4-Bay ICYCube MB561U3S-4S with fan-mod

  • Two different devices with the same serial number ?( Curious
    Normally different disks have unique UUIDs. Did you have cloned the drives with a tool before?


    You should do a full wipe of both drives.

    File systems are assigned unique UUIDs when they are initially formatted. This is not the OP's problem, and wiping the drives and reformatting will not change the serial numbers in the hardware. The identical serial numbers belong to the SATA to USB physical adapters, not the file systems on the plugged in and formatted disks.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • Thanks for the clarification!

    You should do a full wipe of both drives.

    I was thinking rather of a complete wipe in the sense of which was called "low level format" in former times. Then the UUID should be removed too, I would assume.


    The identical serial numbers belong to the SATA to USB physical adapters, not the file systems on the plugged in and formatted disks.

    That would mean, that the drive and the USB-to-Sata-adapter is a bundle and shall not be changed later or mixed among each other, isn´t it?


    That would mean also, that the current problem of @andgi can only be solved with another adapter with a different serial number.


    Why are the serial numbers retrieved from the USB to SATA adapter and not directly from the drive? What is the technical reason?

    OMV 3.0.100 (Gray style)

    ASRock Rack C2550D4I C0-stepping - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1) - Fractal Design Node 304 -

    3x WD80EMAZ Snapraid / MergerFS-pool via eSATA - 4-Bay ICYCube MB561U3S-4S with fan-mod

    Edited 3 times, last by cabrio_leo ().

  • Why are the serial numbers retrieved from the USB to SATA adapter and not directly from the drive? What is the technical reason?

    That It is about what I am interesting - is there a chance to apply setting for each device using other device IDs?


    OMV4 arm (raspberrypi)
    2x SATA to USB adapters Orico 27UTS - both have same S/N 201703310007F
    HDD#1 info from S.M.A.R.T: /dev/sda, Device model ST9500325AS, SN 5VE0BBG4, Firmare v 0002SPM1
    HDD#2 info from S.M.A.R.T: /dev/sdb, Device model ST9500420ASG, SN 5VJ05X5P, Firmare v0002SDM1

    Files

    • HDD1.jpg

      (52.48 kB, downloaded 137 times, last: )
    • HDD2.jpg

      (53 kB, downloaded 112 times, last: )
  • Hello!
    I solved this problem using udev rules to rewrite env variables with actual serial number value from hdparm.
    Cheap china devices always have unpredictable drawbacks in some special cases =(

    Bash: /usr/local/bin/orico-sn.sh
    #!/bin/sh
    SN=$(hdparm -I $1 | grep 'Serial\ Number' | awk -F ':' '{print $2}' | tr -d [:blank:])
    echo "ID_SERIAL_SHORT=${SN}"
    echo "ID_SERIAL=${ID_VENDOR}_${ID_MODEL}_${SN}-${ID_INSTANCE}"
    Bash: /usr/lib/udev/rules.d/99-orico.rules
    ACTION=="add", SUBSYSTEM=="block", ATTRS{idVendor}=="0080", ATTRS{idProduct}=="a001", IMPORT{program}="/usr/local/bin/orico-sn.sh $devnode", SYMLINK="disk/by-path/$env{ID_PATH}", SYMLINK+="disk/by-id/usb-$env{ID_SERIAL}"
  • Hi,


    I'm having the exact same issue as you. Two drives, both with the same enclosure registering with the same serial number causing only one to be picked up at a time.


    I'm not super familiar with linux. I've created the scripts above, did chmod +x on the .sh, and created the udev and rules.d folder and placed the 99-orico.rules in that folder...but I'm not sure how to ensure the script gets ran. Can you give me some more detailed information on what to do next? I think I just don't have enough knowledge of linux to even know where to go from here.


    Thank you!!

  • I just wanted to update that I did find that I needed to update the idVendor and idProduct variables, but it still didn't work.


    I used the below page to make the updates

    https://linuxconfig.org/tutori…basic-udev-rules-in-linux


    I did the following:


    1. Use udevadm info \dev\sda to identify my device info
    2. "use udevadm info -a \dev\sda | grep idVendor" to get the vendor id. several results were returned, I compared them to the output above to see that it tied out to the vendor variable.
    3. "use udevadm info -a \dev/sda | grep idProduct" to get the product id. Several results were returned, the first result tied out to my model ID, I used that.
    4. Place the two values above into the rules script for idProduct and idVendor
    5. Reboot the pi.


    After doing this I'm still seeing the same serial number for the device.

  • Update 2: I fixed it finally.


    The path given above for the rules.d appears to be incorrect. It needs to be /lib/dev/rules.d, not /usr/lib/dev/rules.d. Once I moved the rules file there it was picked up and ran.

  • Update 2: I fixed it finally.


    The path given above for the rules.d appears to be incorrect. It needs to be /lib/dev/rules.d, not /usr/lib/dev/rules.d. Once I moved the rules file there it was picked up and ran.

    I am having the same problem with Sabrent HD enclosures. I believe I found the correct idVendor=152d and idProduct=1561 but still cannot get it to work. Can you share your files with the idVendor and idProduct filled in?

  • I don´t know if this commands are available in OMV for ARM CPUs but I used those commands to find out the VendorID and ProductID:

    lsusb

    In my case this was returned:

    Bus 002 Device 003: ID 174c:55aa ASMedia Technology Inc. ASMedia 2105 SATA bridge

                            |    |

                           VID  PID

    The first four bytes is IDVendor, the second one is IDProduct.


    Otherwise you can use dmesg | grep usb to get more information about USB devices.

    OMV 3.0.100 (Gray style)

    ASRock Rack C2550D4I C0-stepping - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1) - Fractal Design Node 304 -

    3x WD80EMAZ Snapraid / MergerFS-pool via eSATA - 4-Bay ICYCube MB561U3S-4S with fan-mod

  • Thanks everyone.


    I'm pretty inexperienced but using the above I was able to get this working for both of my Sabrent Drives.

    Code: Bash: /usr/lib/udev/rules.d/99-orico.rules
    ACTION=="add", SUBSYSTEM=="block", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="1561", IMPORT{program}="/usr/local/bin/orico-sn.sh $devnode", SYMLINK="disk/by-path/$env{ID_PATH}", SYMLINK+="disk/by-id/usb-$env{ID_SERIAL}"
  • Have two SATA to USB adapters (Orico 27UTS)
    Their SN and ID is the same, bc of that OVM apply setting to both HDD when editing on of that


    Is the way to apply unique ID for correct identification or need to change one of adapters with other brand?

    andgi Could you please run the command udevadm info --query=all --name=/dev/sdX for one of your disks and post the output here.

  • This also happens to my HornetTek HT-RAB237 enclosure in a non-raid. I'm new around at this stuff, but wanted to contribute by adding this.


  • Hey guys,


    i'm desperately trying to get a workaround with your solutions posted above...without success yet. ;(

    I don't really know how to make this rules to get the things done.


    Maybe somebody could help me with a small StepByStep-Guide for that i can see my 2 drives in omv.

    Here's what i see in omv:

    OMV only recognizes 1 out of 2 USB-Drives.


    However, at the filesystems overview everything is ok:



    lsusb tells me this:


    Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

    Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

    Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub

    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


    As you can see, my 2 USB-Drives have the same properties.


    Here's what udev says:


    sudo udevadm info -a /dev/sda | grep idVendor && sudo udevadm info -a /dev/sdb | grep idVendor

    ATTRS{idVendor}=="152d"

    ATTRS{idVendor}=="1d6b"

    ATTRS{idVendor}=="152d"

    ATTRS{idVendor}=="1d6b"


    sudo udevadm info -a /dev/sda | grep idProduct && sudo udevadm info -a /dev/sdb | grep idProduct

    ATTRS{idProduct}=="0578"

    ATTRS{idProduct}=="0003"

    ATTRS{idProduct}=="0578"

    ATTRS{idProduct}=="0003"


    udevadm info --query=all --name=/dev/sda

    P: /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-1/2-1:1.0/host0/target0:0:0/0:0:0:0/block/sda

    N: sda

    L: 0

    S: disk/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1:1.0-scsi-0:0:0:0

    S: disk/by-id/usb-JMicron_Generic_0123456789ABCDEF-0:0

    E: DEVPATH=/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-1/2-1:1.0/host0/target0:0:0/0:0:0:0/block/sda

    E: DEVNAME=/dev/sda

    E: DEVTYPE=disk

    E: MAJOR=8

    E: MINOR=0

    E: SUBSYSTEM=block

    E: USEC_INITIALIZED=10677685

    E: ID_VENDOR_ENC=JMicron\x20


    E: ID_VENDOR_ID=152d

    E: ID_MODEL=Generic

    E: ID_MODEL_ID=0578eric\x20\x20\x20\x20\x20\x20\x20\x20\x20


    E: ID_REVISION=0508

    E: ID_SERIAL=JMicron_Generic_0123456789ABCDEF-0:0

    E: ID_TYPE=diskORT=0123456789ABCDEF


    E: ID_INSTANCE=0:0

    E: ID_BUS=usb

    E: ID_USB_INTERFACE_NUM=0050:080662:


    E: ID_USB_DRIVER=uas

    E: ID_PATH=platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1:1.0-scsi-0:0:0:0

    E: ID_PART_TABLE_UUID=d08355ad-08f9-4aed-9567-f54fb25c73a6-0_1_1_0-scsi-0_0_0_0


    E: ID_PART_TABLE_TYPE=gpt

    E: DEVLINKS=/dev/disk/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1:1.0-scsi-0:0:0:0 /dev/disk/by-id/usb-JMicron_Generic_0123456789ABCDEF-0:0

    E: TAGS=:systemd:


    udevadm info --query=all --name=/dev/sdb

    P: /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2/2-2:1.0/host1/target1:0:0/1:0:0:0/block/sdb

    L: 0db


    S: disk/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:0

    S: disk/by-id/usb-JMicron_Generic_0123456789ABCDEF-0:0

    E: DEVNAME=/dev/sdb/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2/2-2:1.0/host1/target1:0:0/1:0:0:0/block/sdb


    E: DEVTYPE=disk

    E: MAJOR=8

    E: SUBSYSTEM=block


    E: USEC_INITIALIZED=225948629

    E: ID_VENDOR=JMicron

    E: ID_VENDOR_ID=152dcron\x20


    E: ID_MODEL=Generic

    E: ID_MODEL_ENC=Generic\x20\x20\x20\x20\x20\x20\x20\x20\x20

    E: ID_REVISION=0508


    E: ID_SERIAL=JMicron_Generic_0123456789ABCDEF-0:0

    E: ID_SERIAL_SHORT=0123456789ABCDEF

    E: ID_INSTANCE=0:0


    E: ID_BUS=usb

    E: ID_USB_INTERFACES=:080650:080662:

    E: ID_USB_DRIVER=uasNUM=00


    E: ID_PATH=platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:0

    E: ID_PATH_TAG=platform-fd500000_pcie-pci-0000_01_00_0-usb-0_2_1_0-scsi-0_0_0_0

    E: ID_PART_TABLE_TYPE=gpt775b2-0cdb-4be0-a231-88a93553aed2


    E: DEVLINKS=/dev/disk/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:0 /dev/disk/by-id/usb-JMicron_Generic_0123456789ABCDEF-0:0

    E: TAGS=:systemd:



    So, this is my status quo. Now i want to get the magic done by a udev-rule to see my 2 drives in omv or to generally distinguish from each other.


    Big THX for everybody who could help me!!! :S

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!