Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Embedded (http://www.linux-archive.org/gentoo-embedded/)
-   -   gentoo baselayout "Attempted to kill init" (http://www.linux-archive.org/gentoo-embedded/517038-gentoo-baselayout-attempted-kill-init.html)

04-21-2011 09:18 PM

gentoo baselayout "Attempted to kill init"
 
I've got a filesystem created with the following toolchain: (from
crossdev)


arm-unknown-linux-gnu-

with

arm-unknown-linux-gnu-emerge system
arm-unknown-linux-gnu-emerge baselayout

I created the kernel separately, and was able to boot it with another
filesystem that was created by somebody else.


During the boot process the kernel says "Attempted to kill init"
because the /init program exited for some reason.
The problem is that I can't get any other error from the init program.
I have no idea why it's exiting. It could be a missing library, segfault
or bad invocation, so I have no idea where to start.


I was hoping somebody could either spot something obviously wrong in my
setup or propose a method for getting more information as to why init
would crash...


Thanks,
Chris

Mike Dunn 04-22-2011 02:13 AM

gentoo baselayout "Attempted to kill init"
 
On 04/21/2011 02:18 PM, chris@basementcode.com wrote:
> I've got a filesystem created with the following toolchain: (from crossdev)
>
> arm-unknown-linux-gnu-
>
> with
>
> arm-unknown-linux-gnu-emerge system
> arm-unknown-linux-gnu-emerge baselayout
>
> I created the kernel separately, and was able to boot it with another
> filesystem that was created by somebody else.
>
> During the boot process the kernel says "Attempted to kill init" because the
> /init program exited for some reason.
> The problem is that I can't get any other error from the init program. I have
> no idea why it's exiting. It could be a missing library, segfault or bad
> invocation, so I have no idea where to start.
>
>

Beyond emerging system and baselayout, there will be some hand tweaking and
sysadmin chores involved with getting a working bootable root filesystem.

The error you see is very common with what you are doing and usually caused by
missing libraries required by the init process. You can check which libraries
are needed by a particular utility by running (on the build host):
readelf -d /path/to/target/utility | grep NEEDED

I recommend creating a separate minimal rootfs and building it into the kernel
as an initramfs. The minimal filesystem need only contain a statically built
busybox and a simple /init shell script that does a few things like mounting
/proc and /sys and then execs the shell.
See http://en.gentoo-wiki.com/wiki/Initramfs for some guidance. Once this has
succesfully booted, you can mount and chroot into your real rootfs and
troubleshoot it.

HTH
Mike

Jörg Faschingbauer 04-22-2011 06:00 AM

gentoo baselayout "Attempted to kill init"
 
On Thu, 2011-04-21 at 16:18 -0500, chris@basementcode.com wrote:
> I've got a filesystem created with the following toolchain: (from
> crossdev)
>
> arm-unknown-linux-gnu-
>
> with
>
> arm-unknown-linux-gnu-emerge system
> arm-unknown-linux-gnu-emerge baselayout
>
> I created the kernel separately, and was able to boot it with another
> filesystem that was created by somebody else.
>
> During the boot process the kernel says "Attempted to kill init"
> because the /init program exited for some reason.
> The problem is that I can't get any other error from the init program.
> I have no idea why it's exiting. It could be a missing library, segfault
> or bad invocation, so I have no idea where to start.

Provided that /init is an executable:

If the instruction set that the root filesystem was compiled for doesn't
match your architecture's, then it's an "illegal instruction" signal
that bites init. This usually happens quite early, before any
configuration error is seen.

You can verify this by building your own busybox-only tree with the same
toolchain you built the kernel with. Choose a static build
(CONFIG_STATIC, "Busybox Settings"/"Build Options"/"blah static blah").
Copy init and all that it needs (glibc?) over from your real rootfs into
your small tree. Boot the kernel into the small tree, passing it
init=/bin/sh (which is busybox). Call /init and see what happens.

