kernel 2.6 won't exec dynamically linked uclibc apps

Hello,

I'm trying to put together a 2.6/uClibc/busybox-based system for my VIA EPIA. I'm currently running DSL 2.3 with a 2.4 kernel, but am building the kernel (2.6.16.11 stock) and the apps for my rootfs in a uClibc 0.9.28/gcc-3.4.6/binutils-2.16.1 (+buildroot patches) environment into which I chroot. I can also chroot into the rootfs and everything there works fine, shared libraries are in place etc:

# ldd bin/sh # bin/sh: is setuid libcrypt.so.0 => /lib/libcrypt.so.0 (0x40008000) libm.so.0 => /lib/libm.so.0 (0x4001c000) libc.so.0 => /lib/libc.so.0 (0x4002a000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)

But when I pack the rootfs into an initramfs and boot my shiny new kernel, things turn bad: The kernel correctly finds /dev/console and /init (a shell script for a statically linked /bin/dash), which does a ldconfig (statically linked) without problems and echos some messages, but fails to execute any dynamically linked program, claiming that it doesn't know the binary format. (When I had module support compiled in, it would hang itself trying to modprobe for binfmt-0000, which I think meant essentially the same thing.) But support for all formats is turned on, and shouldn't it be ELF anyway? And the same programs run in the chroot environment under the 2.4 distro kernel - I'm not quite sure what to make of it.

Any ideas appreciated.

Thanks, Rupert

To followup on my own posting, the problem seems to have somehow solved itself. I changed the "exec /bin/sh" statement at the end of the /init script (calling the dynamically linked busybox sh) to "exec /bin/dash" to call the statically linked dash. Which, bizarrly, makes the rest of the script work, and all dynamically linked commands execute fine. I can also do "exec /bin/sh" later, in brief, the problem has disappeared.

As a firm believer in causality I'm at a loss to understand why the last command in a script would influence all that happens before. I figure I might have inadvertently changed something else when I repackaged the initramfs archive. Maybe the first was simply somehow damaged. On the other hand, the problem had persisted though several unpacking/repacking cycles, so I'm not sure that was it, either.

So anyway, please nobody lose sleep over that. This doesn't seem to be related to uClibc, or busybox. Maybe to some fine points in the interaction between cpio and the initramfs code.