Unable to mount RAID10 array after reinstall

Support
1

I was able to install and operate Rockstor (unsure which version) on an old SD card in a Raspberry Pi 4 in an Argon 40 EON chassis, mount and configure my RAID10 array, and configure and access my media on a SAMBA share at will, all by following the documentation provided by and on the Rockstor website. As my level of confidence as it pertains to Linux is 0.3/10, I consider this a great feat.
I assume the old SDcard quit working, because I could no longer access 4 4TB drives of media in a RAID10 configuration, and I could not read the SDcard when moved to a USB slot on my Windows machine.

I bought a new card and installed Rockstor 5.0.15. It functions properly.

My trouble comes in trying to recover my media on the RAID array. I cannot currently mount/configure/read/access my RAID array no matter what step I follow in the online documentation. Web searches have yielded no solution.
Storage->Disks shows my SD Card and the four RAID drives.
All of these drives report as NOT SUPPORTED by S.M.A.R.T.
Two of the drives in the RAID array show as duplicates, I assume because they are mirrors of the two striped volumes.

image
image1365Ă—612 99.1 KB

I have reached the limits of my knowledge and ability. I am not convinced that I am not the root cause of my issue. I’d like to recover the data on the RAID drives, as opposed to reformatting them.

2

@IdiotEndUser welcome to the Rockstor community. I suspect that the argon chassis might create issues with the serial numbers (i.e. not unique, or changing) hence you’re seeing some duplication and error messages.

Would you be able to run at the command line, either through the WebUI or if you have a terminal connection (like PuTTy):

/usr/bin/lsblk -P -p -o NAME,MODEL,SERIAL,SIZE,TRAN,VENDOR,HCTL,TYPE,FSTYPE,LABEL,UUID

that should show how/what the serial number looks like.

2 Likes
3

That may be the case. I have since admitted defeat in trying to preserve my previous media. I replaced the hard drives and began anew.

I did run the command you requested anyway, in hopes to help you confirm your suspicions. Output follows:

NAME=“/dev/sda” MODEL=“Samsung SSD 870 EVO 4TB” SERIAL=“S757NL0XB03290T” SIZE=“3.6T” TRAN=“usb” VENDOR=“Pinas " HCTL=“0:0:0:0” TYPE=“disk” F
STYPE=“btrfs” LABEL=“Shelves” UUID=“a3c8a42c-54b2-4604-9f36-9e8f246bfc05”
NAME=”/dev/sdb" MODEL=“Samsung SSD 870 EVO 4TB” SERIAL=“S757NL0XA04282J” SIZE=“3.6T” TRAN=“usb” VENDOR=“Pinas " HCTL=“0:0:0:1” TYPE=“disk” F
STYPE=“btrfs” LABEL=“Shelves” UUID=“a3c8a42c-54b2-4604-9f36-9e8f246bfc05”
NAME=”/dev/sdc" MODEL=“Samsung SSD 870 EVO 4TB” SERIAL=“S757NL0X901338X” SIZE=“3.6T” TRAN=“usb” VENDOR=“Pinas " HCTL=“1:0:0:0” TYPE=“disk” F
STYPE=“btrfs” LABEL=“Shelves” UUID=“a3c8a42c-54b2-4604-9f36-9e8f246bfc05”
NAME=”/dev/sdd" MODEL=“Samsung SSD 870 EVO 4TB” SERIAL=“S757NL0X901415X” SIZE=“3.6T” TRAN=“usb” VENDOR=“Pinas " HCTL=“1:0:0:1” TYPE=“disk” F
STYPE=“btrfs” LABEL=“Shelves” UUID=“a3c8a42c-54b2-4604-9f36-9e8f246bfc05”
NAME=”/dev/mmcblk0" MODEL=“” SERIAL=“0x435c2f41” SIZE=“28.8G” TRAN=“mmc” VENDOR=“” HCTL=“” TYPE=“disk” FSTYPE=“” LABEL=“” UUID=“”
NAME=“/dev/mmcblk0p1” MODEL=“” SERIAL=“” SIZE=“64M” TRAN=“mmc” VENDOR=“” HCTL=“” TYPE=“part” FSTYPE=“vfat” LABEL=“EFI” UUID=“A8DE-4F1F”
NAME=“/dev/mmcblk0p2” MODEL=“” SERIAL=“” SIZE=“2G” TRAN=“mmc” VENDOR=“” HCTL=“” TYPE=“part” FSTYPE=“swap” LABEL=“SWAP” UUID=“32a4c2bc-c35e-4eb
e-86c7-673f352a17b4”
NAME=“/dev/mmcblk0p3” MODEL=“” SERIAL=“” SIZE=“26.7G” TRAN=“mmc” VENDOR=“” HCTL=“” TYPE=“part” FSTYPE=“btrfs” LABEL=“ROOT” UUID=“00dfba17-220d
-435e-bc46-0e9919ef1050”

