I am in the process of building my first UnRAID server and have run into a roadblock.

 

Pertinent Hardware:

Dell PERC H200 running IT firmware.

HGST Enterprise 8TB SAS drive 

unknown model expander (server has 12 bays and originally had an LSI 9260-8i controller)

 

I originally set up the array as follows:

960GB Samsung 852T x2 as Cache Pool

HGST Enterprise 8TB SATA drive as parity

SAS drive above as parity

2x 8TB Seagate Archive drives as array.

 

the page reported the configuration as good, but hitting start would not do anything. I tried changing the number of devices, reformatting the cache drives, and preclearing the data drives. When I then tried to preclear the SAS drive I noticed that the same issue I was having with the array occurred with preclear script. I would start the preclear, but nothing happened. I could find no errors in the system logs. I tried removing the SAS drive and the array started up and built parity.

 

I had previously noticed that the SAS drive also does not have SMART data that all the other drives (including the SATA drives on the same controller) do. I was worried that maybe there was a hardware problem, but I could ssh in- format and mount the drive manually, and it worked. Using the unassigned devices plugin does not work for mounting the drive through the UI. No error, it just does not do anything.

 

I am stumped as to what the issue is. The only apparent variables are that it is a SAS drive and the system gets no SMART data. The kernel will happily mount and use it, so it would appear to be something other than a hardware problem.

 

Any ideas?

 

I can live on single parity for now, but really wanted the protection of dual.

 

 

 

See if this helps

http://lime-technology.com/forum/index.php?topic=48508.msg500313#msg500313

Hi Johnnie,

 

Thanks for the assist. That setting seemed to help, but not fully. Now when I add the disk to the parity it shows a blue box next to it instead of grey, but it still does nothing when I try to start the array and Parity-Sync. No error, no message, it just does nothing.

 

 

Post your diagnostics after trying to add the disk and starting the array.

Here you go. I spotted nothing other than unrelated SMB issues.

 

tower-diagnostics-20170313-1613.zip

Problem is almost certainly because of this invalid partition error:
 

Mar 13 16:13:21 Tower root: Creating new GPT entries.
Mar 13 16:13:21 Tower root: The operation has completed successfully.
Mar 13 16:13:21 Tower kernel: sde: sde1
Mar 13 16:13:21 Tower emhttp: shcmd (587): udevadm settle
Mar 13 16:13:21 Tower emhttp: invalid partition(s)
Mar 13 16:13:21 Tower emhttp: shcmd (588): rmmod md-mod |& logger
Mar 13 16:13:21 Tower kernel: md: unRAID driver removed

Can you post the output of:

 

sgdisk -p /dev/sde

 

Here you go. I had not looked at the detailed output, but I had compared the description with the other 8TB drive. Now it is true, I did not preclear this drive after changing the display setting.

 

