Errors Trying to add Hitachi 4TB Drive

[ecuster]

I finally bit the bullet and built a new unRAID ESXi system, but I am now having a problem adding a new Hitachi 4.0TB drive.

 

The system configuration is:

SuperMicro X9SCM-F

Intel Xeon E3-1230v2

2x 8GB ECC DIMMs - 16GB Total RAM

LSI 9201-i16

ESXi v5.5

unRAID v5.0.4

5 Seagate 5900RPM 2TB drives - 1 is Parity

2 WD Green 2TB drives

 

I ran 2 cycles of preclear on a new Hitachi HDS724040ALE640 drive and did not see any errors, but it is possible that I am missing something in the output.  I then tried to upgrade the Parity drive from 2TB to 4TB and received a number of "attempt to access beyond end of device" messages and then a number of write error messages.  I am attaching the preclear output and the syslog.  Can someone shed some light on what I may have done wrong or missed or does this drive need to be RMAed?

20131215_-_Hitachi_4.0TB_HDS724040ALE640-PKV331P1GNK6HY_PreClear.zip

20131216_-_unRAID01_System_Log.zip

[garycase]

Did you Stop the array; unassign the old parity drive; Start the array to get the "missing drive" message; then Stop it again and assign the new 4TB drive; and then Start it again to start the rebuild?

 

If that process didn't work; you can simply do a New Config and be CERTAIN you assign the correct drives as data and the new 4TB drive as parity.    If you do this, however, be sure you don't accidentally assign the old parity drive as a data drive.

 

[ecuster]

Hi garycase,

 

To clarify, after I completed the 2 passes of preclear I powered down the server and pulled the old 2TB out of the drive bay and put the new 4TB drive in its place.  I then powered up the machine and restarted unRAID.  At that point the parity disk entry said "no device", I selected the new 4TB drive and started the array, which also started a parity sync.  It appears to me that unRAID generated all of the errors past the boundaries of the 4TB drive.

 

I just tried your second approach of doing a new config but unRAID is still giving me the same warning messages "attempt to access beyond end of device" and the same disk write errors past the end of the device.

 

In the past when I upgraded from 1TB to 1.5TB drives and then from 1.5TB drives to 2TB drives I never saw anything like this.  Why is unRAID trying to access beyond the end of the device?  Is unRAID not getting the correct drive parameters?  Has anyone else run into these type of errors?

 

 

[BRiT]

Send an email/PM to Tom to get advice by making him aware of the issue.

 

When I saw this error, it was due to a bad partition table that only had the drive set as 2.2tb so as soon as it crossed that boundary is when it would get the errors.

[prostuff1]

What version of preclear did you use?

[ecuster]

I ran version 1.14 of preclear.

[RobJ]

The kernel identified both Hitachis correctly, as 4TB, but sgdisk appears to be missing the correct version of a dependency, so did not prepare the 4TB partition.  (The first Hitachi is sdb with one partition, the second was sdf with 'unknown partition table'.)

 

Dec 15 21:23:41 TMCINAS02 emhttp: writing GPT on disk (sdb), with partition 1 offset 64, erased: 0

Dec 15 21:23:41 TMCINAS02 emhttp: shcmd (25): sgdisk -Z /dev/sdb $stuff$> /dev/null

Dec 15 21:23:41 TMCINAS02 emhttp: _shcmd: shcmd (25): exit status: 1

Dec 15 21:23:41 TMCINAS02 emhttp: shcmd (26): sgdisk -o -a 64 -n 1:64:0 /dev/sdb |$stuff$ logger

Dec 15 21:23:41 TMCINAS02 logger: sgdisk: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by sgdisk)

Dec 15 21:23:41 TMCINAS02 logger: sgdisk: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by sgdisk)

Dec 15 21:23:41 TMCINAS02 logger: sgdisk: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /usr/lib/libicuio.so.44)

Dec 15 21:23:41 TMCINAS02 emhttp: shcmd (27): udevadm settle

Dec 15 21:23:42 TMCINAS02 emhttp: Start array...

Dec 15 21:23:42 TMCINAS02 kernel: mdcmd (42): start UPGRADE_DISK

Dec 15 21:23:42 TMCINAS02 kernel: unraid: allocating 39140K for 1280 stripes (7 disks)

Dec 15 21:23:42 TMCINAS02 kernel: md1: running, size: 1953514552 blocks

...

 

I suspect you could reload v5.0 and prepare the 4TB drives, then reload v5.0.4.

[BRiT]

The kernel identified both Hitachis correctly, as 4TB, but sgdisk appears to be missing the correct version of a dependency, so did not prepare the 4TB partition.  (The first Hitachi is sdb with one partition, the second was sdf with 'unknown partition table'.)

 

Dec 15 21:23:41 TMCINAS02 emhttp: writing GPT on disk (sdb), with partition 1 offset 64, erased: 0

Dec 15 21:23:41 TMCINAS02 emhttp: shcmd (25): sgdisk -Z /dev/sdb $stuff$> /dev/null

Dec 15 21:23:41 TMCINAS02 emhttp: _shcmd: shcmd (25): exit status: 1

Dec 15 21:23:41 TMCINAS02 emhttp: shcmd (26): sgdisk -o -a 64 -n 1:64:0 /dev/sdb |$stuff$ logger

Dec 15 21:23:41 TMCINAS02 logger: sgdisk: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by sgdisk)

Dec 15 21:23:41 TMCINAS02 logger: sgdisk: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by sgdisk)

Dec 15 21:23:41 TMCINAS02 logger: sgdisk: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /usr/lib/libicuio.so.44)

Dec 15 21:23:41 TMCINAS02 emhttp: shcmd (27): udevadm settle

Dec 15 21:23:42 TMCINAS02 emhttp: Start array...

Dec 15 21:23:42 TMCINAS02 kernel: mdcmd (42): start UPGRADE_DISK

Dec 15 21:23:42 TMCINAS02 kernel: unraid: allocating 39140K for 1280 stripes (7 disks)

Dec 15 21:23:42 TMCINAS02 kernel: md1: running, size: 1953514552 blocks

...

 

I suspect you could reload v5.0 and prepare the 4TB drives, then reload v5.0.4.

 

So the suggested coarse of action is to try addi g the drive with ALL plugins and addons removed and with stock GO file.

[ecuster]

Thank you everyone.  I removed all plugins and went back to the original GO script and everything worked this time around.  When I have some time I will try adding the plugins one at a time to see if I can figure out which one was causing the problem. 

 

Thanks again for helping me get this solved and the array back online.