Мінімальний Linux з ядром та BusyBox: / etc / inittab ігнорується, виконується тільки / init

Мені вдалося створити невеликий і повністю функціональний живий компакт-диск Linux, який містить лише ядро ​​(компільований з параметрами за замовчуванням) та BusyBox (компільований із параметрами за замовчуванням + статичний, усі наявні аплети, в тому числі /sbin/init). У мене не було проблем зі створенням initrdта заповненням /dev, /procа /sysтакож у мене не було проблем із /initсценарієм оболонки.

Нещодавно я прочитав, що BusyBox підтримує /etc/inittabконфігурації (принаймні до якогось рівня) і дуже хотів би зробити що-небудь із наступного:

• Забудь про мій /initскрипт оболонки і повністю покладайся на /etc/inittabконфігурацію.
• Використовуйте як /initсценарій оболонки, так і /etc/inittabконфігурацію.

Тепер актуальна проблема - здається, /etc/inittabвона повністю ігнорується, коли мій дистрибутив завантажується. Симптоми:

• Коли я видаляю /initі залишаю лише /etc/inittabя закінчую паніку ядра. Моє припущення полягає в тому, що ядро ​​взагалі не виконується /sbin/initабо /sbin/initне знаходить (чи читає) /etc/inittab.
• Я читав, що BusyBox повинен працювати добре навіть без /etc/inittab. Отже, я видалив /initі те, /etc/inittabі вгадаю, що - ядро ​​знову панікує.
• Я спробував виконати /sbin/initсвою оболонку і після кількох здогадок, які включали exec /sbin/init, setsid /sbin/initі exec setsid /sbin/initя закінчився панікою ядра. У файловій системі присутній і без / etc / inittab.

Ось вміст мого /initсценарію оболонки:

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

На даний момент мені байдуже, який буде вміст /etc/inittab, доки я маю спосіб дізнатися, що конфігурація там насправді працює. Я спробував декілька /etc/inittabконфігурацій, всі засновані на інформації, яку я знайшов тут .

Як мінімум, мій / etc / inittab містив лише цей один рядок:

::sysinit:/bin/sh

Знову - я закінчився панікою з ядрами, і, здається, це /etc/inittabбуло проігноровано.

Будь-які пропозиції, як змусити мій маленький дистрибутив жити, щоб добре працювати з BusyBox, /etc/inittabвисоко оцінюються!

Оновлення:

• Просто для того, щоб було зрозуміло - у мене не виникає проблем з панікою ядра з моїм поточним /initсценарієм оболонки як з, так і без /etc/inittab. Все працює добре, моя /bin/ashконсоль працює чудово, і я не відчуваю жодних несподіваних проблем. Єдине питання, яке /etc/inittabповністю ігнорується, як я описав вище.
• Я розглянув 3 різні дистрибутивні версії Linux: Slax, Finnix та SysResCD. Усі вони мають /initі жодного з них не мають /etc/inittab. Окрім цього, ця стаття у Вікі робить висновок про мою підозру, що її /sbin/initвзагалі не викликають.

Гаразд, я провів багато обширних досліджень і з’ясував, що не так. Почнемо по черзі:

• Коли ми використовуємо initramfsсхему завантаження, першим процесом, до якого викликається ядро, є /initсценарій. Ядро ніколи не намагатиметься виконати /sbin/initбезпосередньо.
• /init присвоюється ідентифікатор процесу 1. Це дуже важливо!
• Зараз проблема полягає в тому, що /sbin/initїї можна запустити лише так, PID 1але ми вже працюємо /initяк PID 1.
• Рішення полягає в тому, щоб виконати командний рядок, exec /sbin/initпоки ми все ще знаходимось всередині /init. Таким чином новий процес (який є /sbin/init) успадкує PID від свого батьківського ( /initз PID 1), і це все, що ми повинні зробити.

Проблема, яку я зіткнулася з моєю початковою конфігурацією (див. Питання), була пов'язана з тим, що останнє, що /initробиться моїм сценарієм, - це породити новий /bin/shпроцес, якому присвоєний абсолютно новий PID. З цього моменту неможливо запустити /sbin/initбезпосередньо інтерактивну консоль, тому що навіть коли ми виконуємо командний рядок exec /sbin/init, найкраще, що ми досягаємо, - це призначити той самий PID, який вже був призначений оболонці, і цей PID точно не є PID 1.

Коротка історія - виконайте командний рядок exec /sbin/initбезпосередньо з /initцього і все.