Ouch. If you're running Debian unstable, be vewwy vewwy careful upgrading right now.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265486

I seem to have killed my system dead. fork() is forked.

simon@stout:~$ ls
-bash: ../nptl/sysdeps/unix/sysv/linux/fork.c:132: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%gs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (((size_t) &((struct pthread *)0)->tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%gs:%P1,%0" : "=r" (__value) : "i" (((size_t) &((struct pthread *)0)->tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movl %%gs:%P1,%%eax\n\t" "movl %%gs:%P2,%%edx" : "=A" (__value) : "i" (((size_t) &((struct pthread *)0)->tid)), "i" (((size_t) &((struct pthread *)0)->tid) + 4)); } __value; }) != ppid' failed.
Aborted

I can ssh in and an existing mutt session seems to be able to run, including run sudo for root privs.

Any suggestions on recovery greatly appreciated.

Options I'm thinking are:
1. Unpack an older libc6 package somewhere else, scp it up and manually install all the bits. Cross fingers and hope it works. I'm not a C guru though, so mabye this is boneheaded thinking?

2. Purchase some more disk space temporarily and create a new partition. Boot from that, reinstall Debian on it, mount the old drive, copy data across. Then remove the temporarily added disk space (and stop paying for it)

Any more sensible suggestions greatly appreciated.

Boot under a 2.4 based kernel, and then:

mv /lib/tls /lib/tls-disabled

After that, running an NPTL enabled libc under a 2.6-um kernel will work...

-Chris

Well that seems to have been the problem. I'm sure I did this TLS thing before, though.

Caker, could I ask you to work with Bruce Stephens <bruce.stephens@isode.com> to implement some kind of check for UML kernels on the Debian package installer? That way it won't happen again

Did this show up in the apt-listbugs output when you did apt-get upgrade? I see that the bug report is only from today.

I run testing, and have seen some grave and some critical bugs reported by apt-listbugs, so I've held off upgrading perl, for example.

Will check it out. Sounds like a good tool.

Chris, can you explain (use small words and speak slowly for me) to me exactly what the problem here is? I can try and get some kind of check incorporated in the upgrade process of the Debian package.

UML does not (yet) support Thread Local Storage (TLS) in either 2.4 or 2.6. TLS is required by the Native POSIX Thread Library (NPTL) so NPTL is also not supported by UML.

The difference in the way the problem manifests itself (or not) between 2.4 and 2.6 is because NPTL enabled /lib/ld.so checks 'uname' in 2.4 kernels. If extraversion begins with "-ntpl" then this 2.4 kernel has NPTL (and TLS) support. If extraversion doesn't have that string, ld.so assumes that the kernel doesn't have NPTL (or TLS) support. If the kernel is >=2.6, then ld.so assumes that NPTL (and TLS) support is present, so things start to go haywire under UML, where this assumption is invalid.

_________________
/ Peter

I feel like pointing out that the problem is on debian *un*stable. The 2.6 kernel works fine on woody, though it requires some tweaking. I followed the directions at:

http://www.wlug.org.nz/LinuxKernel2.6

and all was well, except I couldn't log in via ssh, so I also added:

  devpts /dev/pts        devpts  defaults        0 0

to /etc/fstab (as per instructions I found on google).

There is no /lib/tls directory on a normal woody install, so caker's instructions don't seem to apply.[/code]

The problem is not with the 2.6 kernel, it is with the the NPTL enabled version of the dynamic linker/loader, which is not present in woody.

_________________
/ Peter

I wrote up a little howto and explanation of the whole /lib/tls thing:

http://www.linode.com/forums/viewtopic.php?t=1160