2.4.36.3: busybox's Init hangs at "Freeing unused kernel memory: "
Hello
I have a 2.4.36.3 kernel compiled for an embedded target (i386). Init (busybox) however does not start up. Using a linux-2.6.24 kernel, it starts up. My hypothesis is currently that busybox's libc is not working properly as it is compiled on a host running linux-2.6.18-gentoo. The library is statically linked to busybox. It should hence not matter on which host system the binary was compiled (as long as the processor architecture does not change). Libc however uses kernel system calls -- that makes me think it might matter. Besides a solution, I would appreciate suggestion how to trace this down further. Setup ===== a) Kernel: 2.4.36.3 b) Rootfs: via nfs c) Init: replaced by a hello world program (to exclude busybox as the culprit) Code:
#include <stdio.h> > file /var/nfs/vmic7750/usr/src/init /var/nfs/vmic7750/usr/src/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, statically linked, for GNU/Linux 2.6.9, not stripped d) Added debug output to init/main.c:run_init_process Code:
static void run_init_process(char *init_filename) ============== Code:
Secondary interface chip i82555. Tilman |
You did build libc against the headers for the kernel you're booting, didn't you?
I also suggest you call 'fflush(stdout)' or you can't really be guaranteed that your message will be sent to the video buffer before the sleep() - otherwise you may have to wait about 32 years before you see your message displayed. Also, it's usually safer to send a message over something like the serial port; don't trust the video. Otherwise, it looks like the rest of the boot procedure (initrd etc) went fine - can you confirm that? |
> You did build libc against the headers for the kernel you're booting, didn't you?
No, I did not -- and I suspect this is why the boot process does not complete. I am currently compiling libc against the header files of 2.4.36.3. Will see how that goes. I used the default options while compiling , i.e. the libc of the gentoo distribution is used for linking. Interestingly enough this is V 2.6.9 -- even though I am using a 2.6.18-gentoo kernel. I read a little bit in the libc docs by now, and I understand that libc is compatible down to a kernel version 2.6.9. I reasoned that it might work as the init executable is statically linked -- assuming that the syscall table between 2.4.36.3 and 2.6.9 was only enhance but not changed. >Also, it's usually safer to send a message over something like the serial port; don't trust the video. the default output is redirected to the serial port -- the bios has on option for that. The box is headless. I am using minicom to interact with it. >Otherwise, it looks like the rest of the boot procedure (initrd etc) went fine - can you >confirm that? Everything before "Freeing unused kernel memory" went OK. I think that also the mounting of the nfs went ok -- I am however not entirely sure. The host's /var/log/messages has an entry from rpc.mount. It does not look any different if booting with V 2.6.24 -- and that works. /var/log/messages of the nfs host: Code:
rpc.mountd: authenticated mount request from 192.168.1.49: Tilman |
I compiled libc 2.3.6 against the source of kernel 2.4.36.3, and then linked my init program with new libc. This works. So the issue was indeed libc.
A questions remains however: How do I tell the make of the busybox to use a different kernel source (I understand that busybox uses a smaller library than libc) Thanks Tilman |
You can look at the LFS project (CLFS sub-project) to see what they do with busybox.
Busybox in Debian is linked against the usual glibc. In CLFS it is patched and linked to 'uClibc'. I have some strange behavior from busybox on uClibc though and haven't had time to look into it - some tests fail such as md5 calculation, but OpenSSL can do md5 hashes so I ignore the broken busybox version. I also suspect that some of the file utilities aren't working quite right on my embedded system, but once again I haven't had time to track down problems. |
I compiled busybox using suse 8.0 (running on vmware) kernel source of 2.4.36.3 and libc 2.2.5. Init(=Busybox) seems to come up (kernel version 2.4.36.3). The devices are however not recognized (see console output below). Using a 2.6.24 kernel, init starts up, and the devices are recognized. Any idea why that is?
Console Output (Kernel 2.4.36.3) ================================ .... VFS: Mounted root (nfs filesystem). Mounted devfs on /dev Freeing unused kernel memory: 84k freed Starting init (/sbin/init) Mount proc FS Mount ROOTFS RW Set hostname Starting syslogd Can't open /dev/ttyS0: No such file or directory Can't open /dev/tty1: No such file or directory Thanks Tilman |
Found the issue myself: I had the devfs kernel option turned on (and at the same time, I am using a classic dev file system)
|
All times are GMT -5. The time now is 12:46 AM. |