Nova instalação do Ubuntu 16.04 trava na reinicialização (i386 Server no laptop Acer Travelmate)

Question

Eu usei um antigo laptop Acer Travelmate 4000 como meu servidor local para idades com o Ubuntu Desktop.

Este ano, eu instalei o 16.04 i386 Server Edition e não poderia estar mais feliz. Todo o conjunto de trabalho do Linux, da pilha de rede e do apache2 usa apenas 37MB dos 2GB de bordo ... No Swap For You!

O problema é que a emissão de um comando de reinicialização (ou desligamento) sempre trava no mesmo ponto no console: "Alvo de desligamento atingido", exigindo um desligamento e reinicialização.

O que posso fazer para diagnosticar isso ainda mais?

UPDATE : Por sugestão, digitei comandos no console sob o sudo para 'systemctl start debug-shell' seguido por 'reboot'.

No entanto, esse servidor baunilha não possui um gerenciador de janelas, portanto, quando a mensagem final do console 'Alvo atingido Encerrar' aparecer, nenhuma combinação de teclas poderá gerar um VT e listar quaisquer tarefas que falharam. O encanto do Alt + SysRq também é ineficaz para continuar a reinicialização.

De qualquer forma, agora há uma nova linha de mensagem de último suspiro que diz: "[278.430967] systemd-shutdown: Falha ao finalizar dispositivos DM. ignorando"

Eu tentei a solução alternativa para desativar o espaço de troca durante o desligamento em um relatório de erros semelhante mas não ajudou; provavelmente porque meu swapfile de 3GB não é usado e / tmp é mínimo (~ 2%).

Há mais alguma coisa que eu possa tentar mover os marcadores para a frente aqui?

UPDATE 2: Capturar a saída dos comandos sugeridos journalctl e systemctl em um arquivo não resultou em nada fora do comum.

Como não há GUI neste servidor, usei este código do github para ativar o Xenial Proposed antes de atualizar / atualizar / reinicializar para garantir que o novo systemd-229 estivesse no mix.

Infelizmente, não fez diferença. Eu não sei se está relacionado, mas eu tomei a opção no momento da instalação do Ubuntu para usar grupos de volume padrão do LVM para / boot, / home, / var, / tmp e swap.

Eu sou realmente o único a ver este problema?

(Aqui está uma captura de tela do console após a reinicialização, além de esperar outros 3 minutos ou mais):

    

Answer 1

Eu atualizei para o Ubuntu 16.10 assim que ele estava disponível, mas isso não resolveu esse problema. Nem as atualizações subsequentes de pacotes foram aplicadas desde então.

No entanto, os upgrades de pacotes de hoje devem ter incluído uma correção, já que agora posso fazer um 'sudo reboot' regular de uma sessão SSH remota e reconectar-me ao servidor em um ou dois minutos.

Aqui está a entrada mais recente do meu /var/log/apt/history.log:

Atualização: libsystemd0: i386 (231-9git1, 231-9ubuntu1), udev: i386 (231-9git1, 231-9ubuntu1), libudev1: i386 (231-9git1, 231-9ubuntu1), python3-distupgrade: i386 ( 1: 16.10.7, 1: 16.10.8), ubuntu-release-upgrader-core: i386 (1: 16.10.7, 1: 16.10.8), systemd-sysv: i386 (231-9git1, 231-9ubuntu1) , libpam-systemd: i386 (231-9git1, 231-9ubuntu1), systemd: i386 (231-9git1, 231-9ubuntu1), libnss-resolve: i386 (231-9git1, 231-9ubuntu1)

Entre essa lista, um enorme "obrigado!" vai para qualquer mantenedor de pacotes que tenha aplicado o encantamento mágico necessário ... você sabe quem você é:)

UPDATE Como o Ubuntu não suporta mais as máquinas i386, mudei felizmente para o Lubuntu 18.04. Bom gosto, menos recheio!

    

Answer 2

Quem sabe quando / se este problema: "systemd-shutdown: Falha ao finalizar dispositivos DM. ignorando." será corrigido nesta plataforma antiga - nada que eu tenha lido sugeriria que será em breve.

Nesse meio tempo, essa solução permite que eu reinicie meu servidor sem desligar a máquina fisicamente.

Todos os comandos a seguir estão sob sudo:

• Coloque esses comandos em um arquivo como ~ / sysrq-reboot.sh em echo 1 > /proc/sys/kernel/sysrq sync && echo b > /proc/sysrq-trigger
• chmod + x o arquivo para torná-lo executável
• então, para reinicializar, basta executar o script com sudo ~ / sysrq-reboot.sh

Se executar o script remotamente via ssh, eu também preciso fechar minha janela ssh e restabelecer uma nova sessão ssh (depois de esperar um minuto para a máquina ficar acessível).