Note to plugin authors:

Be VERY aware of interactions when replacing shared libraries when adding plugins and add-ons.

 

I just finished assisting an unRAID user who was trying for days to upgrade a 2TB parity drive to a 3TB one.

The upgrade process kept failing.  The symptom was the parity disk was apparently being accessed past its end.  You can read about it here: http://lime-technology.com/forum/index.php?topic=22265.0

 

The issue was that the"gdisk" command needed to create a GPT partition was failing.  It was failing because an add-on or plugin was replacing a shared library, and that replacement BROKE the gdisk command needed to create the GPT partition needed for disks > 2.2TB.

 

This affects anybody who wishes to upgrade a current smaller disk to one > 2TB and may not be immediately obvious why the upgrade fails.

 

To test if your "gdisk" command works, you can type

gdisk /dev/null

 

If the command complains about not being able to open a shared library:

gdisk: /usr/lib/libstdc++.so.6: version 'GLIBCXC_3.4.11' not found (required by gdisk)

you will NOT be able to add larger disks to your server and possibly other commands are broken too.  (the above command will complain that /dev/null is not a disk, but that is good, because it is not a disk)

 

We do not know which add-on or plugin clobbered the shared library, but it is out there for someone else to have issues.  It might even be a different .so library than libstdc++ which in turn references /usr/lib/libstdc++.so.6: version 'GLIBCXC_3.4.11'

Have fun, but attempt to verify your add-ons and plugins do not break things...    If somebody figures out which plugin/addon is the culprit, it can probably be fixed or we can warn users it is not compatible with current versions of unRAID.

 

Joe L.

You can also check the shared libraries required for a binary with ldd.

for example:

 

#ldd /sbin/fdisk

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

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

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

Linux 2.6.32.9-unRAID.
root@MICRO:~# gdisk /dev/null
-bash: gdisk: command not found

 

I'm running unRAID 4.7.

Linux 2.6.32.9-unRAID.
root@MICRO:~# gdisk /dev/null
-bash: gdisk: command not found

 

I'm running unRAID 4.7.

Since unRAID 4.7 does not support drives over 2.2TB, that is entirely expected. (the "gpart" command is not in any unRAID release prior to 5.0-beta7

(> 2TB drives and GPT partitions were first supported in the 5.0-beta7 release)

You can also check the shared libraries required for a binary with ldd.

for example:

 

#ldd /sbin/fdisk

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

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

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

 

I show this as far as dependencies (notice no mention of  GLIBCXC_3.4.11)

root@Tower2:~# ldd /sbin/gdisk

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

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

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

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

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

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

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

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

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

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

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

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

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

 

You can also check the shared libraries required for a binary with ldd.

for example:

 

#ldd /sbin/fdisk

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

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

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

 

I show this as far as dependencies (notice no mention of  GLIBCXC_3.4.11)

root@Tower2:~# ldd /sbin/gdisk

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Then it's a subordinate dependency.

Since I deal with secure chroot's all the time, I do it until everything resolves.

Unfortunately, it's a pain and there's no automated way to do it without a script. (at least I don't know of another tool to do it yet).

 

root@atlas ~ #ldd /usr/lib/libstdc++.so.6

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

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

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

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

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

root@p5bplus:/boot/extra# gdisk /dev/null

GPT fdisk (gdisk) version 0.8.4

 

The specified path is a character device!

 

 

root@P8H67:~#  gdisk /dev/null

GPT fdisk (gdisk) version 0.8.4

 

The specified path is a character device!

 

so no issue for me i guess

i have following running

 

SSH from unmenu

screen from unmenu

unzip from unmenu

bwm-ng from unmenu

ntfs-3g from unmenu

clean powerdown from unmenu

swapfile from unmenu

unrar from unmenu

 

Plex

simplefeatures

sab

headphones

couchpotato v2

sickbeard

lazylibrarian

utorrent