Linux minimal avec noyau et BusyBox: / etc / inittab est ignoré, seul / init est exécuté

J'ai réussi à créer un petit CD Linux live entièrement fonctionnel qui ne contient que le noyau (compilé avec les options par défaut) et BusyBox (compilé avec les options par défaut + statique, toutes les applets présentes, y compris /sbin/init). Je n'ai eu aucun problème à créer initrdet à remplir /dev, /procet /sysje n'ai eu aucun problème avec mon /initscript shell.

Récemment, j'ai lu que BusyBox prend en charge les /etc/inittabconfigurations (au moins à un certain niveau) et j'aimerais beaucoup faire l'une des choses suivantes:

• Oubliez mon /initscript shell et comptez entièrement sur la /etc/inittabconfiguration.
• Utilisez à la fois le /initscript shell et la /etc/inittabconfiguration.

Maintenant, le problème réel - il semble que ce /etc/inittabsoit complètement ignoré lorsque ma distribution démarre. Les symptômes sont:

• Quand je retire /initet laisse seulement, /etc/inittabje me retrouve avec la panique du noyau. Mon hypothèse est que le noyau ne s'exécute pas /sbin/initdu tout, ou qu'il /sbin/initne trouve pas (ou ne lit pas) /etc/inittab.
• J'ai lu que BusyBox devrait bien fonctionner même sans /etc/inittab. Donc, j'ai supprimé les deux /initet /etc/inittabet devinez quoi - la panique du noyau à nouveau.
• J'ai essayé d'exécuter à /sbin/initpartir de mon shell et après plusieurs suppositions qui comprenaient exec /sbin/init, setsid /sbin/initet exec setsid /sbin/initje me suis retrouvé avec la panique du noyau. Avec et sans / etc / inittab présent sur le système de fichiers.

Voici le contenu de mon /initscript 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

À ce stade, je me fiche du contenu du /etc/inittab, tant que j'ai un moyen de savoir que la configuration y fonctionne réellement. J'ai essayé plusieurs /etc/inittabconfigurations, toutes basées sur les informations que j'ai trouvées ici .

Au minimum, mon / etc / inittab ne contenait qu'une seule ligne:

::sysinit:/bin/sh

Encore une fois - je me suis retrouvé avec une panique du noyau et il semble que cela ait /etc/inittabété ignoré.

Toutes les suggestions pour forcer ma petite distribution en direct à fonctionner correctement avec BusyBox /etc/inittabsont très appréciées!

Mise à jour:

• Juste pour être clair - je n'ai pas de problèmes de panique du noyau avec mon /initscript shell actuel avec et sans /etc/inittab. Tout fonctionne bien, ma /bin/ashconsole fonctionne très bien et je ne rencontre aucun problème inattendu. Le seul problème est qu'il /etc/inittabest complètement ignoré, comme je l'ai décrit ci-dessus.
• J'ai examiné 3 distributions Linux live différentes: Slax, Finnix et SysResCD. Tous l'ont fait /initet aucun ne l'a fait /etc/inittab. De plus, cet article Wiki conclut ma suspicion qui /sbin/initn'est pas du tout invoquée.

OK, j'ai fait beaucoup de recherches approfondies et j'ai découvert ce qui n'allait pas. Commençons un par un:

• Lorsque nous utilisons initramfsle schéma de démarrage, le premier processus que le noyau invoque est le /initscript. Le noyau n'essaiera jamais de s'exécuter /sbin/initdirectement.
• /init se voit attribuer l'identifiant de processus 1. C'est très important!
• Le problème est que /sbin/initcela ne peut être démarré qu'en tant que PID 1mais nous fonctionnons déjà en /inittant que PID 1.
• La solution consiste à exécuter la ligne de commande exec /sbin/initalors que nous sommes encore à l'intérieur /init. De cette façon, le nouveau processus (qui est /sbin/init) héritera du PID de son parent ( /initavec PID 1) et c'est tout ce que nous avons à faire.

Le problème que j'ai rencontré avec ma configuration initiale (voir la question) est dû au fait que la dernière chose que mon /initscript fait est de générer un nouveau /bin/shprocessus auquel est attribué un tout nouveau PID. À partir de là, il est impossible de s'exécuter /sbin/initdirectement à partir de la console interactive, car même lorsque nous exécutons la ligne de commande exec /sbin/init, le mieux que nous obtenons est d'attribuer le même PID qui a déjà été attribué au shell et ce PID n'est certainement pas le PID 1.

Pour faire court - exécutez la ligne de commande exec /sbin/initdirectement depuis /initet c'est tout.