как отладить upstart, если он зависает, пока root доступен только для чтения?

Я пытаюсь отладить неудачный / зависший запуск системы (upstart) на 14.04.2 LTS. root - это файловая система ext4 в контейнере luks. файловые системы находятся в чистом состоянии.

Процесс загрузки останавливается после upstart-socket-bridge (не обязательно после этой конкретной службы, например, когда был установлен cups-daemon, после этого он останавливался). init -v тоже не очень помогает. Единственная запись в журнале, которая не просто регистрирует запуск / останов различных служб, - это запись об udev прямо перед init.

Begin: Running /scripts/init-bottom ... done.
udev exit failed --rc=2

(Правка) Изначально повторная установка root rw всегда приводила к чистой загрузке, но на самом деле это непредсказуемо, и в любом случае я не смог и успешно загрузился. wut?

Замечание: все выглядит нормально, система просто не перемонтирует доступный для записи корень или продолжает загрузку.

Q: Как определить, какая служба виновата в зависании процесса загрузки?

Обновление: создание второй оболочки через 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) - мое первоначальное наблюдение, что принудительное использование корня с возможностью записи в корне обходит проблему, неверно

Обход проблемы:

Похоже, что это ошибка ureadahead. Чистка привела к 5 чистым ботинкам без каких-либо проблем. Я просто оставлю вопрос (и 100 дополнительных повторений) открытым для всех, кто интересуется или знает ответ на оригинальный вопрос: как, если бы не путем случайного испытания, я мог бы это выяснить.