A inicialização do Ubuntu 14.04 trava no logo após a atualização

Question

Ontem, eu fiz um update / dist-upgrade . Hoje, liguei a máquina e ela estava pendurada na tela de carregamento com o logotipo e os pontos de ciclagem - esperei nesta tela por cerca de uma hora várias vezes sem resultados. Se eu interromper o upstart com ctrl-alt-del, a inicialização será concluída / concluída, mas isso me colocará no tty console login. X inicia, alguns segundos depois, mas uma caixa de diálogo sobre gráficos configurados incorretamente é imediatamente ativada. Atualizar : o problema do X foi resolvido com apt-get install nvidia-current . Problema de interrupção ainda permanece.

Infelizmente, todas as pistas que encontrei sobre o porquê de isso estar se transformando em um beco sem saída. Aqui está meu boot.log (de /var/log ) mostrando onde interrompi a inicialização. Você pode ver que ele trava assim que ele inicia "habilitar dispositivos de bloqueio criptografados de tempo de inicialização restantes" (isso é de cryptdisks ), mas a remoção desse serviço não faz diferença. Experimentei praticamente tudo, desde este relato de bug de hortelã , que descreve sintomas quase idênticos aos meus, sem sucesso. Neste ponto, tenho quase certeza que cryptdisks é um arenque vermelho, e isso é algo totalmente diferente.

Eu também descobri que retomar a inicialização do modo de recuperação parece carregar as coisas em uma ordem diferente. Upstart ainda trava, mas não depois de cryptdisks . Se eu ctrl-alt-del, ele me leva para o gerenciador de login gráfico em vez de um tty, e eu consigo logar com sucesso. No entanto, o sistema ainda não está totalmente funcional; O plug and play USB parece não funcionar, não posso usar meu segundo monitor e tenho que fazer manualmente start resolvconf para acessar a Internet. Aqui está o boot.log de uma dessas startups.

Devo acrescentar que estou criptografando meu disco rígido com LUKS e o problema ocorre depois que eu digito com êxito a senha de descriptografia. Aqui está o meu fstab , caso tenha alguma coisa a ver com as coisas:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/ubuntu--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=9e7c1e90-f3e4-4075-b3b0-e3ccb6d933c7 /boot           ext2    defaults        0       2
/dev/mapper/ubuntu--vg-swap_1 none            swap    sw              0       0

O que está acontecendo aqui?

    

Answer 1

A causa raiz foi um grande número de arquivos no meu diretório /tmp .

Eu usei o diretório /tmp para armazenar milhões de arquivos anteriormente. Acontece que ter muitos arquivos lá faz com que o serviço que limpa /tmp demore muito, muito tempo (duh). Depois de mover os arquivos para fora de /tmp , o problema está resolvido. Não tinha nada a ver com a atualização; isso foi apenas uma coincidência.

Caso isso ajude alguém mais tarde, aqui está o processo que eu usei para descobrir isso. Ativei a "chave do Magic SysRq" alterando etc/sysctl.d/10-magic-sysrq.conf . Então, reproduzi o problema reiniciando; quando a inicialização parou, apertei Alt - SysRq - t . Isso despejou o seguinte no buffer do kernel, leia usando dmesg :

[   36.318527] SysRq : Show Blocked State
[   36.318696]   task                        PC stack   pid father
[   36.318719] find            D ffff88041dd93480     0   839    788 0x00000000
[   36.318721]  ffff880405d07a48 0000000000000082 ffff880401136000 ffff880405d07fd8
[   36.318723]  0000000000013480 0000000000013480 ffff880401136000 ffff88041dd93d18
[   36.318725]  ffff88041dfab460 0000000000000002 ffffffff811ef380 ffff880405d07ac0

Ele despeja muito mais do que isso, mas esta é a parte relevante. Isso mostra que a tarefa bloqueada é find . Depois disso, era apenas uma questão de um amigo experiente saber que o serviço de limpeza /tmp era provavelmente o culpado.

    

Answer 2

Obrigado, Chaosed0, por voltar com sua solução (ou seja, um grande número de arquivos em / tmp). [Tentei postar isso como um comentário, mas não tenho pontos de reputação suficientes]

Eu encontrei o mesmo problema com o servidor Ubuntu (14.04) e foi muito difícil diagnosticar até encontrar o seu post.

Quando reinicializei a máquina, ela parece ficar bloqueada logo antes de exibir normalmente o console de login. Ele poderia ser desbloqueado pressionando Ctrl + Alt + Del , o que faria com que uma mensagem de log fosse impressa e que wait-for-state (rcplymouth-shutdown) tivesse sido terminada. Aquela mensagem de log me mandou para o caminho errado de cutucar vários scripts plymouth e então tentar desabilitar completamente o plymouth: - (

Na verdade, o processo de inicialização não estava travado, estava aguardando a limpeza de /tmp ser concluída. Aquela máquina tinha dezenas de milhares de arquivos em /tmp , então demorava muito tempo para fazer a limpeza.

Então, a solução para mim foi inicializar na recuperação, obter um shell de root e, em seguida, rm -rf /tmp/* . Após cerca de uma hora, o trabalho rm foi concluído. Então eu reiniciei e tudo funcionou normalmente.

Seria ótimo se uma mensagem de log pudesse ser impressa quando a limpeza de /tmp fosse iniciada.