If I set my hardware raid controller in JBOD mode, this is the only time rockstor is able to see the disks, then again it’s not able to understand the serial #'s from each individual disk. If I leave it alone out of any RAID or JBOD configuration the system does not see disks at all that are coming through the raid controller.
Has anyone seen anything similar?
@drancourt Welcome to Rockstor community and thanks for posting your findings.
As far as your no serial number found issue this has been seen and fixed with some devices but still exists with some others, ie certain sdcard readers. If you could post the output of the following commands run via ssh / console on your Rockstor install while in JBOD mode as you pictured we might be able to see what’s wrong and how it might be fixed.
/usr/bin/lsblk -P -o NAME,MODEL,SERIAL,UUID,SIZE
and the follow 3 commands:-
udevadm info --name=sdb | grep 'MODEL=\|DEVNAME\|SERIAL'
udevadm info --name=sdc | grep 'MODEL=\|DEVNAME\|SERIAL'
udevadm info --name=sdd | grep 'MODEL=\|DEVNAME\|SERIAL'
Note the single quotes are the upright type not the lean back type.
This will hopefully tell us if your controller is one that can respond to a workaround already found for certain other devices that lsblk fails to find the serial number for.
Thanks, this would be a great help.
output of command 1:
[root@san02 ~]# /usr/bin/lsblk -P -o NAME,MODEL,SERIAL,UUID,SIZE
NAME="sda" MODEL="INTEL SSDSC2BF18" SERIAL="CVTS42500092180IGN" UUID="" SIZE="167.7G"
NAME="sda1" MODEL="" SERIAL="" UUID="810538de-bbb9-4dea-9b2c-8eb8564f8ad1" SIZE="500M"
NAME="sda2" MODEL="" SERIAL="" UUID="0529d6e4-cc46-40a6-b0d6-87eea6dd09d5" SIZE="7.9G"
NAME="sda3" MODEL="" SERIAL="" UUID="f1941d9e-23ba-4443-8d86-56c12b9308b5" SIZE="159.3G"
NAME="sdb" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdb1" MODEL="" SERIAL="" UUID="c7c4bbc8-2dd6-4311-9bd3-7ea3297468fd" SIZE="698.7G"
NAME="sdc" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdc1" MODEL="" SERIAL="" UUID="fc13437e-1c1b-47ec-ab2e-b2b04d63f5e3" SIZE="698.7G"
NAME="sdd" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdd1" MODEL="" SERIAL="" UUID="d2b11fde-41d6-4a54-9d99-f988436aa47f" SIZE="698.7G"
NAME="sde" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sde1" MODEL="" SERIAL="" UUID="f6f8ce1e-929f-4fca-bc03-d4be7d634c6f" SIZE="698.7G"
NAME="sdf" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdg" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdh" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdh1" MODEL="" SERIAL="" UUID="42584161-66b0-49a9-93f9-a4026dc49f7c" SIZE="698.7G"
NAME="sdi" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdi1" MODEL="" SERIAL="" UUID="ce5cfa64-4b0f-42d9-b1ba-9830d0701e4a" SIZE="698.7G"
NAME="sdj" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdk" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdl" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdm" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdn" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdo" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdp" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sdq" MODEL="ST3750640NS " SERIAL="001b4d2000000000" UUID="" SIZE="698.7G"
NAME="sr0" MODEL="DVDRAM GT40N " SERIAL="KZSB5V74009" UUID="" SIZE="1024M"
The last 3 outputs:
[root@san02 ~]# udevadm info --name=sdb | grep 'MODEL=\|DEVNAME\|SERIAL'
E: DEVNAME=/dev/sdb
E: ID_MODEL=ST3750640NS
E: ID_SCSI_SERIAL=3QD0B9KW
E: ID_SERIAL=2001b4d2000000000
E: ID_SERIAL_SHORT=001b4d2000000000
[root@san02 ~]# udevadm info --name=sdc | grep 'MODEL=\|DEVNAME\|SERIAL'
E: DEVNAME=/dev/sdc
E: ID_MODEL=ST3750640NS
E: ID_SCSI_SERIAL=3QD08ZWW
E: ID_SERIAL=2001b4d2000000000
E: ID_SERIAL_SHORT=001b4d2000000000
[root@san02 ~]# udevadm info --name=sdd | grep 'MODEL=\|DEVNAME\|SERIAL'
E: DEVNAME=/dev/sdd
E: ID_MODEL=ST3750640NS
E: ID_SCSI_SERIAL=3QD0B9S5
E: ID_SERIAL=2001b4d2000000000
E: ID_SERIAL_SHORT=001b4d2000000000@drancourt That’s great thanks.
So it looks like the current method to acquire device serial numbers with your hardware is not producing unique serial numbers. This is not what I expected as in other cases we have had empty serial numbers via lsblk produce this error but the code also checks for repeats and this is what has triggered the error in your case.
However the proposed udevadm command does seem to be able to distinguish the devices via their SCSI_SERIAL parameter.
The workaround I am in the process of modifying that I though may help here doesn’t apply immediately as lsblk is reporting serial numbers, just not unique ones.
Can you confirm that you have 16 real independent ST3750640NS drives in your system? Also could you post your raid controllers model number. Thanks for helping out with this.
@suman This is a little perplexing as it seems this raid controller is presenting the drive serials (via lsblk at least) as all the same. At least there are unique ones available via the udevadm SCSI_SERIAL. This looks like it may require a reworking of device serial acquisition, or maybe another fail over that re-populates all serials from SCSI_SERIAL if available when repeats are found. This SCSI_SERIAL is definitely not always present though. I am working on a patch re issue#757 I could expand it to do something like SCSI_SERIAL if present, then SERIAL if no SERIAL_SHORT (like virtio and some sdcard drivers), then SERIAL_SHORT if present. else empty and we bottom out. as before. This way it could server this scenario as well. Will need to check for duplicates in the re-scan also though.
@phillxnet forgive me for asking an easy question without doing any research. Does udevadm give us everything we get from lsblk? If so, should we just use udevadm exclusively instead of a complex failover mechanism?
@suman I don’t know but it does seem to be better at serial numbers. I had considered this but what of existing systems that use the serial from lsblk. I think that with the above cascade for serial from udevadm we end up with the same one anyway which would be good but only just considered using it as the primary serial acquisition method really.
Example output from a usb drive so we have the transport, note the SERIAL_SHORT. Only just come across the SCSI_SERIAL in this thread.
udevadm info --name=sdb
P: /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4:1.0/host2/target2:0:0/2:0:0:0/block/sdb
N: sdb
S: disk/by-id/usb-TOSHIBA_MK3276GSX_926286AF8888-0:0
S: disk/by-label/rock-pool
S: disk/by-path/pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0
S: disk/by-uuid/8a0a266e-583c-425a-9c41-391c58f6f131
E: DEVLINKS=/dev/disk/by-id/usb-TOSHIBA_MK3276GSX_926286AF8888-0:0 /dev/disk/by-label/rock-pool /dev/disk/by-path/pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/8a0a266e-583c-425a-9c41-391c58f6f131
E: DEVNAME=/dev/sdb
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4:1.0/host2/target2:0:0/2:0:0:0/block/sdb
E: DEVTYPE=disk
E: ID_BUS=usb
E: ID_FS_LABEL=rock-pool
E: ID_FS_LABEL_ENC=rock-pool
E: ID_FS_TYPE=btrfs
E: ID_FS_USAGE=filesystem
E: ID_FS_UUID=8a0a266e-583c-425a-9c41-391c58f6f131
E: ID_FS_UUID_ENC=8a0a266e-583c-425a-9c41-391c58f6f131
E: ID_FS_UUID_SUB=a4756f82-e3fa-4263-822d-b62250190af4
E: ID_FS_UUID_SUB_ENC=a4756f82-e3fa-4263-822d-b62250190af4
E: ID_INSTANCE=0:0
E: ID_MODEL=MK3276GSX
E: ID_MODEL_ENC=MK3276GSX\x20\x20\x20\x20\x20\x20\x20
E: ID_MODEL_ID=2336
E: ID_PATH=pci-0000:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_00_1d_7-usb-0_4_1_0-scsi-0_0_0_0
E: ID_REVISION=0100
E: ID_SERIAL=TOSHIBA_MK3276GSX_926286AF8888-0:0
E: ID_SERIAL_SHORT=926286AF8888
E: ID_TYPE=disk
E: ID_USB_DRIVER=usb-storage
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=TOSHIBA
E: ID_VENDOR_ENC=TOSHIBA\x20
E: ID_VENDOR_ID=152d
E: MAJOR=8
E: MINOR=16
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=904922
And another from the sdcard reader in the issue referenced to provide extremes:-
udevadm info --name=mmcblk0
P: /devices/pci0000:00/0000:00:1e.0/0000:03:01.1/mmc_host/mmc0/mmc0:b368/block/mmcblk0
N: mmcblk0
S: disk/by-id/mmc-00000_0x1ceff260
E: DEVLINKS=/dev/disk/by-id/mmc-00000_0x1ceff260
E: DEVNAME=/dev/mmcblk0
E: DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:03:01.1/mmc_host/mmc0/mmc0:b368/block/mmcblk0
E: DEVTYPE=disk
E: ID_NAME=00000
E: ID_PART_TABLE_TYPE=dos
E: ID_SERIAL=0x1ceff260
E: MAJOR=179
E: MINOR=0
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=735478
Note we always seem to have an ID_SERIAL= but it is not the same as lsblk has been handing out, that’s more like ID_SERIAL_SHORT which isn’t always there, hence the suggested cascade in acquiring the serial via udevadm.
@phillxnet yes there are 16 independent drives with the same model number. This issue is the same on another 2 arrays as well.
The raid controller itself is an Areca ARC1680IX ver 2.3 it was installed in the system around 2011
@phillxnet @suman @drancourt Sorry just to dive into this thread, but to collect SMART data [for nearly any] drive behind a raid controller is very difficult without any specific driver. JBOD of drives is also the only recommended option to use with Rockstor. Perhaps we need to make an special page for this in the manual?
What does the command > blkid give?
UUID should be used as the preferred way to work with disks.
with 3 disks in raid.
As you can see each disk has still their own UUID 
[quote=“phillxnet, post:3, topic:266”]
ID_SERIAL
[/quote] seems to me that is the manufacturer date?
@TheRavenKing @phillxnet @suman
I’ll have to check it out next week when I can get back to the datacenter to pull the info for blkid
Stand by.
@phillxnet @suman @TheRavenKing
here’s the output of blkid on both machines:
machine 1:
[root@san01 ~]# blkid
/dev/sdb: LABEL=“vm_pool” UUID=“78dfef3c-3b6c-4b8d-8e86-89bd5db1f89c” UUID_SUB=“faa6fbe1-e626-4a31-a9b0-37c602ebfb49” TYPE=“btrfs”
/dev/sdd: LABEL=“vm_pool” UUID=“78dfef3c-3b6c-4b8d-8e86-89bd5db1f89c” UUID_SUB=“a25e9b83-b23a-411a-ab53-ed5fa73cc520” TYPE=“btrfs”
/dev/sdc: LABEL=“vm_pool” UUID=“78dfef3c-3b6c-4b8d-8e86-89bd5db1f89c” UUID_SUB=“878096ba-1bd3-42d2-8453-808ba52eedab” TYPE=“btrfs”
/dev/sde: LABEL=“vm_pool” UUID=“78dfef3c-3b6c-4b8d-8e86-89bd5db1f89c” UUID_SUB=“cab8273a-0d28-4f11-a953-664a749c98fa” TYPE=“btrfs”
/dev/sdq1: UUID=“15d6eb2c-9b4a-402a-b165-09192de4e9f5” TYPE=“ext4”
/dev/sdq2: UUID=“63652669-1ac4-44af-9176-42d859270ce6” TYPE=“swap”
/dev/sdq3: LABEL=“rockstor_rockstor” UUID=“396f41dc-f224-428d-aa66-4131ea3f8163” UUID_SUB=“dc821228-1ad2-40c0-83de-0b67f7ba276e” TYPE=“btrfs”
machine 2:
[root@san02 ~]# blkid
/dev/sda1: UUID=“810538de-bbb9-4dea-9b2c-8eb8564f8ad1” TYPE=“ext4”
/dev/sda2: UUID=“0529d6e4-cc46-40a6-b0d6-87eea6dd09d5” TYPE=“swap”
/dev/sda3: LABEL=“rockstor_rockstor” UUID=“f1941d9e-23ba-4443-8d86-56c12b9308b5” UUID_SUB=“d51d2689-7633-4060-93a2-54a14ddc2f96” TYPE=“btrfs”
/dev/sdc1: UUID=“fc13437e-1c1b-47ec-ab2e-b2b04d63f5e3” TYPE=“xfs” PARTLABEL=“primary” PARTUUID=“de49bb6a-34f6-4946-87b0-4f1defd0dfda”
/dev/sdd1: UUID=“d2b11fde-41d6-4a54-9d99-f988436aa47f” TYPE=“xfs” PARTLABEL=“primary” PARTUUID=“8ad37704-2851-4ee5-916f-0359edaa0860”
/dev/sdb1: UUID=“c7c4bbc8-2dd6-4311-9bd3-7ea3297468fd” TYPE=“xfs” PARTLABEL=“primary” PARTUUID=“b986966f-a64c-4d2b-b472-8ae18ff5a8a3”
/dev/sde1: UUID=“f6f8ce1e-929f-4fca-bc03-d4be7d634c6f” TYPE=“xfs” PARTLABEL=“primary” PARTUUID=“2a49cedb-9f00-4a98-a9e5-71d7866aa433”
/dev/sdh1: UUID=“42584161-66b0-49a9-93f9-a4026dc49f7c” TYPE=“xfs” PARTLABEL=“primary” PARTUUID=“eefdb924-cb3a-4347-bb26-afbae1608511”
/dev/sdi1: UUID=“ce5cfa64-4b0f-42d9-b1ba-9830d0701e4a” TYPE=“xfs” PARTLABEL=“primary” PARTUUID=“52a38ac5-d06d-4c25-92c8-8ab038b0d033”
@drancourt perhaps silly question, but did you DBAN all the drives before installing Rockstor? Looks like the drives have been in a raid before. What also worries me is the Firmware version and if these drive where ment or came out of a Dell or HP server? These have their own firmware, for example: http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=RG1GN
Seagate ST3750640NS Barracuda ES 750GB 7200 RPM 3Gbps SATA Disk Drive. Drive includes latest Firmware Update that addresses performance issues and SMART monitoring. Can be used to replace ST3750640AS (consumer grade), but an AS should not replace ST3750640NS units in servers or SANs!
I did DBAN them before installing rockstor.
They are ST3750640NS drives. Purchased from CDW ages ago. The original software was openfiler some years ago, and have sat in a storage room until recently.
@drancourt Are you able to upgrade your 16 disk Areca raid controller install (JOBD mode) that you had before to the recently released Rockstor 3.8-6 version. The reason is that there is an experimental enhancement to disk serial retrieval that you have already played a part in (in this thread) and I would like to see if it works for you. It will involve some minor editing and a restart but I would be really interested to see if this new method allows for your most hansom 16 disk arrays to spring into Rockstor accessibility. As I understand it your existing data disks have no data on so this makes you / your hw a perfect candidate, especially since you provided info that helped this method come into being in the first place. Are you game, I can talk you through the edit which should be pretty simple?
