как отладить upstart, если он зависает, когда root имеет права только на чтение?

как отладить upstart, если он зависает, когда root имеет права только на чтение?

Я пытаюсь отладить неудавшийся/зависший запуск системы (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, чтобы выяснить, какие службы находятся в каком состоянии

Связанный контент