7. Поиск неисправностей, или Агония Поражения.

При создании загрузочных дискет, первые немногие попытки часто не будут загружаться. Общий подход к созданию корневого диска - собрать компоненты из вашей существующей системы, и пробовать и получить основанную на дискете систему, когда она начнет показывает сообщения на консоли. Как только она начинает говорить с Вами, половина сражения выиграна, потому что Вы можете видеть, на что она жалуется, и Вы можете устранять индивидуальные проблемы, пока система не заработает гладко. Если система только зависает без объяснений, найти причину весьма трудно. Чтобы получить систему загружающуюся до состояния, когда она будет разговаривать с Вами, требуется присутствие нескольких компонентов и правильная конфигурация. Рекомендуемая процедура для исследования проблемы, когда система не разговаривает с Вами, следующая:

• Вы можете увидеть сообщение, подобное этому:

  
  Kernel panic: VFS: Unable to mount root fs on XX:YY
  
  

  Это частая проблема и может иметь несколько причин. Первая, проверьте устройство XX:YY по списку кодов устройства; это правильное корневое устройство? Если нет, Вы возможно не сделали rdev -R, или сделали это с неправильным образом. Если код устройства правильный, тогда тщательно проверьте скомпилирован ли драйвер вашего устройства встроенным. Убедитесь, что поддержка дискеты, ramdisk и ext2 файловой системы встроенная.
• Проверьте, что корневой диск фактически содержит каталоги, которые Вы думаете. Достаточно просто скопировать неправильно, чтобы Вы получили что-то вроде /rootdisk/bin вместо /bin на вашей корневой дискете.
• Проверьте наличие /lib/libc.so так с той же самой ссылкой, как и в вашем /lib каталоге на жестком диске.
• Проверьте, что любые символические ссылки в вашем /dev каталоге в вашей существующей системе также существуют на вашей корневой файловой системе дискеты, и что эти ссылки к устройствам, которые Вы включили в вашу корневую дискету. В частности /dev/console ссылка необходима во многих случаях.
• Проверьте, что Вы включили /dev/tty1, /dev/null, /dev/zero, /dev/mem, /dev/ram и /dev/kmem файлы.
• Проверьте конфигурацию ядра - поддержка всех ресурсов, требуемых до точки входа в систему должна быть встроенная, не модулями. Так поддержка ramdisk и ext2 должна быть встроена.
• Проверьте правильность установок ядра для вашего корневого устройства и ramdisk.

Если эти общие аспекты были рассмотрены, есть несколько более специфических файлов для проверки:

1. Удостоверитесь, что init включен как /sbin/init или /bin/init. Удостоверьтесь, что установлен атрибут исполняемый.
2. Выполните ldd init, чтобы проверить библиотеки init. Обычно это - только libc.so, но проверьте все равно. Удостоверитесь, что Вы включили необходимые библиотеки и загрузчики.
3. Удостоверитесь, что у Вас правильный загрузчик для ваших библиотек --- ld.so для a.out или ld-linux.so для ELF.
4. Проверьте в /etc/inittab на вашей загрузочной файловой системе вызовов getty (или некоторой getty-подобной программы, типа agetty, mgetty или getty_ps). Проверьте man страницы программы, которую Вы используете, чтобы удостовериться, что они имеют смысл. inittab - возможно хитростная часть, потому что синтаксис и содержание зависит от используемой программы init и характера системы. Единственный способ заняться этим состоит в том, чтобы читать man страницы для init и inittab и понять, что делает ваша существующая система, когда она загружается. Удостоверьтесь, что /etc/inittab содержит запись инициализации системы. Она должна содержать команду, для выполнения сценария инициализации системы, который должен существовать.
5. Как с init, выполните ldd на вашем getty, чтобы увидеть, что ей требуется, и удостоверьтесь, что необходимые библиотечные файлы и загрузчики были включены в вашу корневую файловую систему.
6. Убедитесь, что Вы включили программу оболочки (например, bash или ash) способную к выполнению всех ваших rc сценариев.
7. Если у Вас есть /etc/ld.so.cache файл на вашем спасательном диске, пересоздайте его.

Если init запустился, но Вы получаете сообщения:

        Id xxx respawning too fast: disabled for 5 minutes  

Это исходит от init, обычно указывает, что getty или login умирает, как только начинает выполняться. Проверьте бинарники getty и login и зависимые библиотеки. Удостоверьтесь, что содержимое /etc/inittab корректно. Если Вы получаете странные сообщения от getty, это может означать, что форма вызова в /etc/inittab неправильна. Опции программ getty различны; даже разные версии agetty, как сообщают, имеют различные несовместимые формы вызова.

Если Вы получаете приглашение к входу и вводите правильный login, но система сразу запрашивает у Вас другое имя - проблема может быть с PAM или NSS. Смотри секцию PAM и NSS. Проблема может быть также в использовании вами скрытых паролей, и не скопированном /etc/shadow на ваш загрузочный диск.

Если Вы пытаетесь выполнять некоторые программы, типа df, который находится на вашем спасательном диске, но Вы получаете сообщение: df: not found, проверьте две вещи: ( 1) Удостоверьтесь, что каталог содержащий программу df находится в переменной PATH, и ( 2) удостоверьтесь, что у Вас есть библиотеки (и загрузчики), которые нужны программам.

---