Need help upgrading to 3TB drives, please.

 

I've got a pair of WD 3TB Red drives that I'd like to add to my array.  One as the new parity drive, the other as a data drive.

 

My unRaid:

 

unRAID Server Pro version: 5.0-rc11

Intel® Core2 Duo CPU    E7500

Supermicro X7SB4/E - BIOS 2.0a

4GB Ram

SASLP-MV8 x 2 - Firmware version 3.1.0.21

2TB Green drives x 12 (Data & Parity)

1TB Green drive x1 (Data)

250GB Cache drive

 

Both new drives have passed several pre-clears, but when I exchange one of them for my parity drive it fails.  I've tried several times.

 

Here is the re-clear report for the "new" parity drive and the other one.

 

Here is the system log after failed parity-sync.

 

I have been in contact with SuperMicro support and was told that my motherboard would support 3TB drives with my current BIOS.

 

This forum thread seems to indicate that 3TB drives are supported on the SASLP-MV8s with my current firmware.

 

I have been pre-clearing the drives with them attached to the expansion cards, but then moving the drive to the specific location in my server that I have designated for the parity drive (which is connected directly to the MoBo).

 

This appears to be the relevant portion of the system log:  "Attempt to read past end of device"  "handle stripe write error":

Mar 23 21:40:42 Tower kernel: md: recovery thread woken up ...

Mar 23 21:40:42 Tower kernel: md: recovery thread syncing parity disk ...

Mar 23 21:40:43 Tower emhttp: shcmd (97): :>/etc/samba/smb-shares.conf

Mar 23 21:40:43 Tower emhttp: get_config_idx: fopen /boot/config/shares/AACC Backups.cfg: No such file or directory - assigning defaults

Mar 23 21:40:43 Tower kernel: md: using 1536k window, over a total of 2930266532 blocks.

Mar 23 21:40:43 Tower emhttp: Restart SMB...

Mar 23 21:40:43 Tower emhttp: shcmd (98): killall -HUP smbd

Mar 23 21:40:43 Tower emhttp: shcmd (99): ps axc | grep -q rpc.mountd

Mar 23 21:40:43 Tower emhttp: _shcmd: shcmd (99): exit status: 1

Mar 23 21:40:43 Tower emhttp: shcmd (100): /usr/local/sbin/emhttp_event svcs_restarted

Mar 23 21:40:43 Tower emhttp_event: svcs_restarted

Mar 23 22:37:01 Tower crond[1309]: ignoring /var/spool/cron/crontabs/root- (non-existent user)

Mar 23 23:37:01 Tower crond[1309]: ignoring /var/spool/cron/crontabs/root- (non-existent user)

Mar 24 00:37:01 Tower crond[1309]: ignoring /var/spool/cron/crontabs/root- (non-existent user)

Mar 24 01:37:01 Tower crond[1309]: ignoring /var/spool/cron/crontabs/root- (non-existent user)

Mar 24 02:37:01 Tower crond[1309]: ignoring /var/spool/cron/crontabs/root- (non-existent user)

Mar 24 03:37:01 Tower crond[1309]: ignoring /var/spool/cron/crontabs/root- (non-existent user)

Mar 24 03:40:01 Tower logger: mover started

Mar 24 03:40:01 Tower logger: skipping */

Mar 24 03:40:01 Tower logger: mover finished

Mar 24 04:37:01 Tower crond[1309]: ignoring /var/spool/cron/crontabs/root- (non-existent user)

Mar 24 05:37:01 Tower crond[1309]: ignoring /var/spool/cron/crontabs/root- (non-existent user)

Mar 24 06:20:14 Tower kernel: attempt to access beyond end of device

Mar 24 06:20:14 Tower kernel: sda1: rw=1, want=4294967296, limit=4294967295

Mar 24 06:20:14 Tower kernel: md: disk0 write error

Mar 24 06:20:14 Tower kernel: attempt to access beyond end of device

Mar 24 06:20:14 Tower kernel: sda1: rw=1, want=4294967304, limit=4294967295

Mar 24 06:20:14 Tower kernel: handle_stripe write error: 4294967288/0, count: 1

Mar 24 06:20:14 Tower kernel: md: md_do_sync: got signal, exit...

Mar 24 06:20:14 Tower kernel: md: disk0 write error

