Поиск неисправностей, или Агония Поражения
При создании загрузочных дискет, первые несколько попыток часто не будут
загружаться. Общий подход к созданию корневого диска - собрать компоненты из
вашей существующей системы, и пробовать довести систему на дискете до
состояния, когда она начнет показывать сообщения на консоли. Как только она
начнет говорить с Вами, половина сражения выиграна, так как Вы сможете
увидеть, на что она жалуется, и сможете устранить индивидуальные проблемы,
пока она не заработает гладко. Если система просто зависает без объяснений,
найти причину может быть весьма трудно. Рекомендуемая процедура
исследования проблемы, когда система с Вами не разговаривает, такова:
Вы можете увидеть такое сообщение:
Kernel panic: VFS: Unable to mount root fs on XX:YY
Это частая проблема и может иметь несколько причин. Во-первых, проверьте
устройство XX:YY по списку кодов устройств в
/usr/src/linux/Documentation/devices.txt; Если он не
правилен, Вы, возможно, не сделали rdev -R, или сделали
с неправильным образом файловой системы. Если код устройства правильный, тогда
тщательно проверьте, скомпилирован ли драйвер вашего устройства встроенным.
Убедитесь, что у Вас встроенная поддержка дискеты, ramdisk и файловой системы
ext2.Если Вы видите много подобных ошибок:
end_request: I/O error, dev 01:00 (ramdisk), sector NNN
Это ошибка ввода-вывода драйвера ramdisk, обычно из-за попыток ядра записать
за пределом (за концом) устройства. Ramdisk слишком мал для корневой файловой
системы. Проверьте сообщения инициализации ядра вашего диска на предмет строки
вида:
Ramdisk driver initialized : 16 ramdisks of 4096K size
Сравните этот размер с размером распакованной корневой
файловой системы. Если размер ramdisk-ов не достаточно велик - увеличьте его.Проверьте, что корневой диск на самом деле содержит каталоги, которые Вы
предполагаете. Достаточно просто что-то скопировать неправильно, чтобы Вы
получили на вашей корневой дискете что-то вроде
/rootdisk/bin вместо /bin.
Проверьте наличие /lib/libc.so с той же самой ссылкой,
как и в каталоге /lib на вашем жестком диске.
Проверьте, что любые символические ссылки в каталоге /dev
в существующей системе также существуют на корневой файловой системе дискеты,
и эти ссылки к устройствам, которые Вы включили в корневую дискету. В
частности ссылка /dev/console необходима во многих
случаях. Проверьте, что Вы включили файлы /dev/tty1, /dev/null, /dev/zero,
/dev/mem, /dev/ram и /dev/kmem.
Проверьте конфигурацию ядра - поддержка всех ресурсов, требуемых до
точки входа в систему(login) должна быть встроенная, не модулями. Так
поддержка ramdisk и ext2 должна быть встроена. Проверьте правильность установки корневого устройства в ядре и правильность
настроек ramdisk.
Если эти общие аспекты были рассмотрены, есть несколько более характерных
файлов для проверки:
Проверьте, что init включен как
/sbin/init или /bin/init.
Проверьте, что установлен атрибут исполняемый. Выполните ldd init, чтобы проверить библиотеки init. Обычно
это всего лишь libc.so, но все равно проверьте.
Удостоверитесь, что Вы включили необходимые библиотеки и загрузчики. Проверьте, что у Вас правильный загрузчик для ваших библиотек --
ld.so для a.out или ld-linux.so
для ELF.
Проверьте в /etc/inittab на вашей загрузочной файловой
системе вызовы getty (или какой-либо другой
getty-подобной программы, такой как
agetty, mgetty или
getty_ps). Дважды еще раз проверьте
inittab, сравнивая с файлом на Вашем жестком диске.
Проверьте man страницы используемой программы и удостоверьтесь, что все опции имеют смысл. inittab - возможно
хитростная часть, так как его синтаксис и содержание зависит от используемой
программы init и характера системы. Единственный способ разобраться с этим —
читать man страницы init и
inittab и понять, что делает ваша существующая система
при загрузке. Проверьте, что /etc/inittab содержит запись
инициализации системы. Она должна содержать команду выполнения сценария
инициализации системы, который должен существовать. Как и с init, запустите ldd на
getty, посмотрите, что ей требуется, и удостоверьтесь,
что необходимые библиотечные файлы и загрузчики были включены в вашу корневую
файловую систему. Убедитесь, что Вы включили программу оболочки (такие как
bash или ash) способную выполнять все
ваши rc сценарии.
Если на вашем спасательном диске есть файл
/etc/ld.so.cache , пересоздайте его.
Если init запустился, но Вы получаете сообщения:
Id xxx respawning too fast: disabled for 5 minutes
Оно исходит от init, и обычно указывает, что
getty или login умирает, как только
начинает выполняться. Проверьте исполняемые файлы getty и
login и зависимые библиотеки. Удостоверьтесь, что
содержимое /etc/inittab корректно. Если Вы получаете
странные сообщения от getty, они могут означать, что форма
вызова в /etc/inittab неправильна. Если Вы получаете приглашение к входу и вводите правильное регистрационное имя, но система сразу заново запрашивает у Вас другое имя - проблема может быть с PAM
или NSS. Смотрите секцию Разд. Обеспечение PAM и NSS.. Проблема также может быть
в использовании вами скрытых паролей, и не скопированном на ваш загрузочный
диск /etc/shadow. Если Вы пытаетесь выполнять некоторые находящиеся на вашем спасательном диске
программы, такие как df, но получаете сообщение:
df: not found, проверьте две вещи: (1)
Каталог, содержащий исполняемый файл находится в переменной PATH, и (2)
У Вас есть библиотеки (и загрузчики), которые нужны программам.
|