4

Sorry to hear that you had to start over.

Your printout seems to show the same UUID=a3c8a42c-54b2-4604-9f36-9e8f246bfc05 for 4 of the devices, and since Rockstor relies on unique serial numbers, (can be seen under the path /dev/disk/by-uuid/<uuid> it’s getting confused on what belongs where to whom …

NAME=“/dev/sda” MODEL=“Samsung SSD 870 EVO 4TB” SERIAL=“S757NL0XB03290T” SIZE=“3.6T” TRAN=“usb” VENDOR=“Pinas " HCTL=“0:0:0:0” TYPE=“disk” F
STYPE=“btrfs” LABEL=“Shelves” UUID=“a3c8a42c-54b2-4604-9f36-9e8f246bfc05”
NAME=”/dev/sdb" MODEL=“Samsung SSD 870 EVO 4TB” SERIAL=“S757NL0XA04282J” SIZE=“3.6T” TRAN=“usb” VENDOR=“Pinas " HCTL=“0:0:0:1” TYPE=“disk” F
STYPE=“btrfs” LABEL=“Shelves” UUID=“a3c8a42c-54b2-4604-9f36-9e8f246bfc05”
NAME=”/dev/sdc" MODEL=“Samsung SSD 870 EVO 4TB” SERIAL=“S757NL0X901338X” SIZE=“3.6T” TRAN=“usb” VENDOR=“Pinas " HCTL=“1:0:0:0” TYPE=“disk” F
STYPE=“btrfs” LABEL=“Shelves” UUID=“a3c8a42c-54b2-4604-9f36-9e8f246bfc05”
NAME=”/dev/sdd" MODEL=“Samsung SSD 870 EVO 4TB” SERIAL=“S757NL0X901415X” SIZE=“3.6T” TRAN=“usb” VENDOR=“Pinas " HCTL=“1:0:0:1” TYPE=“disk” F
STYPE=“btrfs” LABEL=“Shelves” UUID=“a3c8a42c-54b2-4604-9f36-9e8f246bfc05”

So, I think the Argon EON is not well-suited for Rockstor in this scenario. This issue does occur more frequently when USB based setups are used, because the disk UUIDs are not passed through by certain controllers.

1 Like
5

@Hooverdan Am I reading this incorrectly?

Serial in your quoted output is unique: the uuid references the fs found on the device I believe.

I.e.:

SERIAL=“S757NL0XB03290T”
SERIAL=“S757NL0XA04282J”
SERIAL=“S757NL0X901338X”
SERIAL=“S757NL0X901415X”

They appear unique, UUID comes form the formatting, a pool mostly likely. And if it’s one pool across all disks then it will be the same. Sorry only taken a quick look/read here so may have the wrong end of the stick :slight_smile: .

I.e. I think not:

is correct if we swap SERIAL for your UUID i.e.:

… because the disk SERIALs are not passed through by certain controllers.

which as you say:

But those numbers are not from:

but from the by-id directory instead:

/dev/disk/by-id/

and contained within the names used there. We strip these serial out from the partition info if there is any. The serials of each drive: which are also available via stickers on the phsical drives, are unique to the drive itself,especially when combined as they are with the bustype-modelnumber-serial-partition as per that directories entries.

So likely

[quote=“Hooverdan, post:4, topic:10372”]
the Argon EON
[/quote]

Does look to be passing unique serials through OK. But again I’ve only done a quick read here so may have missed something.

Hope that helps.

6

@Hooverdan OK I see now my confusion.

UUID vs SERIAL command correct in my last post.

But it appears I missed the history here. Hardware change since original issue so yes, Argon EON may well have obscured the serials and merged them all into one. We would need the output from when that enclosure was attached to prove this. But highlly likely that was the case if there were duplicate serials back-then; but not in the working output where that device was no-longer in play.

My apologies for missing this history on first read.

7

Thanks for setting me straight on UUID vs. Serial. I thought both of them had to be unique …

1 Like