problems during linux kernel init

Question

What are the possible culprits for crashes during kernel init?

I am running a kernel that has initramfs, the inittab is very basic rcS (as sysinit) and getty (respawn). While booting I don't get any error message, however the init gives me this message: S0 respawning too fast: disabled for 5 minutes, where S0 is actually the respawn::getty line(it seems as getty keep crashing), also none of the messages generated by the rcS are seen on the console (I assume that rcS commands also crashe).

If I force the kernel to go to /bin/sh (instead of /init) I can call rcS manually and I get no errors, same happens for getty (if I call getty with the same params from inittab it works fine).

I am wondering what are the difference between the way init spawns processes and the way /bin/sh does.

Answer 1

Some OS's log init respawns to wtmp, you might want to check there. Turning up your syslog might also help.

When you kick off getty via /bin/sh, does it stay running? AFAIK, the trick with init respawn is that the PID it generates is monitored and if it goes down it kicks off another one.

Answer 2

The stock /bin/sh is not built static, nor is getty. You need to look at the shared library dependencies of /bin/sh and getty that all the libraries are present.

You can use ldd or 'readelf -a' to see the shared library dependencies.

Answer 3

Maybe nothing is setting up /dev/tty1, /dev/tty2, etc, but stuff is running ok on /dev/console (which is not the same thing as /dev/tty1). If you're depending on a /dev directory being in your initramfs or root filesystem, check those.

Probably the main difference between init=/bin/sh and letting init spawn stuff is the /dev/console vs. /dev/ttyx. I can't think of anything else that would be relevant. Keep in mind that the initramfs does run first, I think.

And BTW, you're obviously past the kernel init stage if init(8) or /bin/sh can run.