Linux kernel init problems

What are the possible culprits for crashes during kernel initialization?

I am starting kernel with initramfs, inittab is very simple rcS (like sysinit) and getty (respawn). I don't get an error during boot, however init gives me this message: S0 respawning is too fast: disabled for 5 minutes, where S0 is actually the respawn :: getty pipe (it seems like getty keeps crashing), also none from the messages generated by rcS does not show up on the console (I assume rcS commands also crash).

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

I am wondering what is the difference between the init process and the / bin / sh way.

0


a source to share


3 answers


In some versions of the OS log on wtmp, you can check there. It might also help to enable your syslog.



When you run getty through / bin / sh, does it stay on? AFAIK, the trick with init respawn is that the PID it generates is monitored and if it goes down it starts another one.

0


a source


The share / bin / sh is not built statically, not getty. You should look at the common dependency libraries / bin / sh and getty that all libraries are present.



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

0


a source


Maybe nothing is configured /dev/tty1

, /dev/tty2

etc., but stuff works fine on /dev/console

(which is not the same as /dev/tty1

). If you are in your initramfs or root filesystem depending on the / dev directory, check them.

Probably the main difference between init = / bin / sh and initwn's initialization capability is /dev/console

vs. /dev/ttyx

... I cannot think of anything else that would be relevant. Keep in mind that initramfs gets started first I guess.

And BTW, you've obviously gone through the kernel initialization phase if init (8) or /bin/sh

.

0


a source







All Articles