udevadm info --name sdg
P: /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/host7/target7:0:0/7:0:0:1/block/sdg
N: sdg
S: disk/by-id/usb-ST4000DM_000-1F2168_000000000000-0:1
S: disk/by-path/pci-0000:00:1a.0-usb-0:1.1:1.0-scsi-0:0:0:1
E: DEVLINKS=/dev/disk/by-id/usb-ST4000DM_000-1F2168_000000000000-0:1 /dev/disk/by-path/pci-0000:00:1a.0-usb-0:1.1:1.0-scsi-0:0:0:1
E: DEVNAME=/dev/sdg
E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/host7/target7:0:0/7:0:0:1/block/sdg
E: DEVTYPE=disk
E: ID_BUS=usb
E: ID_INSTANCE=0:1
E: ID_MODEL=000-1F2168
E: ID_MODEL_ENC=000-1F2168\x20\x20\x20\x20\x20\x20
E: ID_MODEL_ID=0539
E: ID_PATH=pci-0000:00:1a.0-usb-0:1.1:1.0-scsi-0:0:0:1
E: ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_1_1_0-scsi-0_0_0_1
E: ID_REVISION=0X06
E: ID_SERIAL=ST4000DM_000-1F2168_000000000000-0:1
E: ID_SERIAL_SHORT=000000000000
E: ID_TYPE=disk
E: ID_USB_DRIVER=usb-storage
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=ST4000DM
E: ID_VENDOR_ENC=ST4000DM
E: ID_VENDOR_ID=152d
E: MAJOR=8
E: MINOR=96
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=1710737
@Brett_Abela Thanks for the info. From:
We see each of the 3 drives in the Orico enclosure has a by-id name, which is part of the problem sorted (no serial devices get no by-id name at all), but what we now need to know is if those names are assigned on a first come first served basis, which may change from one boot to the next, or as I am hoping, on a bay/enclosure-slot basis. Can you see if you can establish this? Ie you have 2 different models of drive there and given the enclosure rather unhelpfully obfuscates the actual serials we can’t tell the difference by name alone from the 2 similar models (the essence of why serials are relied upon in Rockstor and by udev). If you can establish that a bay in that enclosure always get the same number assigned to it, ie the “0:0”, “0:1”, “0:2” bit at the end assigned by udev to it’s “ID_SERIAL” element (and in turn used in the generated by-id name, then we have a chance.
So Rockstor can usually track a drive across various different connection methods because it uses the serial, baring serial obfuscation mechanisms of course: But given this enclosure spoils that it can’t. However if the enclosure, and it’s subsequent observation by the usb and block subsystem, is itself consistent with bay numbering then you will at least have that. I.e if a drive is not moved from one bay to the next it will always have the given say “000000000000-0:1” unique element (think those 2 same model drives where there is nothing more to tell them apart). So although less robust it is a potential, if slightly degraded’ way, of tracking a device.
Sort of it: if each bay consistently get the same 0:1 type ending irrespective of it’s content or any of the other bays content then we have a usable ‘bay stable’ system. Otherwise we do not. Rockstor attempts to track drives from their unique id (serial) up, with what this enclosure does it can only manage drives from their bay location up. That may be enough if that is in fact what’s happening here, as long as that is understood in it’s use: mostly this should be fine however.
As this is a potentially time consuming effort on both our parts please be clear on if you would like to attempt the hack path (if the above drive bay to serial mapping end up being stable)? No worries otherwise, but from my perspective it’s the second time such an enclosure has come up on the forum and they look like nicely build pieces of equipment so if we can find a way to accommodate them (if possible), given the above bay level tracking rather than device level tracking, and users are aware of this limitation, then it would be good all around to explore this option. And potentially add it as a ‘special case’ if the interest was there. If the given slot to serial stability is there, I think I see a way to make this so.
Hope that helps and let us know you findings, if you have time of course, on that bay to serial stability (irrespective of other bays content).
N.B. Be sure to also test with the first bay empty, ie do the serials then start from ‘0:1’ and not the so far observed ‘0:0’.
Thanks.
Hi, apologies for resurrecting an old thread but this one looked unresolved. I have an 8 bay Orico unit which has the same problem. I can’t find anything about firmware updates for the JMS567 controller that could address the problem.
To answer your question on whether the “0:0” or “0:1” is assigned by the bay of the drive. Sadly not. The last digit sequentially increases for each drive detected regardless of the bay that it is located in. Which would make the enclosure suitable for Rockstor.
@outicnz Welcome to the Rockstor community.
OK, that’s a shame as from my last post this means that these devices are unusable by Rockstor. Oh well, can’t win them all. It is in my opinion a flawed design to obfuscate a drives only unique element (pre-formatting).
Thanks for confirming this devices workings re the udev names. Most helpful. Funnily enough I was wondering about this just the other day, since it was left unresolved prior to your input.
Do please keep us updated on an other future firmware or internal/external switch option that might change this behaviour as then we could look to accommodating their behaviour if it turned out it was then possible.
Hello, also sorry to resurrect an older thread, but I’ve just started using Rockstor, and have been trying all day to get a 4 drive bay to work with it, when I came across this and anther post.
I do, however, see that the drives are assigned a number 0:0, 0:1, 0:2, 0:3 when they are attached, but have no idea if this is fixed, or can change on reboot.
I love these drive bays, and have 2 of them actually, but hate the thought that I potentially can use them with Rockstor. So any help is figuring out how to provide something unique for these drives is much appreciated.
Just tell me what you need from me, and I’ll do my best to get it back to you.
@bmcgonag Welcome to the Rockstor community.
No worries on that account. The more interested input the better.
Re:
To this question, it looks like we have already had the answer from @outicnz Re:
And from this it pretty much guarantees, on startup, this element of the drive name is arbitrarily assigned. As such it is unreliable and so can’t be used by Rockstor as a reliable drive ‘tracker’.
It may be that there are setting on these enclosures, or firmware fixes etc, that can lead to a reliable naming mechanism. We absolutely need a reliable way to identify (read track) an individual drive regardless of it’s content in order to do the thing we try to do. If you can find a way to retrieve the serial number of a drive whilst it’s within one of these enclosures then it should be possible to first recognise when a drive is within one of these and second to singularly identify that drive by a special case instigated by the enclosure indicator.
So as per my comment to @outicnz
Sorry for the bad news.
I’d suggest, since you have local access to one of these enclosures, that there is an opportunity to confirm @outicnz findings re:
and
to which @outicnz’s understanding is that these names do not represent slots. In which case the next immidiate hope might be to modify/install udev rules that do give us drive or at least bay tracking capability. But even if we got bay tracking stability, if one move a drive from one bay to another it’s serial number would change. That, to Rockstor, would mean the original appearance of the drive (in it’s first bay) would disappear and a new drive would appear. This does not lend itself to stable device tracking. Let us know how you get on. Also it may well be worth confirming this behaviour re changing serial numbers as per drive time start-up in our Rockstor 4 release which has a far newer kernel. Things may have changed in the mean time in how the linux kernel and udev treat/see these devices:
See:
and it’s linked and associated GitHub repo:
Hope that helps.
Hello there!
I think I have an interesting input at that matter. I’ve got a Yottamaster Y-Profession/Y-Pioneer 5 Bay External Hard Drive Enclosure (no-RAID USB 3.0 A/B variant also known as PS500U3) – I’ve got it from a second hand, but it is apparently similar to
Filled it up with 5 Seagate ST4000NC000-1FR168 drives, tried to use with Rockstor and… stumbled upon the all same (all zeros) drive serial number problem. BTW my enclosure seems to be based on ORICO as well:
rockstor:~ # lsusb
Bus 003 Device 002: ID 125f:a578 A-DATA Technology Co., Ltd. ORICO USB Device
...
and, yes, the by-id name seems to be assigned same way in my case. I can confirm the following
In my PS500U3 the scan appears to go top-down in terms of bay order. Anyways, I have to agree with
But I’ve found that hdparm returned Serial Number is actually ok! It’s exactly same as at the drive’s label (the factory printed sticker I mean) in my case. Which would make such Serial Number a reliable drive tracker IMHO.
Walking this way (hinted with @phillxnet’s mention of udev / thanks @phillxnet!) I was able to coin a dirty workaround. Here it goes:
- create executable
/usr/lib/udev/orico_idwith the following juice:
#!/bin/sh
SERIAL=`expr substr "$(/sbin/hdparm -I $1 | grep Serial\ Number)" 22 8`
SERIAL_HEX=`echo -n "$SERIAL" | xxd -ps -c 200`
EXPORTS=`/usr/lib/udev/scsi_id --export --whitelisted -d $1`
EXPORTS="${EXPORTS/ID_SERIAL=33000000000000000/ID_SERIAL=ORICO_hdparm-sn-$SERIAL}"
EXPORTS="${EXPORTS/ID_SERIAL_SHORT=3000000000000000/ID_SERIAL_SHORT=$SERIAL}"
EXPORTS="${EXPORTS/ID_WWN=0x3000000000000000/ID_WWN=0x$SERIAL_HEX}"
EXPORTS="${EXPORTS/ID_WWN_WITH_EXTENSION=0x3000000000000000/ID_WWN_WITH_EXTENSION=0$SERIAL_HEX}"
echo "$EXPORTS"
- add the following to
/usr/lib/udev/rules.d/60-persistent-storage.rules:
# Workaround for ORICO USB enclosure disk serial number problem
KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}=="*000000000000000000000000000000*", IMPORT{program}="orico_id $devnode", ENV{ID_BUS}="scsi"
- reboot the OS
I hope the workaround may help other Rockstor and ORICO (or Yottamaster) users.
Rockstor developers, please consider implementing a clean fix based on the hdparm finding. I offer my help.
Happy New Year, Everyone!
PS I’m on Rockstor 5.0.5-0 Testing / openSUSE Tumbleweed: 20230313 (Linux: 6.2.4-1-default) in a Proxmox 8 VM
Hi, I also encountered this problem with orico dock station.
I tried creating mentioned scripts but problem is still here. I suppose this is due to my serials altought are same for different HDDs, but they are not zeros, so I have to correct script, but I cannot figure out how.
Can you help me, @Greg_R?
in case if needed - my serials are “DD5641988389F”
@DarkDeny, welcome to the Rockstor community.
What is the output of
hdparm -I /dev/sd? | grep 'Serial'
(assuming your devices have the nomenclature sdX)?
They all show up with the same number (the one you posted above)?
Not that it makes much of a difference for these scenarios, but can you also put the Rockstor version number?
I tried to check this out, but got -bash: hdparm: command not found
RockStor version is: ROCKSTOR 4.5.8-0
ah, yes, the package needs to be installed first (which would also be a pre-requisite for any of Greg_R’s scripts to work.
zypper in hdparm, I believe it is.
Actually the package was in place, I missed that I need to sudo running that command.
Output was: Serial Number: 78EWNTNAS
You currently only have one drive? Or did all drives return that same serial number?
yes, I disconnected second drive so that I can have my share available on my PC.
ok, I guess the question now would be, if you connect the second drive again, and run the command, will you get the same output for each of the drives (I would expect not). You might want to run this directly from the terminal, rather than through the Rockstor WebUI to eliminate any other factors …
If they are different, I would then try to run the script from above orico_id /dev/sda (and then for the other device, assuming it might be /dev/sdb and see what the outputs are for each.
If they are different, I would think the udev rule should work, but you already said it does not seem to.
Serial Number: WD-WX32DB0R7SEP
Serial Number: 78EWNTNAS
first drive output was:
ID_SCSI=1
ID_VENDOR=External
ID_VENDOR_ENC=External
ID_MODEL=USB3.0_DISK03
ID_MODEL_ENC=USB3.0\x20DISK03\x20\x20\x20
ID_REVISION=0103
ID_TYPE=disk
ID_SERIAL=33044564198838960
ID_SERIAL_SHORT=3044564198838960
ID_SERIAL_COMPAT=
ID_WWN=0x3044564198838960
ID_WWN_WITH_EXTENSION=0x3044564198838960
ID_SCSI_SERIAL=DD5641988389F
second
ID_SCSI=1
ID_VENDOR=External
ID_VENDOR_ENC=External
ID_MODEL=USB3.0_DISK04
ID_MODEL_ENC=USB3.0\x20DISK04\x20\x20\x20
ID_REVISION=0103
ID_TYPE=disk
ID_SERIAL=33044564198838960
ID_SERIAL_SHORT=3044564198838960
ID_SERIAL_COMPAT=
ID_WWN=0x3044564198838960
ID_WWN_WITH_EXTENSION=0x3044564198838960
ID_SCSI_SERIAL=DD5641988389F
Mhm, it seems then that in your case, not even the serial numbers (SCSI or otherwise) are differentiated. In @greg_r’s case serial numbers were different (matching the ones on the printed label) which then allowed for that script/udev rule combination to work. In your case, since there is no “good” differentiating factor (and the ID_MODEL based on which bay the disk is in, is likely not a good candidate) I don’t think the approach outlined by @greg_r will work for you.
Which orico enclosure model are you using?
I have 6558US3-C, it also say 5HDD duplicator, that might be the issue?