Disk /dev/sde: 1953506646 sectors, 7.3 TiB
Logical sector size: 4096 bytes
Disk identifier (GUID): 797F2BFA-3E2B-409D-B5A9-BC0C16450B85
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 1953506640
Partitions will be aligned on 64-sector boundaries
Total free space is 58 sectors (232.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              64      1953506640   7.3 TiB     8300

 

 

I tried deleting the partition table using parted and then trying again, it recreates the partition but still does not work.

 

Thanks

Edited March 14, 20179 yr by ssb201

Partition looks normal, don't know why it's not accepting it, try this:

 

In case you rebooted in the meantime double check sde is still parity2, if yes first destroy current partition:

 

sgdisk -Z /dev/sde

then create a new one:

sgdisk -o -a 64 -n 1:64:0 /dev/sde

Try to assign it again and starting the array, if still doesn't work grab and post new diags.

No. Same thing happens.

tower-diagnostics-20170313-1713.zip

No more ideas, I posted on the release thread to see if someone from LT can take a look.

Thanks. It really is puzzling.

4 hours ago, ssb201 said:

Thanks. It really is puzzling.

 

The message "invalid partitions(s)" means that after using 'sgdisk' to write a GPT partition, upon read-back, the exact GPT partition layout, including contents of the protective-MBR is not the same as what was written.  Usually this might happen due to disk error, but if that happened there would have been a syslog entry for that as well.  Indeed puzzling.

 

There is one odd message in the syslog:

 

Mar 13 14:35:30 Tower kernel: BTRFS: device fsid 78f1f644-dea0-4e1d-a352-abbf2b21afc6 devid 1 transid 10 /dev/sde

This happens near start of boot up, when btrfs file system is loading.  There is a subsystem called "blkid" that btrfs uses to keep a small in-memory database of the overall system btrfs configuration.  Apparently this particular device was once formatted with btrfs as a "whole device", that is, not in a partition (there are no partitions).  All I can think might be happening is unRaid tries to write a GPT but then blkid says, "hey this is supposed to be btrfs" so it goes and restores something in the MBR so that it continues to be recognized.  This is a rather common "issue" with btrfs (I call it an issue): once a device/partition has been formatted with btrfs it's difficult to purge it off that device/partition.

 

I suggest trying something like this:

 

wipefs -a /dev/sde

 

See if that works.  If not, something more drastic:

 

dd if=/dev/zero of=/dev/sde bs=1M count=1

 

But be very careful with above commands, that "/dev/sde" is indeed the problematic device.

So I ran wipefs and saw:

 

/dev/sde: 8 bytes were erased at offset 0x00010040 (btrfs): 5f 42 48 52 66 53 5f 4d
/dev/sde: 8 bytes were erased at offset 0x00001000 (gpt): 45 46 49 20 50 41 52 54
/dev/sde: 8 bytes were erased at offset 0x74702555000 (gpt): 45 46 49 20 50 41 52 54
/dev/sde: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
/dev/sde: calling ioctl to re-read partition table: Success

 

I then tried to add the drive as my second parity drive and still does not work.

 

syslog still shows:

Mar 15 13:32:23 Tower emhttp: shcmd (4003): sgdisk -Z /dev/sde &> /dev/null
Mar 15 13:32:23 Tower kernel: sde: sde1
Mar 15 13:32:24 Tower emhttp: shcmd (4004): sgdisk -o -a 64 -n 1:64:0 /dev/sde |& logger
Mar 15 13:32:25 Tower root: Creating new GPT entries.
Mar 15 13:32:25 Tower root: The operation has completed successfully.
Mar 15 13:32:25 Tower kernel: sde: sde1
Mar 15 13:32:25 Tower emhttp: shcmd (4005): udevadm settle
Mar 15 13:32:25 Tower emhttp: invalid partition(s)
Mar 15 13:32:25 Tower emhttp: shcmd (4006): rmmod md-mod |& logger
Mar 15 13:32:25 Tower kernel: md: unRAID driver removed

 

 

Edited March 15, 20179 yr by ssb201

Try dd

 

On 14/03/2017 at 5:05 AM, limetech said:

See if that works.  If not, something more drastic:

 

dd if=/dev/zero of=/dev/sde bs=1M count=1

 

But be very careful with above commands, that "/dev/sde" is indeed the problematic device.

 

Same error.

You could try preclearing the disk but doubt that will help since all the partition info is on the first few sectors, maybe Tom has other suggestions.

I tried preclearing without any success. I am hoping this is a bug that the lime-tech guys can get to the bottom of. The only other option I can see is using snapraid to get semi-equivalent parity protection using the drive. 

Edited March 16, 20179 yr by ssb201

Can you post the output of:

 

dd if=/dev/sde bs=2048 count=1 | hexdump -C

 

Assuming disk is still sde and after trying to add it to the array.

Edited March 17, 20179 yr by johnnie.black

I'm also having the same exact issue. New 8tb drive assigned to parity will keep giving the "invalid partition" error. Successfully precleared the drive too. Had to go back to my current array of 4tb drives in order to use my system.

The output from the hexdump:

 

root@Tower:/# dd if=/dev/sde bs=2048 count=1 | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
1+0 records in
1+0 records out
*
000001c0  02 00 ee ff ff ff 01 00  00 00 55 25 70 74 00 00  |..........U%pt..|
2048 bytes (2.0 kB, 2.0 KiB) copied, 0.000467479 s, 4.4 MB/s000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800
 

@limetech Just notice this, pretty sure this is the problem:

 

Mar 13 14:35:30 Tower kernel: sd 1:0:1:0: [sde] 1953506646 4096-byte logical blocks: (8.00 TB/7.28 TiB)

 

I believe 4Kn disks are currently not supported by unRAID.

 

There is a similar 512e model ( HUH728080AL5200 instead of HUH728080AL4200)

 

 

Edited March 17, 20179 yr by johnnie.black

36 minutes ago, xodusgenesis said:

I'm also having the same exact issue

 

Disk model or syslog? is it 4Kn also?

Edited March 17, 20179 yr by johnnie.black

That would explain it. I hope support comes soon. I do not have another 8TB drive hanging around at the moment.

Nice find johnnie.black!  Damn I should have seen that... That particular model HUH728080AL4200 is indeed a 4K-logical-sector size device:

https://www.hgst.com/sites/default/files/resources/Ultrastar-He8-DS.pdf

 

...and right, unRaid OS does not properly handle that at present.

When are 4Kn drives expected to be supported? I have the same 8tb drives but as SATA.