I have booted Unraid on my r720xd with a newly flashed IT mode h710p mini d1 SAS card.  Devices are seen normally, all smart status are green, and I am attempting to add disks to the array.  I have successfully added one out of 8, the remaining seven are listed in unassigned devices, and when I attempt to add a disk, it looks like it adds for a split second then returns to "unassigned".

 

I installed the Preclear plugin and erased each disk and its MBR, I've rebooted after resetting the config, I'm not precisely sure what to do from here.  

 

Diags to come after post approval.

See attached diags - this was taken shortly after attempting to add disks, a few minutes after a reboot.

tower-diagnostics-20210419-1433.zip

You have multiple disks showing errors like this:

 

Apr 19 13:42:01 Tower kernel: blk_update_request: critical target error, dev sdb, sector 1953524992 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0

 

According to this post

 

 

it's possibly cable related.

 

 

It is odd... this array was working well in Windows on the pre-flashed Perc h710p, I'm not saying you're wrong but it would be very coincidental for the cables to go between switching OSs.  Plus the Preclean scripts had no issues erasing the disks nor writing zeros across all sectors.

 

When I tail the /var/log/syslog and attempt to add a disk to the array, there is some output with this block seeming to be the most relevant:

 

Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#3435 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s
Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#3435 Sense Key : 0x7 [current] 
Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#3435 ASC=0x20 ASCQ=0x2 
Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#3435 CDB: opcode=0x28 28 00 00 00 00 00 00 00 20 00
Apr 19 15:24:11 Tower kernel: blk_update_request: critical target error, dev sdh, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#5249 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s
Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#5249 Sense Key : 0x7 [current] 
Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#5249 ASC=0x20 ASCQ=0x2 
Apr 19 15:24:11 Tower kernel: sd 1:0:6:0: [sdh] tag#5249 CDB: opcode=0x28 28 00 00 00 00 00 00 00 08 00
Apr 19 15:24:11 Tower kernel: blk_update_request: critical target error, dev sdh, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Apr 19 15:24:11 Tower kernel: Buffer I/O error on dev sdh, logical block 0, async page read
Apr 19 15:24:11 Tower emhttpd: error: ckmbr, 2197: Input/output error (5): read: /dev/sdh
Apr 19 15:24:11 Tower emhttpd: ckmbr error: -1

 

The iDRAC on this box (pre flash) used to show seven out of the eight disks as "secured", I wonder if there isn't some lockdown that Dell has in place that ensures genuine disks or something similar. 

Preclear can't verify the Unraid MBR signature either:

############################################################################################################################
#                                                                                                                          #
#                            unRAID Server: verifying Preclear State of disk  5000c50057ee296b.                            #
#                              Verifying disk '5000c50057ee296b' for unRAID's Preclear State.                              #
#                                                                                                                          #
#                                                                                                                          #
#   Step 1 of 1 - Verifying unRAID's signature:                                                                    FAIL    #
#                                                                                                                          #
#                                                                                                                          #
#                                                                                                                          #
#                                                                                                                          #
#                                                                                                                          #
#                                                                                                                          #
#                                                                                                                          #
#                                                                                                                          #
#                                                                                                                          #
#                                                                                                                          #
#                                                                                                                          #
############################################################################################################################
#                               Cycle elapsed time: 0:00:00 | Total elapsed time: 0:00:00                                  #
############################################################################################################################

--> RESULT: FAIL! /dev/sdb DOESN'T have a valid unRAID MBR signature!!!

 

That sound a bit like Type 2 protection. See this thread:

 

 

But it isn't being reported as such by SMART. Sorry, I don't use SAS disks so I don't know the finer points of using them. Maybe @JorgeB has an idea.

 

1 hour ago, John_M said:

That sound a bit like Type 2 protection. See this thread:

 

 

But it isn't being reported as such by SMART. Sorry, I don't use SAS disks so I don't know the finer points of using them. Maybe @JorgeB has an idea.

 

This thread may help

56 minutes ago, SimonF said:

This thread may help

 

It certainly would if they actually are Type 2 protected, but the SMART reports don't mention it as they do in the linked thread, so I'm not sure.

53 minutes ago, John_M said:

 

It certainly would if they actually are Type 2 protected, but the SMART reports don't mention it as they do in the linked thread, so I'm not sure.

ASC ASCQ seem to suggest an access issue.

ACCESS DENIED - NO ACCESS RIGHTS

 

Inspecting the labels on these drives shows a PSID, which indicates they are SED (self encrypting drives).  According to this article: https://www.truenas.com/docs/core/storage/sed/ you can unlock the drives with the PSID on the label using the sedutils-cli command in TrueNAS.  I'm going to install TrueNAS on a flash drive and see if I can unlock them with those very long PSIDs.  If that doesn't work, I may have to reflash my h710p back to stock and have it remove the locks.

 

Oof, what a pain.  Thanks for all the help, keep your fingers crossed for me.

That was the solution, using the sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID <longPSIDstringhere> /dev/daX command wiped whatever security lock was on the drive and after rebooting from TrueNAS I was able to build my array, all drives adding normally.

 

Thanks again for your assistance, time to populate the array with data!

4 hours ago, ishcabittle said:

That was the solution, using the sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID <longPSIDstringhere> /dev/daX command wiped whatever security lock was on the drive and after rebooting from TrueNAS I was able to build my array, all drives adding normally.

 

Thanks again for your assistance, time to populate the array with data!

Glad you found the solution.