Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
I am trying to build a root file system for the kernel and seems to be having
problem getting the kernel to load.
I developing on beaglebone black for learning purposes and so far I have
managed to build the following four elements.
(1) Toolchain using cross-ng (arm-cortex_a8-linux-gnueabihf- )
(2) u-boot.img
(3) Linux kernel (v4.1.10) omap2plus_defconfig
(4) Busybox (1_25_stable) [built as static]
For testing I am using NFS to mount the root file system. The puzzling bit for
me is that I when I use an already built rootfile system that I obtained from www.free-electrons.com "Embedded Linux kernel and driver development training"
I can boot the kernel without any problem.
The process I am using to load the kernel is as follows. I copy both the
zImage and am335x-boneblack.dtb to my sdcard and load that using u-boot console
as shown below.
The sdcard has been partitioned into two parts with partition 1 named boot
being a Fat 16 and parition 2 an ext4 (currently not used). The first partition
contains the following files MLO,u-boot.img,zImage and am335x-boneblack.dtb.
I start the kernel as follows..
--------------------------------------------------
USE CASE 1 (using free-electrons root file system)
-----------------------------------------------
Based on the googling and reading I have done. I am expecting the kernel to boot
and stop at a command prompt '#' until I start populating things like "inittab",
and the other directory and nodes.
I am have re-built busybox more that 20 times both as static library and
static library. Obviously when I created as dynamic library I copy libraries
from the tool chain library directory to the rootfs library directory but I
keep getting the same result.
So far for this exercise I am using the bare minimum folders that busybox
generates as shown below
Code:
onio@host:rootfs $ tree -d
.
├── bin
├── dev
├── lib
├── sbin
└── usr
├── bin
├── lib
└── sbin
Any help would be highly appreciated as I am completely stuck on this one.
Many thanks in advance.
Your stuck condition seems to be based on two misconceptions.
First you seem to equate Busybox with a root filesystem.
No, building Busybox (by itself) is not sufficient for a rootfs.
Quote:
Originally Posted by olaoni
Based on the googling and reading I have done. I am expecting the kernel to boot
and stop at a command prompt '#' until I start populating things like "inittab",
and the other directory and nodes.
Please list these web sites and reading materials that led you to this expectation.
You have a bogus expectation. The Linux kernel will definitely not interact with the user through a CLI.
There's no shell prompt until kernel initialization is complete and userspace is active.
It's possible to build a rootfs around Busybox by hand (I used to do it a long time ago), but now there are tools such as Buildroot.
Just like you used crosstool-NG to build a toolchain instead of compiling the binutils, gcc, etc. packages, Buildroot is an analogous tool for the rootfs.
Your stuck condition seems to be based on two misconceptions.
First you seem to equate Busybox with a root filesystem.
No, building Busybox (by itself) is not sufficient for a rootfs.
I am fully aware that Busybox is not a root filesystem. However it is used to create the core components which are symbolically linked to the actual busybox exectuable.
I understand that other directories (etc, dev, tmp, sys and nodes (dev/null and dev/console) need to be created.
Quote:
Originally Posted by blue_z
Your stuck condition seems to be based on two misconceptions.
Please list these web sites and reading materials that led you to this expectation.
Booting the system First, boot the board to the U-Boot prompt. Before booting the kernel, we need to tell it that
the root filesystem should be mounted over NFS, by setting some kernel parameters.
Use the following U-Boot command to do so, in just 1 line
setenv bootargs console=ttyS0,115200 root=/dev/nfs ip=192.168.0.100:::::eth0
nfsroot=192.168.0.1:/home/<user>/embedded-linux-labs/tinysystem/nfsroot rw
Of course, you need to adapt the IP addresses to your exact network setup. Save the environment
variables (with saveenv).
You will later need to make changes to the bootargs value. Don’t forget you can do this with
the editenv command.
Now, boot your system. The kernel should be able to mount the root filesystem over NFS:
VFS: Mounted root (nfs filesystem) on device 0:13.
If the kernel fails to mount the NFS filesystem, look carefully at the error messages in the console.
If this doesn’t give any clue, you can also have a look at the NFS server logs in /var/log/syslog.
However, at this stage, the kernel should stop because of the below issue:
[
7.476715] devtmpfs: error mounting -2
This happens because the kernel is trying to mount the devtmpfs filesystem in /dev/ in the root
filesystem. To address this, create a dev directory under nfsroot and reboot.
Now, the kernel should complain for the last time, saying that it can’t find an init application:
Kernel panic - not syncing: No working init found. Try passing init= option to kernel.
See Linux Documentation/init.txt for guidance.
Obviously, our root filesystem being mostly empty, there isn’t such an application yet. In the
next paragraph, you will add Busybox to your root filesystem and finally make it usable.
Root filesystem with Busybox Download the sources of the latest BusyBox 1.23.x release.
To configure BusyBox, we won’t be able to use make xconfig, which is currently broken for
BusyBox in Ubuntu 14.04, because of Qt library dependencies.
We are going to use make gconfig this time. Before doing this, install the required packages:
sudo apt-get install libglade2-dev
Now, configure BusyBox with the configuration file provided in the data/ directory (remember
that the Busybox configuration file is .config in the Busybox sources).
If you don’t use the BusyBox configuration file that we provide, at least, make sure you build
BusyBox statically! Compiling Busybox statically in the first place makes it easy to set up the
system, because there are no dependencies on libraries. Later on, we will set up shared libraries
and recompile Busybox.
Build BusyBox using the toolchain that you used to build the kernel.
Going back to the BusyBox configuration interface specify the installation directory for Busy-
Box 5 . It should be the path to your nfsroot directory.
Now run make install to install BusyBox in this directory.
Try to boot your new system on the board. You should now reach a command line prompt,
allowing you to execute the commands of your choice.
Quote:
You have a bogus expectation. The Linux kernel will definitely not interact with the user through a CLI.
There's no shell prompt until kernel initialization is complete and userspace is active.
It's possible to build a rootfs around Busybox by hand (I used to do it a long time ago), but now there are tools such as Buildroot.
I am aware of Buildroot and Yocto as build system. I am also aware that instead of using Crosstool-NG I could have used
Code:
sudo apt-get install gcc-arm-linux-gnueabihf
to get a working compiler. This is a learning exercise so I want it to be as manual as possible in order to have fully appreciation of what the build system is doing for me. I have tinkered around Yocto receipes in the past but I want to learn the manual process.
So far for this exercise I am using the bare minimum folders that busybox
generates as shown below
Code:
onio@host:rootfs $ tree -d
.
├── bin
├── dev
├── lib
├── sbin
└── usr
├── bin
├── lib
└── sbin
Quote:
Originally Posted by olaoni
I understand that other directories (etc, dev, tmp, sys and nodes (dev/null and dev/console) need to be created.
So you understand one thing, but do something else?
Quote:
Originally Posted by olaoni
Booting the system
[I]First, boot the board to the U-Boot prompt. Before booting the kernel, we need to tell it that
the root filesystem should be mounted over NFS, ...
If you're going to quote something, it's proper (if not expected) to cite the source and credit the author.
So exactly where is this quotation from?
Quote:
Originally Posted by olaoni
Try to boot your new system on the board. You should now reach a command line prompt,
allowing you to execute the commands of your choice.
You're misinterpreting this quotation.
This does not state as you wrote, that "the kernel ...[will]... stop at a command prompt '#' until I start populating things like "inittab", and the other directory and nodes."
The command line prompt that the quote refers to is surely a (root) shell prompt (executing in userspace).
The kernel panic that you're seeing is a clear indicator that userspace (i.e. the init process) is not active.
The failure of the init process is usually an indicator that something is wrong with the rootfs.
You have created your own chicken-and-egg problem. The init process probably needs some files in a rootfs, but you (incorrectly) expect a shell prompt so that you can populate the rootfs.
Quote:
Originally Posted by olaoni
This is a learning exercise so I want it to be as manual as possible in order to have fully appreciation of what the build system is doing for me.
Then using crosstool-NG as you did does not fulfill this goal at all.
You could have manually built the individual binutils, gcc, glibC etc packages.
IMO you put too much effort claiming what you do is correct and valid. You're the one with the kernel panic, and yet you never asked a question in this thread or seem to doubt your actions.
So you understand one thing, but do something else?
IMO you put too much effort claiming what you do is correct and valid. You're the one with the kernel panic, and yet you never asked a question in this thread or seem to doubt your actions.
Regards
Hey blue_z if my last email came across arrogant,defensive or rude I apologise. I was just a bit frustrated with the time I have spent trying to resolve and all the pressure I was getting from my day job.
I am following a book titled "Mastering Embedded Linux Programming" by Chis Simmonds The book goes through the stages of building Toolchain(hence my choice of croostool-Ng) followed by building bootloader (u-boot), followed by kernel and lastly file system (busybox).
I followed the book through the creation of the following directories bin,dev,etc,lib,proc,sbin,sys,tmp,usr,usr/bin and usr,lib and at the end of creating the /etc/inittab , /init.d/rcS file and the /dev/null and /dev/console the kernel didn't boot up, but kept coming up with one form or panic or another. So I started messing around with static builds and then dynamic builds all which also failed.
I came across www.free-electrons.com tutorial on building linux-kernel and thought the tutorial was going through a process of starting from a blank directory and then start populating with busybox files and later on other relevant directories. But as you pointed out there was a misconception on my part which I accept and has helped me to take a step back which is always a good things when confronted with issues like this.
I think I understand the process much clearer now, and should be able proceed much better and with fresh pair of eyes.
Thanks for the time and effort you have spent on responding to my questions.
Thanks for your comment. Sorry for late acknowledgement, It has been another hectic day. Yes regarding the tree command output that was the output from one of my many iterations of trying to solve the kernel panic issue.
I believe, I now have adequate information to tackle the problem. Once again thanks.
Thanks for the reply. Did you follow the steps from "Mastering Embedded Linux Programming" by Chis Simmonds book as well? Were you building with busybox as well or did you use a build system such as buildroot.
I am currently using buildroot for creating file system and kernel image for beagleoboard-xm but at some point in the future I would like to be able to do things manually as I initially attempted.
Yes, I mainly followed steps from matrials from "Free-Electorns" but also referred to "Mastering Embedded Linux Programming"
I didn't use buildroot or yocto for my "minimal root filesystem".
I had same problem at first as you did but it was solved atfer I changed my toolchain and recompiled kernel and busybox.
Only thing I had changed was toolchain option:
Crosstool-NG => C library => C library (glibc => uClibc)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
