Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 307439 - sys-fs/dmraid-1.0.0_rc16-rc1 is not loaded beacaus pthread_mutex_trylock is undefined symbol
Summary: sys-fs/dmraid-1.0.0_rc16-rc1 is not loaded beacaus pt...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: No maintainer - Look at if you want to take care of it
Depends on:
Reported: 2010-03-02 09:34 UTC by Christophe Philemotte
Modified: 2020-12-09 11:46 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---

updates dmraid to snapshot v1_0_0_rc16-support_ignoremissing_option (dmraid-1.0.0_rc16_20100317.patch,76.94 KB, text/plain)
2010-07-26 18:14 UTC, Ian Stakenvicius (RETIRED)
ebuild that will apply the rc16 update patch (dmraid-1.0.0_rc16-r2.ebuild,2.46 KB, text/plain)
2010-07-26 18:20 UTC, Ian Stakenvicius (RETIRED)
strace output dmeventd (dmeventd,35.47 KB, text/plain)
2010-07-27 20:30 UTC, Roel Brook
CVS HEAD ebuild for dmraid (dmraid-9999.ebuild,1.82 KB, text/plain)
2010-07-27 21:43 UTC, Ian Stakenvicius (RETIRED)

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Philemotte 2010-03-02 09:34:27 UTC
When activating a RAID set, /usr/lib64/ is not loaded because pthread_mutex_trylock is undefined symbol.

Reproducible: Always

Steps to Reproduce:
1. install dmraid (emerge dmraid)
2. activate RAID set (dmraid -a y)

Actual Results:  
RAID set "isw_ddhjaehgdj_HDD_RAID" was activated
The dynamic shared library "" could not be loaded:
    /usr/lib64/ undefined symbol: pthread_mutex_trylock

Expected Results:  
successful load of

It seems like the -lpthread was not set.

I've tried with previous ebuild versions sys-fs/dmraid-1.0.0_rc16 sys-fs/dmraid-1.0.0_rc15-rc1 sys-fs/dmraid-1.0.0_rc15 and sys-fs/dmraid-1.0.0_rc14. Same behavior.

emerge --info
Portage (default/linux/amd64/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r1, 2.6.31-gentoo-r6 x86_64)
System uname: Linux-2.6.31-gentoo-r6-x86_64-Intel-R-_Core-TM-2_Duo_CPU_E8500_@_3.16GHz-with-gentoo-2.0.1
Timestamp of tree: Sun, 28 Feb 2010 10:15:01 +0000
app-shells/bash:     4.1_p2
dev-java/java-config: 2.1.10
dev-lang/python:     2.6.4-r1, 3.1.1-r1
dev-util/cmake:      2.8.0-r2
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.0-r1
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.13, 2.65
sys-devel/automake:  1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:  2.20-r1
sys-devel/gcc:       4.3.4
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.32
ACCEPT_KEYWORDS="amd64 ~amd64"
CFLAGS="-O2 -pipe -march=core2"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -march=core2"
FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch"
LINGUAS="en en_US fr"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
USE="X a52 aac acl acpi alsa amd64 bash-completion berkdb bluetooth branding bzip2 cairo cdr cli consolekit cracklib crypt cups cxx dbus dri dts dvd dvdr eds emboss encode evo fam firefox flac fontconfig fortran gdbm gif gnome gnutls gpm gstreamer gtk hal iconv ipv6 java jpeg ldap libnotify mad mikmod mmx mng modules mp3 mp4 mpeg mudflap multilib ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcre pdf perl png postscript ppds pppd python qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl startup-notification svg sysfs tcpd threads thunar tiff tk truetype unicode usb v4l v4l2 vim-syntax vorbis x264 xcb xinerama xml xorg xulrunner xv xvid xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US fr" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" 
Comment 1 Christophe Philemotte 2010-03-06 08:29:58 UTC
enable -pthread ldflags fix the problem

