Busybox init problem

[Zachár Balázs]

I found the solution with Wan ZongShun's help on arm-linux mailing list:

I forgot to turn on the CONFIG_AEABI in my new kernel!

Many thanks for the helps!

Regards,
Balazs Zachar

Zachár Balázs wrote:
> 
> Denys Vlasenko wrote:
>> On Tuesday 17 March 2009 18:27, Zachár Balázs wrote:
>>> Hi,
>>>
> 
> Hi,
> Firstly thanks for the help!
> 
>>> I have a pxa270 based board, and I would like to renew the system on it...
>>> I am using the emdebian's stable gnueabi cross-toolchain.
>>> I have already recompile the kernel (both latest stable (2.6.28.7) and testing (2.6.29-rc8)) and it works (boot up) now...
>>>
>>> I would like to use Busybox to init (and to many other :) )...
>>>
>>> I made a new root-filesystem structure, and I compiled a Busybox with the same cross-toolchain which I used to compile the new kernel...
>>>
>>> But when I would like to boot up I get this error message:
>>> VFS: Mounted root (nfs filesystem) on device 0:11.
>>> Freeing init memory: 96K
>>> Warning: unable to open an initial console.
>>> Kernel panic - not syncing: Attempted to kill init!
>> Look carefully: it does not say it cannot find /sbin/init.
>> It says that it cannot open /dev/console,
>> and then it says that *init exited*.
> 
> Yes I know this... If it can't find the /dev/console file it using the kernel param to console...
> 
>>> So I compile this code to static using the cross-toolchain:
>>> devel:/opt/rootfs# cat test_init.c
>>> #include <stdio.h>
>>>
>>> int main()
>>> {
>>>   printf("Hello world!\n");
>> In order to exclude the possibility of stdio bug triggering,
>> use write(1, "Hello world!\n", 12) instead.
> 
> I tried it, but I got the same error... :(
> 
>>>   while(1);
>>>   return 0;
>>> }
>>>
>>> And I copy it to my nfsroot/sbin/init
>>>
>>> I make two dev file (because I have my console on ttyS1 (kernel param: console=ttyS1,115200)):
>>> devel:~# ll /nfsroot/root/dev/console
>>> crw------- 1 root tty 5, 1 2009-03-17 18:30 /nfsroot/root/dev/console
>>> devel:~# ll /nfsroot/root/dev/ttyS1
>>> crw-rw---- 1 root dialout 4, 65 2009-02-20 11:10 /nfsroot/root/dev/ttyS1
>> Major/minor numbers look correct, but
>> why they are in /nfsroot/root/dev instead of /nfsroot/dev?
> 
> Because I use the /nfsroot/ dir to hold some file to, but I use the /nfsroot/root/ dir when I mount it to root...
> 
>>> Than I tried to boot up, but I got the same error like above:
>>> Kernel panic - not syncing: Attempted to kill init!
>> Do you still get "Warning: unable to open an initial console"
>> just above this line? If yes, this is definitely a problem
>> with /dev/console not being found.
> 
> No. After I made the /dev/console file the Warning disappeared...
> 
>> This will also make all init's messages to not be visible.
>>
>> However, it won't make init exit. This is a bit strange
>> that it exits.
>>
>>> When I using the new kernel, with the old/orig rootfs (it is using busybox too) content it boot up properly... But I would like to build a new system!
>>>
>>> Any Idea, where should I try?
>> Another possibility is that your toolchain generates
>> broken (crashing) executables (wrong CPU flavor selected, etc).
> 
> This Is what I am afraid... But I compile my new kernel with this cross-toolchain and it boot up as far as the init call...
> 
>> If you have known working ("old") toolchain, build
>> minimal-static-init-for-testing using it,
>> but install it on new system. If it boots and you see
>> "Hello world" (after you fixed "Warning: unable to open
>> an initial console" problem), this confirms the theory
>> about broken toolchain. Then use objdump and readelf
>> to compare executables and find out what is wrong.
> 
> Good idea!
> I have an old toolchain...
> I tried it and it works... :(
> Can be my new toolchain is bad after a success kernel compile? :(
> 
> 
> After this bad news, I tried this:
> Boot: New kernel, old system
> Success boot!
> Run: test_init (static linked, compiled with new toolchain: )
> # /tmp/test_init_eabi
> Segmentation fault
> #
> 
> with gdb:
> # gdb /tmp/test_init_eabi
> GNU gdb 6.6
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "arm-linux"...
> Using host libthread_db library "/lib/libthread_db.so.1".
> (gdb) run
> Starting program: /tmp/test_init_eabi
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x000118ec in uname ()
> (gdb)
> 
> :(
> But how can a bad cross-toolchain compile a good kernel and can't compile a "Hello world!" ?????
> 
> regards,
> Balazs
> 
> 
> 
> 
> 
> 
> 
>> --
>> vda
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox