13

I managed to create a small and fully functional live Linux CD which contains only kernel (compiled with default options) and BusyBox (compiled with default options + static, all applets present, including /sbin/init). I had no issues to create initrd and populate /dev, /proc and /sys and also I had no issues at all with my /init shell script.

Recently I read that BusyBox supports /etc/inittab configurations (at least to some level) and I very much would like to do either of the following:

  • Forget about my /init shell script and rely entirely on /etc/inittab configuration.
  • Use both /init shell script and /etc/inittab configuration.

Now the actual problem - it seems that /etc/inittab is completely ignored when my distro boots up. The symptoms are:

  • When I remove /init and leave only /etc/inittab I end up with kernel panic. My assumption is that kernel doesn't execute /sbin/init at all, or that /sbin/init doesn't find (or read) /etc/inittab.
  • I read that BusyBox should work fine even without /etc/inittab. So, I removed both /init and /etc/inittab and guess what - kernel panic again.
  • I tried to execute /sbin/init from my shell and after several guesses which included exec /sbin/init, setsid /sbin/init and exec setsid /sbin/init I ended up with kernel panic. Both with and without /etc/inittab being present on the file system.

Here is the content of my /init shell script:

#!/bin/sh
dmesg -n 1
mount -t devtmpfs none /dev
mount -t proc none /proc
mount -t sysfs none /sys
setsid cttyhack /bin/sh

At this point I don't care what the content of the /etc/inittab would be, as long as I have a way to know that the configuration there actually works. I tried several /etc/inittab configurations, all based on the information which I found here.

As a bare minimum my /etc/inittab contained just this one line:

::sysinit:/bin/sh

Again - I ended up with kernel panic and it seems that /etc/inittab was ignored.

Any suggestions how to force my little live distro to work fine with BusyBox's /etc/inittab are highly appreciated!

Update:

  • Just to make it clear - I do not have kernel panic troubles with my current /init shell script both with and without /etc/inittab. It all works fine, my /bin/ash console works great and I don't experience any unexpected troubles. The only issue is that /etc/inittab is completely ignored, as I described above.
  • I examined 3 different live Linux distributions: Slax, Finnix and SysResCD. All of them have /init and none of them have /etc/inittab. In addition this Wiki article concludes my suspicion that /sbin/init is not invoked at all.
hmijail
  • 103
  • 3
Ivan Davidov
  • 501
  • 2
  • 4
  • 13

1 Answers1

13

OK, I did a lot of extensive research and I found out what was wrong. Let's start one by one:

  • When we use initramfs boot scheme the first process which the kernel invokes is the /init script. The kernel will never try to execute /sbin/init directly.
  • /init is assigned process identifier 1. This is very important!
  • The problem now is that /sbin/init can only be started as PID 1 but we are already running /init as PID 1.
  • The solution is to execute the command line exec /sbin/init while we are still inside /init. In this way the new process (which is /sbin/init) will inherit the PID from its parent (/init with PID 1) and that's all we have to do.

The problem I experienced with my initial configuration (see the question) was due to the fact that the last thing my /init script does is to spawn new /bin/sh process which is assigned brand new PID. From this point it's impossible to run /sbin/init directly from interactive console because even when we execute the command line exec /sbin/init, the best we achieve is to assign the same PID which has already been assigned to the shell and this PID is definitely not PID 1.

Long story short - execute the command line exec /sbin/init directly from /init and that's all.

Ivan Davidov
  • 501
  • 2
  • 4
  • 13