src_configure() {
    append-ldflags -pthread
    econf \
        $(use_enable static static_link) \
        $(use_enable selinux libselinux) \
        $(use_enable selinux libsepol)

But now, I've another error:
RAID set "isw_ddhjaehgdj_HDD_RAID" was activated
ERROR:  Unable to register a device mapper event handler for device "isw_ddhjaehgdj_HDD_RAID"
Comment 2 Ian Stakenvicius (RETIRED) gentoo-dev 2010-03-08 14:45:12 UTC
iirc, there is an issue with using pthreads with other hardware or older versions of the kernel or something.. i can't remember the details but there is a reason to not include it for all compiles.  That said, it seems that since it is needed it should be USE-flagged.  

Unfortunately I don't have the hardware to test dmraid anymore.

That second issue looks like it's an upstream issue, though..  FYI, intel raid can now be managed entirely via mdadm, you don't need to use dmraid (or device-mapper) anymore.

Comment 3 Christophe Philemotte 2010-03-09 11:27:26 UTC
thanks Ian Stakenvicius for the tips, I'll take a look at mdadm so.
Comment 4 Thomas Sachau gentoo-dev 2010-03-12 15:33:53 UTC
@Ian: I suggest you either try to continue the maintainence of this ebuild or at least tell me, that you dont want to maintain it anymore, so others have a chance of looking at it.
Comment 5 Ian Stakenvicius (RETIRED) gentoo-dev 2010-06-10 17:23:36 UTC
I haven't found anything upstream that would suggest adding -pthread is a good idea (a couple of versions back it seemed to cause more issues than it solved)..  

As for the lack of detection, upstream seems to have nothing to say -- I'm adding the patch listed in bug 275451 but I do not think this will resolve your issue either.

Since support for all intel biosraid is moving to mdadm anyhow, I'm changing this bug to resolved/wontfix.

IF ANYONE ELSE HAS THE PTHREAD ISSUE, please re-open this bug and I'll apply the fix and/or sort it out with upstream.
Comment 6 Roel Brook 2010-07-24 18:57:33 UTC
OK, as requested.

I tried re-emerging sys-fs/dmraid to make sure I got the "patched" version, but I get this error too.

 * Applying dmraid-1.0.0_rc16-undo-p-rename.patch ...                     [ ok ]
 * Applying dmraid-1.0.0_rc16-return-all-sets.patch ...                   [ ok ]
 * Applying dmraid-destdir-fix.patch ...                                  [ ok ]
 * Applying dmraid-1.0.0_rc16-as-needed.patch ...                         [ ok ]

Also on an intel RAID set.

I'm willing to test patches etc, I'll wait with trying mdadm.

PS, I don't have rights to reopen the bug, as I'm not the reporter.
Comment 7 Ian Stakenvicius (RETIRED) gentoo-dev 2010-07-26 15:01:29 UTC
OK, reopening bug as a reminder..
Comment 8 Ian Stakenvicius (RETIRED) gentoo-dev 2010-07-26 18:14:35 UTC
Created attachment 240215 [details]
updates dmraid to snapshot v1_0_0_rc16-support_ignoremissing_option
Comment 9 Ian Stakenvicius (RETIRED) gentoo-dev 2010-07-26 18:20:00 UTC
Created attachment 240217 [details]
ebuild that will apply the rc16 update patch

OK, so upstream has been working on dmraid since rc16 through the 'device-mapper' project now instead of through the 'ataraid' project, it seems.  Anyhow, there's a new version tagged in their CVS which includes pthread linking.  This ebuild, combined with the patch "dmraid-1.0.0_rc16_20100317.patch" (in attachment 240215 [details] - copy it to files/ in your overlay) will provide the updated copy.

I've tested the ebuild and it compiles and installs fine, HOWEVER I can't confirm that it works at runtime since I don't have the hardware.  If you could test for me and report back I would appreciate it.
Comment 10 Roel Brook 2010-07-27 20:27:44 UTC
Well, the ebuild compiles fine, but unfortunatly, does not work.

/dev/mapper is still empty.

dmraid -ay hangs for a while, and finally spits out:

Medusa mapper # dmraid -ay
RAID set "isw_dagchgecca_BootEnBackup" already active
RAID set "isw_dagchgecca_Data" already active
ERROR:  Unable to register a device mapper event handler for device "isw_dagchgecca_BootEnBackup"
ERROR:  Unable to register a device mapper event handler for device "isw_dagchgecca_Data"
ERROR: opening "/dev/mapper/isw_dagchgecca_BootEnBackup"
ERROR: opening "/dev/mapper/isw_dagchgecca_Data"

Output from 
"strace -f -s 1500 -t -o /tmp/strace dmraid -ay"
is found here:

(bzip2'ed, 141MB unpacked, bugzilla has a limit of 1MB for uploaded files, this is 2.3MB)

line 1002460 shows the error.
Just above (1002436) that you can see the child segfaulting after a munmap() call.
Comment 11 Roel Brook 2010-07-27 20:30:52 UTC
Created attachment 240367 [details]
strace output dmeventd

After debugging some more, I'm pretty sure it's dmeventd which is segfaulting.

Testcase; start strace -s 1500 -f -t -o /tmp/dmeventd -- dmeventd -ddd -f in one terminal, start dmraid -ay in another terminal.

dmeventd exits with "segfault".

strace output is attached (this one is tiny).
Comment 12 Ian Stakenvicius (RETIRED) gentoo-dev 2010-07-27 21:43:42 UTC
Created attachment 240375 [details]
CVS HEAD ebuild for dmraid

Try using this ebuild -- it's for current CVS; if it still doesn't work, then I'll forward your debugging info upstream so that they can try and fix it before the next release.  If it does work, i'll try and back-port the patches.

(adjust the KEYWORDS as necessary for your system)
Comment 13 Roel Brook 2010-07-28 12:22:54 UTC
Hmm, CVS HEAD doesn't seem to be working either...

Builds, compiles and everything, but dmraid -ay still fails. Same error message, strace output looks similar too...
Comment 14 Roel Brook 2010-08-13 22:30:44 UTC
Ian, did you get around to reporting this upstream?
Comment 15 Ian Stakenvicius (RETIRED) gentoo-dev 2010-08-16 16:05:05 UTC
Not yet -- will be doing so today.
Comment 16 Maxime Gilles 2010-08-25 18:00:54 UTC
(In reply to comment #3)
> thanks Ian Stakenvicius for the tips, I'll take a look at mdadm so.

Is there any documentation on howto use mdadm and Intel raid ?

Comment 17 Ian Stakenvicius (RETIRED) gentoo-dev 2010-08-25 18:05:47 UTC
None that I am aware of...

...might shed some light, though.

Also, Roel, the issue this user was having looks a bit like yours; might be worth checking out...
Comment 18 Ian Stakenvicius (RETIRED) gentoo-dev 2010-08-25 18:12:18 UTC
This is the closest thing to a howto that i've been able to find so far:
Comment 19 Ian Stakenvicius (RETIRED) gentoo-dev 2010-09-27 15:36:36 UTC
I read something at some point in the past couple of weeks (sorry, don't have the reference) that seemed to imply that the md raid kernel modules could 'take over' the raids, even though they aren't being configured, which might block dmraid from being able to do its thing.  Could you maybe double-check to ensure that no md-raid modules are enabled in your kernel, and then give dmraid a test?
Comment 20 Roel Brook 2010-09-27 21:47:55 UTC
Hmm, that could be something:

Medusa ~ # lsmod | grep md
Medusa ~ # zgrep _MD_ /proc/config.gz 

I apparently have MD support compiled into my kernel. I'll see if I can recompile without this (or with modules) and re-test.

Thanks for the how-to :)

I do think the RedHat bug is different from my situation (different output), but comment #4 mentions:

"because as said already Intel RAID now uses mdraid instead of dmraid.".