Debian Jessie pendurado na inicialização

3

Depois de instalar o kernel 4.6, nós inicializamos um servidor de desenvolvimento com o Debian 8.5 Jessie. Ele não passa da mensagem de erro "Configurando grupos de volumes LVM".

A VM tem o Debian 8, com repositório de backports, inicializando com sysV em vez de systemd e usando LVM.

Eu posso inicializá-lo com uma imagem ao vivo knoppix e fazer com que as 6 partições LVM no grupo de volume apareçam com:

vgchange -ay 

Eu também sou capaz de montar as partições LVM e editá-las, para que não pareça nenhum tipo de problema LVM.

Eu também aproveitei isso para montar todas as partições em sua ordem natural, incluindo mount binding proc, sys e dev e, assim, executar um chroot para executar mais naturalmente outros comandos de depuração / correção na linha.

Já tentei alterar o algoritmo de inicialização para CONCURRENCY=none / legacy sem muito sucesso.

Também regenerou o arquivo initrd , fez com que o servidor tivesse espaço em disco preenchido durante a atualização do kernel, com o comando:

sudo dpkg-reconfigure linux-image-4.6.0-0.bpo.1-amd64 

Também não fez diferença alguma.

Eu também reinstalei o grub, usando:

sudo update-grub
sudo grub-install /dev/sda

Isso também não ajudou.

Também adicionei opções de depuração às opções do kernel em grub , no entanto, o sistema, na inicialização, não imprime erros relevantes nem imprime qualquer mensagem adicional após o erro.

Também não há logs nem dmesg logs para inspecionar, já que, na inicialização, o syslog ainda não está funcionando.

    
por Rui F Ribeiro 23.08.2016 / 23:16

1 resposta

2

Acabei de localizar o script incorreto como /etc/rcS.d/S05lvm2 e o comando que interrompeu a VM nesse script como /sbin/lvm vgchange -aay --sysinit >/dev/null

Como pode ser visto no arquivo de origem, as dependências de S05lvm2 são:

# Should-Start:      udev mdadm-raid cryptdisks-early multipath-tools-boot

Por fim, ocorreu-me que alguém ou algo desativou a inicialização do udev daemon (pouco tempo atrás, após a última inicialização bem-sucedida). Eu também determinei que não eram as rotinas de pós-instalação do kernel desabilitando udev .

O script de inicialização, tendo a dependência do udev service não satisfeita, parou na espera por uma dependência que nunca foi satisfeita, ou por um dispositivo que nunca apareceu (ou ambos).

O problema foi corrigido em execução no chroot mencionado anteriormente:

sudo chkconfig udev on

(instalamos chkconfig ). No caminho do Debian, seria:

sudo update-rc.d udev defaults

Próximo para refazer o arquivo initrd:

sudo dpkg-reconfigure linux-image-4.6.0-0.bpo.1-amd64
    
por 23.08.2016 / 23:16