Alternatively, you could augment your tree with busybox, by installing
it into it. Boot into the tree, but with init=/bin/sh (the augmented
busybox).

Have fun,
Joerg

04-22-2011 01:34 PM

gentoo baselayout "Attempted to kill init"
 
On Fri, 22 Apr 2011 08:00:35 +0200, Jörg Faschingbauer
<joerg.faschingbauer@aon.at> wrote:

On Thu, 2011-04-21 at 16:18 -0500, chris@basementcode.com wrote:

I've got a filesystem created with the following toolchain: (from
crossdev)

arm-unknown-linux-gnu-

with

arm-unknown-linux-gnu-emerge system
arm-unknown-linux-gnu-emerge baselayout

I created the kernel separately, and was able to boot it with
another

filesystem that was created by somebody else.

During the boot process the kernel says "Attempted to kill init"
because the /init program exited for some reason.
The problem is that I can't get any other error from the init
program.
I have no idea why it's exiting. It could be a missing library,
segfault

or bad invocation, so I have no idea where to start.


Provided that /init is an executable:

If the instruction set that the root filesystem was compiled for
doesn't

match your architecture's, then it's an "illegal instruction" signal
that bites init. This usually happens quite early, before any
configuration error is seen.

You can verify this by building your own busybox-only tree with the
same

toolchain you built the kernel with. Choose a static build
(CONFIG_STATIC, "Busybox Settings"/"Build Options"/"blah static
blah").
Copy init and all that it needs (glibc?) over from your real rootfs
into

your small tree. Boot the kernel into the small tree, passing it
init=/bin/sh (which is busybox). Call /init and see what happens.

Alternatively, you could augment your tree with busybox, by
installing

it into it. Boot into the tree, but with init=/bin/sh (the augmented
busybox).

Have fun,
Joerg


You were right about the "Illegal Instruction". I booted the working
filesystem and chrooted into the new one where I was able to play around
with the "broken" init file.


I'm guessing I stuck a bad flag in make.conf, since the same compiler
was able to produce a working kernel.


Thanks.

04-22-2011 01:34 PM

gentoo baselayout "Attempted to kill init"
 
On Fri, 22 Apr 2011 08:00:35 +0200, Jörg Faschingbauer
<joerg.faschingbauer@aon.at> wrote:

On Thu, 2011-04-21 at 16:18 -0500, chris@basementcode.com wrote:

I've got a filesystem created with the following toolchain: (from
crossdev)

arm-unknown-linux-gnu-

with

arm-unknown-linux-gnu-emerge system
arm-unknown-linux-gnu-emerge baselayout

I created the kernel separately, and was able to boot it with
another

filesystem that was created by somebody else.

During the boot process the kernel says "Attempted to kill init"
because the /init program exited for some reason.
The problem is that I can't get any other error from the init
program.
I have no idea why it's exiting. It could be a missing library,
segfault

or bad invocation, so I have no idea where to start.


Provided that /init is an executable:

If the instruction set that the root filesystem was compiled for
doesn't

match your architecture's, then it's an "illegal instruction" signal
that bites init. This usually happens quite early, before any
configuration error is seen.

You can verify this by building your own busybox-only tree with the
same

toolchain you built the kernel with. Choose a static build
(CONFIG_STATIC, "Busybox Settings"/"Build Options"/"blah static
blah").
Copy init and all that it needs (glibc?) over from your real rootfs
into

your small tree. Boot the kernel into the small tree, passing it
init=/bin/sh (which is busybox). Call /init and see what happens.

Alternatively, you could augment your tree with busybox, by
installing

it into it. Boot into the tree, but with init=/bin/sh (the augmented
busybox).

Have fun,
Joerg


You were right about the "Illegal Instruction". I booted the working
filesystem and chrooted into the new one where I was able to play around
with the "broken" init file.


I'm guessing I stuck a bad flag in make.conf, since the same compiler
was able to produce a working kernel.


Thanks.


All times are GMT. The time now is 11:03 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.