Minimalny Linux z jądrem i BusyBox: / etc / inittab jest ignorowany, wykonywany jest tylko / init

Udało mi się stworzyć małą, w pełni funkcjonalną płytę CD z systemem Linux na żywo, która zawiera tylko jądro (skompilowane z domyślnymi opcjami) i BusyBox (skompilowane z domyślnymi opcjami + statyczne, wszystkie aplety są obecne /sbin/init). Nie miałem żadnych problemów, aby utworzyć initrdi wypełnić /dev, /proca /sysi też nie miałem problemów w ogóle z moim /initskrypcie.

Niedawno przeczytałem, że BusyBox obsługuje /etc/inittabkonfiguracje (przynajmniej do pewnego poziomu) i bardzo chciałbym wykonać jedną z następujących czynności:

• Zapomnij o moim /initskrypcie powłoki i polegaj całkowicie na /etc/inittabkonfiguracji.
• Użyj zarówno /initskryptu powłoki, jak i /etc/inittabkonfiguracji.

Teraz faktyczny problem - wygląda na to, że /etc/inittabjest całkowicie ignorowany, gdy moja dystrybucja się uruchamia. Objawami są:

• Kiedy usuwam /initi zostawiam tylko, /etc/inittabkończę z paniką jądra. Zakładam, że jądro w ogóle się nie uruchamia /sbin/initlub /sbin/initnie znajduje (ani nie czyta) /etc/inittab.
• Przeczytałem, że BusyBox powinien działać dobrze nawet bez niego /etc/inittab. Więc usunąłem oba /inita /etc/inittabi zgadnijcie co - Kernel panic ponownie.
• Próbowałem wykonać /sbin/initz mojej powłoki i po kilku zgadywaniach, które zawierały exec /sbin/init, setsid /sbin/initi exec setsid /sbin/initskończyło się na panice jądra. Zarówno z / bez / etc / inittab w systemie plików.

Oto treść mojego /initskryptu powłoki:

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

W tym momencie nie dbam o to, jaka /etc/inittabbyłaby treść , o ile mam sposób wiedzieć, że konfiguracja tam naprawdę działa. Wypróbowałem kilka /etc/inittabkonfiguracji, wszystkie oparte na informacjach, które tu znalazłem .

Jako minimum moje / etc / inittab zawierało tylko jedną linię:

::sysinit:/bin/sh

Znowu - wpadłem w panikę jądra i wygląda na to, że /etc/inittabzostał zignorowany.

Wszelkie sugestie, jak zmusić moją małą dystrybucję na żywo do współpracy z BusyBox, /etc/inittabsą bardzo mile widziane!

Aktualizacja:

• Żeby było jasne - nie mam problemów z paniką jądra w moim obecnym /initskrypcie powłoki zarówno z, jak i bez /etc/inittab. Wszystko działa dobrze, moja /bin/ashkonsola działa świetnie i nie mam żadnych nieoczekiwanych problemów. Jedynym problemem jest to, że /etc/inittabjest całkowicie ignorowane, jak opisałem powyżej.
• Badałem 3 różne dystrybucje Linuksa na żywo: Slax, Finnix i SysResCD. Wszystkie mają /initi nie mają /etc/inittab. Ponadto ten artykuł na Wiki stanowi podsumowanie moich podejrzeń, które /sbin/initw ogóle nie zostały przywołane.

OK, przeprowadziłem wiele obszernych badań i dowiedziałem się, co było nie tak. Zacznijmy jeden po drugim:

• Kiedy używamy initramfsschematu rozruchowego, pierwszym procesem wywoływanym przez jądro jest /initskrypt. Jądro nigdy nie spróbuje wykonać /sbin/initbezpośrednio.
• /init ma przypisany identyfikator 1. procesu. Jest to bardzo ważne!
• Problem polega na tym, że /sbin/initmożna go uruchomić tylko jako, PID 1ale już działamy /initjako PID 1.
• Rozwiązaniem jest wykonanie wiersza poleceń, exec /sbin/initgdy jesteśmy jeszcze w środku /init. W ten sposób nowy proces (który jest /sbin/init) odziedziczy PID od jego rodzica ( /initz PID 1) i to wszystko, co musimy zrobić.

Problem, którego doświadczyłem przy początkowej konfiguracji (patrz pytanie), wynikał z faktu, że ostatnią rzeczą, którą /initrobi mój skrypt, jest odrodzenie nowego /bin/shprocesu, któremu przypisano zupełnie nowy PID. Od tego momentu nie można uruchamiać /sbin/initbezpośrednio z interaktywnej konsoli, ponieważ nawet gdy wykonujemy wiersz poleceń exec /sbin/init, najlepsze, co osiągamy, to przypisanie tego samego PID, który został już przypisany do powłoki, a ten PID zdecydowanie nie jest PID 1.

Krótka historia - uruchom wiersz poleceń exec /sbin/initbezpośrednio z /initi to wszystko.