Hello,
I am trying to build a basic initramfs image into the kernel, using
the CONFIG_INITRAMFS_SOURCE. The required result is a single image
loaded into a target containing usermode application (busybox).
I use cross compile mipsel-unknown-linux-uclibc in order to build the
kernel and the initramfs's usermode.
The cpio image is created using cpio -o -H newc command.
The same configuration works with i586-pc-linux-uclibc cross compile.
printk at init/main.c::run_init_process() shows that the
kernel_execve() returns -2 (ENOENT) for /init and -14 (EFAULT) for
/*/init.
Looking at the initramfs /init is available and executable.
Any reason why I get ENOENT?
Any special procedure should be performed for mips arch?
Best Regards,
Alon Bar-Lev.
Alon Bar-Lev wrote:
> Hello,
>
> I am trying to build a basic initramfs image into the kernel, using
> the CONFIG_INITRAMFS_SOURCE. The required result is a single image
> loaded into a target containing usermode application (busybox).
>
> I use cross compile mipsel-unknown-linux-uclibc in order to build the
> kernel and the initramfs's usermode.
>
> The cpio image is created using cpio -o -H newc command.
>
> The same configuration works with i586-pc-linux-uclibc cross compile.
>
> printk at init/main.c::run_init_process() shows that the
> kernel_execve() returns -2 (ENOENT) for /init and -14 (EFAULT) for
> /*/init.
>
> Looking at the initramfs /init is available and executable.
>
> Any reason why I get ENOENT?
> Any special procedure should be performed for mips arch?
>
Make sure your /init doesn't depend on an interpreter or library which
isn't available.
-hpa
On 12/18/07, H. Peter Anvin <[email protected]> wrote:
> Make sure your /init doesn't depend on an interpreter or library which
> isn't available.
Thank you for your answer.
I already checked.
/init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
But shouldn't I get a different error code if this is the case?
Best Regards,
Alon Bar-Lev.
Alon Bar-Lev wrote:
> On 12/18/07, H. Peter Anvin <[email protected]> wrote:
>> Make sure your /init doesn't depend on an interpreter or library which
>> isn't available.
>
> Thank you for your answer.
>
> I already checked.
>
> /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
>
> But shouldn't I get a different error code if this is the case?
Don't think so.
-hpa
On Wed, Dec 19, 2007 at 12:09:46AM +0200, Alon Bar-Lev wrote:
> On 12/18/07, H. Peter Anvin <[email protected]> wrote:
> > Make sure your /init doesn't depend on an interpreter or library which
> > isn't available.
>
> Thank you for your answer.
>
> I already checked.
>
> /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
Are you sure that libc.so.0 is enough and that you don't need any ld.so ?
> But shouldn't I get a different error code if this is the case?
If it does not find part of the dynamic linker or libraries, this error
makes sense to me.
You should try to build a static init with any stupid thing such as a
hello world to ensure that the problem really comes from the init and
nothing else.
Regards,
Willy
Thank you for your help.
Indeed the dynamic loader of uclibc is the cause.
I upgraded to latest uclibc-0.9.29, and finally the files was linked
against uclibc's ld.
But it did not work...
Tried to run a dynamic linked executable via static shell, and got
floating point exception.
Tried to compile toolchain and uclibc with softfloat, but still did not work.
So I moved to glibc and all works correctly.
Thank you for quick response!
I will continue the discussion at uclibc lists.
Best Regards,
Alon Bar-Lev.
On 12/19/07, Willy Tarreau <[email protected]> wrote:
> On Wed, Dec 19, 2007 at 12:09:46AM +0200, Alon Bar-Lev wrote:
> > On 12/18/07, H. Peter Anvin <[email protected]> wrote:
> > > Make sure your /init doesn't depend on an interpreter or library which
> > > isn't available.
> >
> > Thank you for your answer.
> >
> > I already checked.
> >
> > /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
>
> Are you sure that libc.so.0 is enough and that you don't need any ld.so ?
>
> > But shouldn't I get a different error code if this is the case?
>
> If it does not find part of the dynamic linker or libraries, this error
> makes sense to me.
>
> You should try to build a static init with any stupid thing such as a
> hello world to ensure that the problem really comes from the init and
> nothing else.
>
> Regards,
> Willy
>
>