RPI4 Quad says hat

Same problem.

https://forum.radxa.com/t/quad…ult-5-raspberry-pi-4/3193

Hi,

in my case (JMicron JM20337 USB PATA/SATA bridge on Orangepi PC2 with OMV5) the generic env ENV{ID_VENDOR}=="JMicron" in the troubleshooting sectiondid not work and I had to change the rule as follows:

KERNEL=="sd*", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="2338", SUBSYSTEMS=="usb", PROGRAM="/root/serial.sh %k", ENV{ID_SERIAL}="USB-%c", ENV{ID_SERIAL_SHORT}="%c"

where idVendor and idProduct are simply coming from lsusb command output

just made a PR

sorry but I'm not very familiar with github so you should format the text in my commit in the proper way to be released in the troubleshooting guide....just few lines

Zitat von votdev

In the troubleshooting section there are some hints related to JMicron controllers, maybe that helps.

I tried the troubleshooting section for JMicron controllers:

Zitat von latimeria

Hi,

in my case (JMicron JM20337 USB PATA/SATA bridge on Orangepi PC2 with OMV5) the generic env ENV{ID_VENDOR}=="JMicron" in the troubleshooting sectiondid not work and I had to change the rule as follows:

Code

KERNEL=="sd*", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="2338", SUBSYSTEMS=="usb", PROGRAM="/root/serial.sh %k", ENV{ID_SERIAL}="USB-%c", ENV{ID_SERIAL_SHORT}="%c"

where idVendor and idProduct are simply coming from lsusb command output

So when the above failed I tried your recommendation. And it worked. Thank you.

cabi

Did you do anything else

I tried the exact same thing and my lsusb is the same as yours

root@raspberrypi:~# lsusb

Bus 002 Device 002: ID 1058:0a10 Western Digital Technologies, Inc.

Bus 002 Device 003: ID 1058:0a10 Western Digital Technologies, Inc.

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

I did notice my serial.sh does throw some errors

root@raspberrypi:~# . /root/serial.sh sda

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

WD-WXH0A9963528

root@raspberrypi:~# . /root/serial.sh sdb

W764ZE7R

root@raspberrypi:~# . /root/serial.sh sdc

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

W0Q6WH0B

root@raspberrypi:~# . /root/serial.sh sdd

5VE0AXEC

but in openmedia I now only see one drive and it has a serial number of ACASIS and only dev\sdd sda sdb and sdc are missing?

Any one got any ideas?

KERNEL=="sd*", ATTRS{idVendor}=="1058", ATTRS{idProduct}=="0a10", SUBSYSTEMS=="usb", PROGRAM="/root/serial.sh %k", ENV{ID_SERIAL}="USB-%c", ENV{ID_SERIAL_SHORT}="%c"

I'm in the same boat. Cannot get past only 1 drive showing up in OMV. Urgh!

Same problem here. Fix for the serial script is straightforward just add 2>/dev/null as shown below.

#!/bin/bash

/sbin/hdparm -I /dev/$1 2>/dev/null | grep 'Serial Number' | awk '{print $3}'

Now script will return proper serial numbers for all my drives.

But alas, even after reboot and OMV scan for new disks... my missing Samsung 860 EVO is not discovered.

After updating the script and storage config this is what i get. its different to with out the update but still not the right serial numbers? and there should be 4 drives...

checking out this the subsystem is "block" where do people take the USB/SCSI from when they talk about updating the storage config?

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

N: sdb

L: 0

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-ACASIS_Go_To_Final_Lap_1234567890123-0:0

E: DEVPATH=/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

E: DEVNAME=/dev/sdb

E: DEVTYPE=disk

E: MAJOR=8

E: MINOR=16

E: SUBSYSTEM=block

E: USEC_INITIALIZED=13508938

E: ID_VENDOR=ACASIS

E: ID_VENDOR_ENC=ACASIS\x20\x20

E: ID_VENDOR_ID=1058

E: ID_MODEL=Go_To_Final_Lap

E: ID_MODEL_ENC=Go\x20To\x20Final\x20Lap

E: ID_MODEL_ID=0a10

E: ID_REVISION=8034

E: ID_SERIAL=ACASIS_Go_To_Final_Lap_1234567890123-0:0

E: ID_SERIAL_SHORT=1234567890123

E: ID_TYPE=disk

E: ID_INSTANCE=0:0

E: ID_BUS=usb

E: ID_USB_INTERFACES=:080650:080662:

E: ID_USB_INTERFACE_NUM=00

E: ID_USB_DRIVER=uas

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: 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-ACASIS_Go_To_Final_Lap_1234567890123-0:0

E: TAGS=:systemd:

This is what worked for me. After adding to /lib/udev/rules.d/60-persistent-storage.rules I can see the drives but OMV thinks they are USB devices so there is no option to create a raid. I have also changed to sata in the script with the same results. Any thought?

KERNEL=="sd*", ATTRS{idVendor}=="1058", ATTRS{idProduct}=="0a10", SUBSYSTEMS=="usb", PROGRAM="/root/serial.sh %k", ENV{ID_SERIAL}="USB-%c", ENV{ID_SERIAL_SHORT}="%c"