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

Question

Estou tentando depurar uma inicialização do sistema sem sucesso/desligada (upstart) em 14.04.2 LTS. root é um sistema de arquivos ext4 em um contêiner luks. os sistemas de arquivos estão em estado limpo.

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

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

(Editar) Remontar o root rw inicialmente parecia sempre levar a uma inicialização limpa, mas o fato é que é meio imprevisível e eu falhei e inicializei com sucesso de qualquer maneira. que?

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

P:Como descubro qual serviço é o culpado por travar o processo de inicialização?

---

Atualização: gerar um segundo shell via getty pode ser executado initctl listdepois que ele desliga, esses são os trabalhos 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 apenas usar init 5para fazer com que o sistema travado continue a inicialização normalmente.
• o sistema agora travou mesmo se eu remontasse manualmente o root rw (ou usasse o parâmetro rw do kernel) - minha observação inicial de que forçar o root gravável funciona em torno do problema está incorreta

---

Gambiarra:

Parece que é ureadaheadculpa. A purga resultou em 5 botas limpas sem nenhum problema. Deixarei apenas a pergunta (e as 100 repetições extras) em aberto para qualquer pessoa interessada ou que saiba 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 sucesso) que tentei, mas podem ser úteis para outras pessoas:

• obtenha outro sistema semelhante ao Debian que inicialize (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 chroot. use qemu-static para poder fazer isso em um sistema com arquitetura diferente.
• instale um shell independente como sash, em seguida, altere a linha de comando do kernel (use a tecla e no grub ou edite grub.cfg/cmdline.txt) e adicione init=/bin/sash, reinicie, examine a situação nesse shell e só então use exec initpara continuar a inicialização
• use initcom o -vswitch para aumentar o registro
• monte o sistema de arquivos raiz gravável antecipadamente (por exemplo, adicione 'rw' à linha de comando do kernel, mount -o remount,rw /antes de executar o init) - isso permite mais registros
• examinar/var/log/upstart
• inicie um terminal extra em tty2 antes de executar o init, por exemplo getty -n -l /bin/bash 38400 tty2 &- isso ajuda a examinar o status em que o sistema está (por exemplo ps -Af, , iotop)
• usar initctl listpara descobrir quais serviços estão em qual estado