Linux mínimo con kernel y BusyBox: / etc / inittab se ignora, solo se ejecuta / init

Logré crear un CD de Linux en vivo pequeño y completamente funcional que contiene solo kernel (compilado con opciones predeterminadas) y BusyBox (compilado con opciones predeterminadas + estático, todos los applets presentes, incluidos /sbin/init). No tuve problemas para crear initrdy completar /dev, /procy /systampoco tuve ningún problema con mi /initscript de shell.

Recientemente leí que BusyBox admite /etc/inittabconfiguraciones (al menos hasta cierto nivel) y me gustaría mucho hacer cualquiera de los siguientes:

• Olvídate de mi /initscript de shell y confía completamente en la /etc/inittabconfiguración.
• Utilice tanto el /initscript de shell como la /etc/inittabconfiguración.

Ahora el problema real: parece que /etc/inittabse ignora por completo cuando se inicia mi distribución. Los síntomas son:

• Cuando elimino /inity dejo solo /etc/inittabtermino con pánico en el núcleo. Mi suposición es que el kernel no se ejecuta /sbin/initen absoluto, o que /sbin/initno encuentra (o lee) /etc/inittab.
• Leí que BusyBox debería funcionar bien incluso sin él /etc/inittab. Por lo tanto, me quita tanto /inity /etc/inittaby supongo que lo que - de pánico del kernel nuevo.
• Traté de ejecutar /sbin/initdesde mi shell y después de varias conjeturas que incluyeron exec /sbin/init, setsid /sbin/inity exec setsid /sbin/initterminé con kernel panic. Tanto con / sin / etc / inittab como presente en el sistema de archivos.

Aquí está el contenido de mi /initscript de shell:

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

En este punto no me importa cuál sería el contenido de la /etc/inittab, siempre y cuando tenga una manera de saber que la configuración allí realmente funciona. Intenté varias /etc/inittabconfiguraciones, todas basadas en la información que encontré aquí .

Como mínimo, mi / etc / inittab contenía solo esta línea:

::sysinit:/bin/sh

Una vez más, terminé con kernel panic y parece que /etc/inittabfue ignorado.

Cualquier sugerencia sobre cómo forzar mi pequeña distribución en vivo para que funcione bien con BusyBox /etc/inittabes muy apreciada.

Actualizar:

• Solo para aclararlo: no tengo problemas de kernel panic con mi /initscript de shell actual con y sin /etc/inittab. Todo funciona bien, mi /bin/ashconsola funciona muy bien y no experimento ningún problema inesperado. El único problema es que /etc/inittabse ignora por completo, como describí anteriormente.
• Examiné 3 distribuciones de Linux en vivo diferentes: Slax, Finnix y SysResCD. Todos tienen /inity ninguno tiene /etc/inittab. Además, este artículo de Wiki concluye mi sospecha de que /sbin/initno se invoca en absoluto.

Bien, investigué mucho y descubrí lo que estaba mal. Comencemos uno por uno:

• Cuando usamos initramfsel esquema de arranque, el primer proceso que invoca el núcleo es el /initscript. El núcleo nunca intentará ejecutarse /sbin/initdirectamente.
• /init se le asigna el identificador de proceso 1. ¡Esto es muy importante!
• El problema ahora es que /sbin/initsolo se puede iniciar como PID 1pero ya estamos ejecutando /initcomo PID 1.
• La solución es ejecutar la línea de comando exec /sbin/initmientras aún estamos dentro /init. De esta manera, el nuevo proceso (que es /sbin/init) heredará el PID de su padre ( /initcon PID 1) y eso es todo lo que tenemos que hacer.

El problema que experimenté con mi configuración inicial (vea la pregunta) se debió al hecho de que lo último que hace mi /initscript es generar un nuevo /bin/shproceso al que se le asigna un PID nuevo. Desde este punto, es imposible ejecutar /sbin/initdirectamente desde la consola interactiva porque incluso cuando ejecutamos la línea de comando exec /sbin/init, lo mejor que podemos lograr es asignar el mismo PID que ya se ha asignado al shell y este PID definitivamente no es PID 1.

Larga historia corta: ejecute la línea de comando exec /sbin/initdirectamente desde /inity eso es todo.