Due to incompatibilities between NPTL-enabled libcs in various distributions and the current UML kernels (which do not yet fully support NPTL), several things will be broken unless you do:

mv /lib/tls /lib/tls-disabled

You could also just delete /lib/tls, but it's a good idea to keep it around, just in case. /lib/tls contains the NPTL-enabled libraries, and without the existence of this directory, it'll fall back to using /lib/i686, which contains LinuxThreads libraries. Don't worry, "tls" in this case has nothing to do with "Transport Layer Security" or encryption. Here are a few symptoms that this should solve:

• nslookup, dig, host, mysql, or sshd segfaults (aka signal 11) on ...
• ... Debian Unstable (Sid)
• ... Gentoo (some builds, not sure of the circumstances)
• ... CentOS
• ... Any system running kernel 2.6 (modified Fedora Cores, most notably)

If you are not covered by this, check for the existence of /lib/tls anyways. It is safe to move it out of the way, since NPTL functionality is not in current UML kernels anyways.

Also, please bear in mind that if you update glibc, either manually or though your distro's package management system, the /lib/tls directory will be restored, so a script like this in /etc/cron.hourly is helpful:

#!/bin/sh

[ -d /lib/tls ] && mv /lib/tls /lib/tls-diabled-`date +%s`

This will check every hour for the existence of /lib/tls, and if it exists, it moves it into a unique directory, without clobbering older versions. Have fun!

This is also responsible for the phantom segfaults I've been getting trying to apt-get some software and get erlang/ejabberd to install, and the segfaults in erl.

I post this here for anyone trying to do a search on the forums for "segfault", "segmentation fault", and/or "erlang", "ejabberd", and "erl".

Just for completeness:

segfault, segmentation fault, erlang, ejabberd, erl

I'm so glad to have this working. 2 days of frustrations just washed away.