Я пытаюсь отладить неудавшийся/зависший запуск системы (upstart) на 14.04.2 LTS. Корень — это файловая система ext4 в контейнере luks. Файловые системы находятся в чистом состоянии.
Процесс загрузки останавливается после upstart-socket-bridge (не обязательно после этой конкретной службы, например, когда был установлен cups-daemon, он остановился после этого). init -v
тоже не очень помогает. Единственная запись в журнале, которая не просто регистрирует запуск/остановку различных служб, это запись об udev прямо перед init.
Begin: Running /scripts/init-bottom ... done.
udev exit failed --rc=2
(Изменить) Поначалу казалось, что повторное монтирование корневого раздела всегда приводит к чистой загрузке, но на самом деле это довольно непредсказуемо, и у меня были как неудачные, так и успешные загрузки в обоих случаях. Что?
Наблюдение: Все выглядит нормально, система просто не перемонтирует корневой раздел с возможностью записи или не продолжает загрузку.
В:Как определить, какая служба виновата в зависании процесса загрузки?
Обновление: создание второй оболочки через getty, которую можно запустить initctl list
после того, как она зависнет, это запущенные задания
mountnfs-bootclean.sh start/running
udev start/running, process 438
upstart-udev-bridge start/running, process 432
plymouth start/running, process 122
resolvconf start/running
ssh start/running, process 767 <-- this one was manually started
mountall start/running, process 337
mountkernfs.sh start/running
mountnfs.sh start/running
bootmisc.sh start/running
upstart-socket-bridge start/running, process 745**
cryptdisks start/running
mountdevsubfs.sh start/running
mtab.sh start/running
network-interface (lo) start/running
network-interface (eth0) start/running
plymouth-ready (startup) start/running, process 315
plymouth-upstart-bridge start/running, process 316
mountall-bootclean.sh start/running
network-interface-security (network-interface/eth0) start/running
network-interface-security (network-interface/lo) start/running
Обновление 2:
- Переустановка upstart и всех его зависимых пакетов (это мучение и) не дает никакого эффекта.
- Используя вторую консоль, я могу просто
init 5
заставить зависшую систему продолжить загрузку в обычном режиме. - теперь система зависала, даже если я вручную перемонтировал корневой раздел rw (или использовал параметр ядра rw) - мое первоначальное наблюдение, что принудительное разрешение записи root работает для решения проблемы, неверно
Обходной путь:
Похоже, это ureadahead
ошибка. Очистка привела к 5 чистым ботинкам без каких-либо проблем. Я просто оставлю вопрос (и 100 дополнительных репутаций) открытым для тех, кому интересно или кто знает ответ на изначальный вопрос: как, если не методом случайных проб, я мог бы это выяснить.
решение1
Для справки, (безуспешные) шаги отладки, которые я попробовал, но которые, тем не менее, могут быть полезны другим:
- возьмите другую Debian-подобную систему, которая загружается (например, Live Ubuntu на загрузочном USB-накопителе) и внесите изменения в конфигурацию или программное обеспечение исследуемой системы с помощью chroot. Используйте qemu-static, чтобы сделать это в системе с другой архитектурой.
- установите автономную оболочку, например
sash
, затем измените командную строку ядра (используйте клавишу e в grub или отредактируйте grub.cfg/cmdline.txt) и добавьтеinit=/bin/sash
, перезагрузитесь, проверьте ситуацию в этой оболочке и только затем используйтеexec init
для продолжения загрузки - используйте
init
с-v
переключателем для увеличения ведения журнала - смонтируйте корневую файловую систему с возможностью записи заранее (например, добавьте «rw» в командную строку ядра
mount -o remount,rw /
перед выполнением init) — это позволяет вести больше журналов - исследовать
/var/log/upstart
- запустите дополнительный терминал на tty2 перед выполнением init, например,
getty -n -l /bin/bash 38400 tty2 &
- это помогает проверить состояние, в котором находится система (напримерps -Af
,iotop
) - используйте
initctl list
, чтобы выяснить, какие службы находятся в каком состоянии