“Lvmetad ainda não está ativo, usando a ativação direta durante o sysinit” no boot?

2

Algum tempo atrás eu instalei o Ubuntu 16.04 no meu PC. Tudo correu bem e sem problemas até agora. Quando a primeira atualização do kernel saiu eu não pude iniciá-lo e recebi o seguinte erro:

Lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
Cannot process volume group ubuntu-vg

Quando eu escolho o kernel antigo do menu do GRUB, tudo deu certo e sem problemas. Depois disso, outra atualização do kernel foi lançada e também aquela não funcionou. Basicamente, após clicar na versão mais recente do kernel, recebi o erro e repeti repetidamente na tela (sem fim, não testado pelo menos).

Eu tentei o seguinte sem sorte:

Nem funcionou. Eu tenho meu disco criptografado como era uma opção durante a instalação e eu pensei porque não? Eu acho que algo está acontecendo com isso, embora seja mais como um pressentimento do que uma evidência concreta. Eu procurei se é possível desativar a criptografia e foi um trabalho muito tedioso, então eu meio que parei de procurar por isso, mas se essa parece ser a solução, eu ainda posso tentar.

Portanto, a versão do kernel instalada era 4.4.0-21-generic (conforme exibido no GRUB). Funciona bem sem problemas. Depois disso, os kernels instalados eram 4.4.0-22-generic , 4.4.0-24-generic e 4.4.0-28-generic (como visto no GRUB). Que todos os três não funcionam e dão exatamente o mesmo erro anterior.

Por que estou recebendo o erro e como resolvo isso?

    
por user3892683 10.07.2016 / 22:11

2 respostas

2

Eu tive as mesmas mensagens de erro depois que eu fiz uma atualização do Ubuntu 14.04 LTS para o 16.04 LTS em um chroot (chroot como descrito em este artigo alemão ) de um sistema ativo.

O erro ocorreu antes do prompt da senha. Como o grupo de volumes LVM está normalmente dentro do volume criptografado, ele deve ser um problema de configuração do dm_crypt / LUKS.

Eu encontrei uma solução aqui e explicarei abaixo.

No meu caso, o nome do mapeador do volume criptografado era diferente do nome dado em / etc / crypttab.

Eu escolhi o nome do mapeador luks da saída de ls -l /dev/mapper , depois de abrir o dispositivo criptografado com o gerenciador de arquivos gráficos . No meu caso, a saída foi:

control
luks-87fc4c8e-017b-8482-cd09-7332fe351628
vgubuntu-root
vgubuntu-swap

Então, como root, mudei meu / etc / crypttab (observe o início da linha) de:

sda5_crypt UUID=87fc4c8e-017b-8482-cd09-7332fe351628 none luks,discard

para:

luks-87fc4c8e-017b-8482-cd09-7332fe351628 UUID=87fc4c8e-017b-8482-cd09-7332fe351628 none luks,discard

Por fim, atualizei meu initramfs:

update-initramfs -u -k all

Foi um pouco confuso que esses dois nomes fossem diferentes. Pode-se supor que quando o mapeador é criado, seu nome é retirado da criptografia. De qualquer forma, funcionou.

Eu fiz o material todo em um chroot, executando um sistema ao vivo. Também pode funcionar a partir do shell busybox em que você solta após a inicialização do seu sistema, mas eu não tentei.

    
por casi 08.03.2017 / 18:44
-1

Nova resposta:
Percebi que apenas editar esse arquivo não funcionaria pelo menos para mim, por algum motivo as alterações foram revertidas.

Você pode fazer isso se quiser: inicializar o Ubuntu no seu kernel antigo (via menu de seleção de inicialização do grub) e fazer o download Grub Customiser , vá para a aba" Configurações gerais "e selecione a inicialização mais antiga do kernel" predefinida: "em" entrada padrão ". Salve isso. Desta forma, você sempre escolherá o kernel mais antigo por padrão.

Resposta errada original:
Por que não apenas usar o kernel antigo? Eu também tenho o mesmo problema que você e graças à sua descoberta sobre o uso do kernel antigo, eu mudo o kernel da primeira entrada do menu /boot/grub/grub.cfg de 4.4.0-28-generic para 4.4.0-21-generic e meu computador finalmente consegue inicializar completamente.

    
por user1602020 11.07.2016 / 10:08