Mar 24 06:20:14 Tower kernel: handle_stripe write error: 4294967296/0, count: 1

Mar 24 06:20:14 Tower kernel: md: recovery thread sync completion status: -4

Mar 24 06:20:14 Tower kernel: md: recovery thread woken up ...

Mar 24 06:20:14 Tower kernel: md: recovery thread has nothing to resync

 

I've read elsewhere here that this is due to actually having a 2TB partition on the 3TB drive.  Is this correct?  If so, how do I correct it?

 

I also saw elsewhere here that someone had success with parity-sync after this error by doing it in Maintenance Mode.  While I don't know if/why this would make a difference, I'm trying it now.

 

I'm open to buying new hardware if necessary, but it seems that my current stuff should work.

 

Possibly unrelated but I have not updated the Adaptec Ultra320 drivers for the motherboard since I purchased it.  Since I don't really understand what that controller does, I just thought that I would mention it.

 

Thanks in advance

 

John

System_Log_Parity_Sync_Failed.txt

See my sig to disable all add-ons and then try again.

See my sig to disable all add-ons and then try again.

The issue is this:

Mar 23 21:40:36 Tower emhttp: writing GPT on disk (sda), with partition 1 offset 64, erased: 0

Mar 23 21:40:36 Tower emhttp: shcmd (34): sgdisk -Z /dev/sda &> /dev/null

Mar 23 21:40:36 Tower emhttp: _shcmd: shcmd (34): exit status: 1

Mar 23 21:40:36 Tower emhttp: shcmd (35): sgdisk -o -a 64 -n 1:64:0 /dev/sda |& logger

Mar 23 21:40:36 Tower logger: sgdisk: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by sgdisk)

One of your add-ons messed with the shared library nneeded by the program that creates the GPT partition on your new disk.  The partition was not created properly.

 

The library being missing is very serious, as who knows what other commands it might affect.  It might be that some other library changed by an add-on now requires /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11'  where it is not required otherwise in a stock unRAID system.

 

My stock version of unRAID needs:

root@Tower:~# ldd /sbin/sgdisk

        linux-gate.so.1 =>  (0xb77d9000)

        libicuio.so.44 => /usr/lib/libicuio.so.44 (0xb77c9000)

        libicuuc.so.44 => /usr/lib/libicuuc.so.44 (0xb7693000)

        libuuid.so.1 => /lib/libuuid.so.1 (0xb768f000)

        libpopt.so.0 => /lib/libpopt.so.0 (0xb7688000)

        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7597000)

        libm.so.6 => /lib/libm.so.6 (0xb7571000)

        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb7554000)

        libc.so.6 => /lib/libc.so.6 (0xb73f1000)

        libpthread.so.0 => /lib/libpthread.so.0 (0xb73d8000)

        libicudata.so.44 => /usr/lib/libicudata.so.44 (0xb659a000)

        libicui18n.so.44 => /usr/lib/libicui18n.so.44 (0xb63c3000)

        libdl.so.2 => /lib/libdl.so.2 (0xb63bf000)

        /lib/ld-linux.so.2 (0xb77da000)

 

The only way I know of to fix this is to reboot with your add-ons disabled

make sure the new 3TB drive is still /dev/sda (otherwise when you run the next command it will be on the wrong disk)

then un-assign the new 3TB parity disk

then type the same commands as was originally attempted to format that disk.

 

/sbin/sgdisk -Z /dev/sda

/sbin/sgdisk -o -a 64 -n 1:64:0 /dev/sda |& logger

Then, re-assign the new parity disk.

 

The reason your original parity sync failed is that there was no GPT partition properly created.  It appears as if the exit status of the sgdisk command is being ignored, and probably should not be ignored.  That way, a failure to create the GPT partition would be detected.  In the same way, perhaps the output of sgdisk -Z should not be sent to /dev/null. Since unRAID would benefit by those changes, please send Tom an email or PM pointing him to this thread and what I discovered.

 

You must finally figure out which of your add-ons clobbered the shared libraries.  You can simply type

sgdisk

on the command line.  If working properly, it should show you its usage display.  If not, you'll get the missing library error. 

 

Re-install one add-on at a time, test by typing "sgdisk" after each install... let us know which is clobbering the shared library.

 

Joe L.

Thanks for the replies guys.

 

