kernelOfTruth / ZFS-for-SystemRescueCD

SRM kernel modules for SystemRescueCD (Gentoo Linux based) releases, allowing access to zpools running on latest upstream ZFSonLinux code
18 stars 5 forks source link

libgcc_so.1 missing #1

Open simonbuehler opened 10 years ago

simonbuehler commented 10 years ago

hi,

tried your modules and most zdb commands work, but for e.g. zdb -hh -e -r rpool

it fails with libgcc_s.so.1 must be installed for pthread_cancel to work. zsh: abort zdb -hh -e -rpool

any idea how to fix this?

kernelOfTruth commented 10 years ago

Hi,

thanks for reporting this issue

this really seems to be a very multi-faceted "symptom"

but first: running zdb on my system there's no "r" (small r) - only:

-R read and display block from a device

for some the solution was to install openjdk which indicates that I might have to re-compile my gcc-version

for other the rlimit was too stricted

which might point to the fact that some adjustments would need to be made in SystemRescueCD: http://forums.cpanel.net/f5/libgcc_s-so-1-must-installed-pthread_cancel-work-382262.html

another thing comes to mind: could adding a swap and setting

echo 1 > /proc/sys/vm/overcommit_memory
echo 80 > /proc/sys/vm/overcommit_ratio

plus making adjustments with rlimit

as a test help ?

the zfs kernel module is loaded up, right ?

these solutions came up while search for libgcc_s.so.1 must be installed for pthread_cancel to work via google - there might be even more - but these are the first ones worth evaluating

edit:

I'll see if I can make some short tests during the next days to attempt to reproduce

simonbuehler commented 10 years ago

thanks for your response, the -r parameter was not supposed to be there but also without it the result is the same, i'll try your suggestions and report back

kernelOfTruth commented 9 years ago
ldd /sbin/zdb
    linux-vdso.so.1 (0x00007ffe1f58c000)
    libnvpair.so.1 => /lib64/libnvpair.so.1 (0x00007f22e90f9000)
    libuutil.so.1 => /lib64/libuutil.so.1 (0x00007f22e8ee2000)
    libzpool.so.2 => /lib64/libzpool.so.2 (0x00007f22e8ab2000)
    libzfs.so.2 => /lib64/libzfs.so.2 (0x00007f22e8869000)
    libzfs_core.so.1 => /lib64/libzfs_core.so.1 (0x00007f22e8665000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f22e8368000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f22e8164000)
    libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f22e9485000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f22e7f5c000)
    libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f22e947e000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f22e7d43000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f22e7b26000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f22e777c000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f22e9313000)

that's from my current running system

I'm wondering where that referenced libgcc_so.1 might be coming from

...

@simonbuehler could you give https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.5.2 a try and see whether that improves things

I have a suspicion:

In a nutshell the problem might come down to following:

64bit kernel, 64bit app (zdb) ? with 32bit userland and (mostly 32bit) libs ?

so there's not much I can do

http://www-01.ibm.com/support/docview.wss?uid=swg21666144

but the following could work:

https://github.com/travis-ci/travis-ci/issues/1326

simonbuehler commented 9 years ago

sorry for the slow reply but the system to test ist currently broken