como depurar o upstart se ele trava enquanto o root é somente leitura?

Question

Eu estou tentando depurar uma inicialização do sistema (upstart) sem necessidade / desligada em 14.04.2 LTS. root é um sistema de arquivos ext4 em um container luks. os sistemas de arquivos estão no estado limpo.

O processo de inicialização pára após o upstart-socket-bridge, (não necessariamente após esse serviço específico, por exemplo, quando cups-daemon foi instalado, ele parou depois disso). init -v não é muito útil também. A única entrada de log que não está meramente registrando o início / parada de vários serviços é sobre o udev antes do init.

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

(Edit) Remontar o root rw inicialmente parecia estar sempre levando a uma inicialização limpa, mas fato é, é meio imprevisível e eu tive falhas e botas de sucesso de qualquer maneira. wut?

Observação: tudo parece estar bem, o sistema simplesmente não remonta a raiz gravável ou continua a inicialização.

P: Como faço para descobrir qual serviço é o culpado pelo processo de inicialização?

Update: Gerando um segundo shell via getty pode-se rodar initctl list depois que ele desliga, estes são os jobs em execução

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

Atualização 2:

• Reinstalar o upstart e todos os seus pacotes dependentes (é uma dor e) não tem efeito.
• Usando o segundo console, posso usar apenas init 5 para ficar preso sistema para continuar a inicialização normalmente.
• o sistema agora ficou preso mesmo que eu remontasse manualmente a raiz rw (ou usei o parâmetro do kernel rw) - minha observação inicial de que forçar os trabalhos graváveis da raiz em torno do problema está incorreto

Solução alternativa:

Parece ser uma falha ureadahead s. Purgar resultou em 5 botas limpas sem qualquer problema. Vou deixar a pergunta (e o representante extra de 100) aberta para qualquer pessoa interessada ou saber uma resposta para a pergunta original: como, se não por tentativa aleatória, eu poderia ter descoberto isso.

    

Answer 1

Para referência, as etapas de depuração (sem êxito) que eu tentei, que, no entanto, podem ser úteis para outras pessoas:

• obtenha outro sistema semelhante ao debian que inicializa (por exemplo, um Ubuntu ao vivo em um pen drive USB inicializável) e faça alterações de configuração ou software no sistema examinado usando o chroot. use o qemu-static para poder fazer isso em um sistema com arquitetura diferente.
• instalar um shell autônomo como sash , em seguida, alterar a linha de comando do kernel (use a tecla e no grub ou editar grub.cfg / cmdline.txt) e adicionar init=/bin/sash , reiniciar, examinar a situação em que a Shell e só então use exec init para continuar a inicialização
• use init com a opção -v para aumentar o log
• monte o sistema de arquivos raiz gravável antes (por exemplo, adicione 'rw' à linha de comando do kernel, mount -o remount,rw / antes de executar o init) - isso permite mais registros
• examine /var/log/upstart
• inicie um terminal extra em tty2 antes de executar o init, por ex. getty -n -l /bin/bash 38400 tty2 & - ajuda a examinar o status no qual o sistema está (por exemplo, ps -Af , iotop )
• use initctl list para descobrir quais serviços estão em qual estado