Just to make sure, I don't need to run pre-clear again on the drive.  Correct?

Thanks for the replies guys.

 

Just to make sure, I don't need to run pre-clear again on the drive.  Correct?

If you are adding it to an existing array, replacing the existing parity drive, you do not need to preclear it again.

See my sig to disable all add-ons and then try again.

 

Just FYI, I do not have an "Extra" folder on my flash

See my sig to disable all add-ons and then try again.

 

Just FYI, I do not have an "Extra" folder on my flash

then you probably have nothing in it. 

 

You would have had to create it if you were to use it to install a "package" at server boot.

then you probably have nothing in it. 

 

You would have had to create it if you were to use it to install a "package" at server boot.

 

I recently upgraded from 4.7. I do have a "packages" folder that I did not edit.

 

 

 

SUCCESS!!!

 

Gentlemen, thank you both very much.  I never would have figured that out on my own.

 

I wish I could buy you guys a couple beers...

 

I'll try to work on re-installing my add-ons this weekend and seeing which one was causing the problem.

The reason your original parity sync failed is that there was no GPT partition properly created.  It appears as if the exit status of the sgdisk command is being ignored, and probably should not be ignored.  That way, a failure to create the GPT partition would be detected.  In the same way, perhaps the output of sgdisk -Z should not be sent to /dev/null. Since unRAID would benefit by those changes, please send Tom an email or PM pointing him to this thread and what I discovered.

 

You must finally figure out which of your add-ons clobbered the shared libraries.  You can simply type

sgdisk

on the command line.  If working properly, it should show you its usage display.  If not, you'll get the missing library error.

 

Re-install one add-on at a time, test by typing "sgdisk" after each install... let us know which is clobbering the shared library.

 

Joe L.

 

Joe, I've re-installed unMenu, and it does not appear to be the problem.  However, I subsequently re-installed "Clean Powerdown" and set it to re-install after reboot.

 

"sgdisk" check out just fine after this, but I'm not sure if I should reboot after each new install.

 

I've got the pre-clear running on my old parity disk, so I don't want to reboot right now.

 

Should I wait and reboot after each new add-on install?  Or can I install and check without rebooting?

The reason your original parity sync failed is that there was no GPT partition properly created.  It appears as if the exit status of the sgdisk command is being ignored, and probably should not be ignored.  That way, a failure to create the GPT partition would be detected.  In the same way, perhaps the output of sgdisk -Z should not be sent to /dev/null. Since unRAID would benefit by those changes, please send Tom an email or PM pointing him to this thread and what I discovered.

 

You must finally figure out which of your add-ons clobbered the shared libraries.  You can simply type

sgdisk

on the command line.  If working properly, it should show you its usage display.  If not, you'll get the missing library error.

 

Re-install one add-on at a time, test by typing "sgdisk" after each install... let us know which is clobbering the shared library.

 

Joe L.

 

Joe, I've re-installed unMenu, and it does not appear to be the problem.  However, I subsequently re-installed "Clean Powerdown" and set it to re-install after reboot.

 

"sgdisk" check out just fine after this, but I'm not sure if I should reboot after each new install.

I've got the pre-clear running on my old parity disk, so I don't want to reboot right now.

 

Should I wait and reboot after each new add-on install?  Or can I install and check without rebooting?

I don't think you'll need to reboot after each install, but you can test sgdisk after each install.

 

You will need to reboot once the shared library gets clobbered though (and sgdisk stops working), but hopefully, at that time, the culprit will be the last thing installed.

 

Thanks

 

I'll work on it.

Installed "unraid web" from the unmenu package manager....

 

'GLIBCXX_3.4.11' not found (required by sgdisk)

 

Looks like that is the problem....?

Installed "unraid web" from the unmenu package manager....

 

'GLIBCXX_3.4.11' not found (required by sgdisk)

 

Looks like that is the problem....?

It is a package that was written by bubbaQ long ago for a much older version of unRAID.  I guess it breaks things in 5.0 these days when it installs an incompatible version of one of the shared libraries.

 

Joe L.

Sent a PM to bubbaQ, alerting him to the issue.

 

I can do without unRaid Web, but I only recently discovered it and liked it quite a bit.

 

Hopefully, he'll have some thoughts about how to fix it.

 

Thanks again for your help,

 

John