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ć initrd
i wypełnić /dev
, /proc
a /sys
i też nie miałem problemów w ogóle z moim /init
skrypcie.
Niedawno przeczytałem, że BusyBox obsługuje /etc/inittab
konfiguracje (przynajmniej do pewnego poziomu) i bardzo chciałbym wykonać jedną z następujących czynności:
- Zapomnij o moim
/init
skrypcie powłoki i polegaj całkowicie na/etc/inittab
konfiguracji. - Użyj zarówno
/init
skryptu powłoki, jak i/etc/inittab
konfiguracji.
Teraz faktyczny problem - wygląda na to, że /etc/inittab
jest całkowicie ignorowany, gdy moja dystrybucja się uruchamia. Objawami są:
- Kiedy usuwam
/init
i zostawiam tylko,/etc/inittab
kończę z paniką jądra. Zakładam, że jądro w ogóle się nie uruchamia/sbin/init
lub/sbin/init
nie znajduje (ani nie czyta)/etc/inittab
. - Przeczytałem, że BusyBox powinien działać dobrze nawet bez niego
/etc/inittab
. Więc usunąłem oba/init
a/etc/inittab
i zgadnijcie co - Kernel panic ponownie. - Próbowałem wykonać
/sbin/init
z mojej powłoki i po kilku zgadywaniach, które zawierałyexec /sbin/init
,setsid /sbin/init
iexec setsid /sbin/init
skończyło się na panice jądra. Zarówno z / bez / etc / inittab w systemie plików.
Oto treść mojego /init
skryptu 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/inittab
byłaby treść , o ile mam sposób wiedzieć, że konfiguracja tam naprawdę działa. Wypróbowałem kilka /etc/inittab
konfiguracji, 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/inittab
został zignorowany.
Wszelkie sugestie, jak zmusić moją małą dystrybucję na żywo do współpracy z BusyBox, /etc/inittab
są bardzo mile widziane!
Aktualizacja:
- Żeby było jasne - nie mam problemów z paniką jądra w moim obecnym
/init
skrypcie powłoki zarówno z, jak i bez/etc/inittab
. Wszystko działa dobrze, moja/bin/ash
konsola działa świetnie i nie mam żadnych nieoczekiwanych problemów. Jedynym problemem jest to, że/etc/inittab
jest całkowicie ignorowane, jak opisałem powyżej. - Badałem 3 różne dystrybucje Linuksa na żywo: Slax, Finnix i SysResCD. Wszystkie mają
/init
i nie mają/etc/inittab
. Ponadto ten artykuł na Wiki stanowi podsumowanie moich podejrzeń, które/sbin/init
w ogóle nie zostały przywołane.
Odpowiedzi:
OK, przeprowadziłem wiele obszernych badań i dowiedziałem się, co było nie tak. Zacznijmy jeden po drugim:
initramfs
schematu rozruchowego, pierwszym procesem wywoływanym przez jądro jest/init
skrypt. Jądro nigdy nie spróbuje wykonać/sbin/init
bezpośrednio./init
ma przypisany identyfikator 1. procesu. Jest to bardzo ważne!/sbin/init
można go uruchomić tylko jako,PID 1
ale już działamy/init
jako PID 1.exec /sbin/init
gdy jesteśmy jeszcze w środku/init
. W ten sposób nowy proces (który jest/sbin/init
) odziedziczy PID od jego rodzica (/init
z 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ą
/init
robi mój skrypt, jest odrodzenie nowego/bin/sh
procesu, któremu przypisano zupełnie nowy PID. Od tego momentu nie można uruchamiać/sbin/init
bezpoś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/init
bezpośrednio z/init
i to wszystko.źródło