Ubuntu não inicializa por causa do lvmetad

Question 1

Eu vi o mesmo erro hoje em um laptop rodando Ubuntu 15.10 que sempre mantive atualizado, mas não reiniciei por um mês até querer testar um kernel atual (ou seja, pode ter havido uma mudança recente).

De qualquer forma, descobri que no meu caso a causa subjacente era na verdade uma partição swap "ausente" devido a uma falha de configuração ao seguir o tutorial acima. Se for esse o caso e/ou você estiver realmente usando lvm, poderá pular a etapa 2 abaixo. Claro, você também poderá ver a mensagem de erro acima caso a partição do seu sistema (ou dados secundários) tenha sido danificada ou não possa ser encontrada (consulte a etapa 3).

Passo 1: Monte seu sistema, inicialize as partições seguindo o tutorial mencionado

Digamos que sua partição de inicialização (ext2) seja /dev/sdX1, sua partição swap (criptografada) seja /dev/sdX2, sua partição de dados (criptografada) seja /dev/sdX3 e você descriptografou a última com sucesso usando cryptsetup luksOpen /dev/sdX3 data, seguido pela montagem isto: mkdir /tmp/data; mount /dev/mapper/data /tmp/data.

Preste atenção às montagens de ligação no tutorial e certifique-se de montar /dev/sdX1 para que você possa acessá-lo a partir do diretório /boot da partição do sistema (isso é crucial, pois temos que executar update-initramfs).

A seguir, presumimos que você executou com sucesso chroot /tmp/data/@ubuntu1510(ou qualquer que seja o nome da partição do sistema montada)

Etapa 2: livre-se da mensagem de erro acima

Estou usando o btrfs (como você deve ter adivinhado pelo nome do subvolume mencionado), então o lvmetad pode ser facilmente desativado da seguinte maneira, sem perda de funcionalidade:

edite /etc/lvm/lvm.conf e mude use_lvmetad=1parause_lvmetad=0
executarupdate-initramfs -k $(uname -r) -u ; sync

Agora vocêpoderiareinicie e a mensagem de erro deverá desaparecer.No entanto,no meu caso, a próxima mensagem de erro[1] me apontou para o problema subjacente mencionado acima, então, já que estamos nisso, ...

Etapa 3: certifique-se de que /etc/crypttab aponte para as partições corretas e não danificadas

Primeiro, execute sfdisk --list /dev/sdXe verifique se sua partição swap criptografada (no meu caso, /dev/sdX2) realmente funcionanãoaparece como uma partição swap (normal). Se isso acontecesse (como no meu caso), isso significava que a inicialização, por exemplo, usando um disco de recuperação provavelmente usaria aquela partição swap disponível, sobrescrevendo assim os metadados relacionados ao cryptsetup (frase-chave e UUID).

A seguir, dê uma olhada em /dev/disk/by-uuid e compare os respectivos UUIDs de suas partições criptografadas com aqueles contidos em /etc/crypttab. Meu palpite neste momento: no seu caso, há uma incompatibilidade.

Se a partição swap criptografada dedicada não for encontrada abaixo de /dev/disk/by-uuid, é porque ela está atualmente em uso pelo seu sistema de recuperação. Nesse caso, faça o seguinte:

certifique-se de parar de usar a partição:swapoff -a
reformate-o: mkfs.ext2 /dev/sdX2(isto écrucial, especialmente ao usar partições GPT[2], pois desfaz a falha que mencionei anteriormente. A causa provável da partição aparecer como tipo "swap" na listagem do sfdisk é que você/eu usei por engano mkswap /dev/sdX2ao configurar a partição no início.)
siga o tutorial para criptografar a partição e definir uma senha; depois, abra-o usando cryptsetup e reformate adequadamente oagora descriptografadopartição (usando algo como mkswap /dev/mapper/swap)
certifique-se de que sfdisk --list /dev/sdXnão identificará a partição swap como tal (nesse caso, repita os últimos passos)

Agora, verifique novamente se os UUIDs listados em /etc/crypttab estão alinhados com o que você vê abaixo de /dev/disk/by-uuid para suas respectivas partições criptografadas.

Novamente, para tornar as alterações permanentes, você deve executar update-initramfsconforme mostrado acima.

Se estiver satisfeito, certifique-se de que tudo esteja gravado no disco e reinicie o sistema (não há necessidade de desmontar tudo manualmente). Depois, seu problema deverá desaparecer.

[1] talvez eu não tenha prestado atenção na primeira vez ou a primeira mensagem de erro “mascarou” a segunda; ou seja, somente após a reinicialização (com use_lvmetad=0), me foi apresentado "Lendo todos os volumes físicos. Isso pode demorar um pouco..."(repetido várias vezes), seguido por"ALERTA! /dev/disk/by-uuid/... não existe.". (Deve-se notar que update-initramfstambém reclamou da falta de uma partição.)

[2] porque seu tipo é deduzido da análise de seu conteúdo e não especificado por um sinalizador/byte (é por isso que não há uma maneira fácil de, por exemplo, alterar o tipo de sistema de arquivos GPT usando [g]parted.)

Answer

Eu vi o mesmo erro hoje em um laptop rodando Ubuntu 15.10 que sempre mantive atualizado, mas não reiniciei por um mês até querer testar um kernel atual (ou seja, pode ter havido uma mudança recente).

De qualquer forma, descobri que no meu caso a causa subjacente era na verdade uma partição swap "ausente" devido a uma falha de configuração ao seguir o tutorial acima. Se for esse o caso e/ou você estiver realmente usando lvm, poderá pular a etapa 2 abaixo. Claro, você também poderá ver a mensagem de erro acima caso a partição do seu sistema (ou dados secundários) tenha sido danificada ou não possa ser encontrada (consulte a etapa 3).

Passo 1: Monte seu sistema, inicialize as partições seguindo o tutorial mencionado

Digamos que sua partição de inicialização (ext2) seja /dev/sdX1, sua partição swap (criptografada) seja /dev/sdX2, sua partição de dados (criptografada) seja /dev/sdX3 e você descriptografou a última com sucesso usando cryptsetup luksOpen /dev/sdX3 data, seguido pela montagem isto: mkdir /tmp/data; mount /dev/mapper/data /tmp/data.

Preste atenção às montagens de ligação no tutorial e certifique-se de montar /dev/sdX1 para que você possa acessá-lo a partir do diretório /boot da partição do sistema (isso é crucial, pois temos que executar update-initramfs).

A seguir, presumimos que você executou com sucesso chroot /tmp/data/@ubuntu1510(ou qualquer que seja o nome da partição do sistema montada)

Etapa 2: livre-se da mensagem de erro acima

Estou usando o btrfs (como você deve ter adivinhado pelo nome do subvolume mencionado), então o lvmetad pode ser facilmente desativado da seguinte maneira, sem perda de funcionalidade:

edite /etc/lvm/lvm.conf e mude use_lvmetad=1parause_lvmetad=0
executarupdate-initramfs -k $(uname -r) -u ; sync

Agora vocêpoderiareinicie e a mensagem de erro deverá desaparecer.No entanto,no meu caso, a próxima mensagem de erro[1] me apontou para o problema subjacente mencionado acima, então, já que estamos nisso, ...

Etapa 3: certifique-se de que /etc/crypttab aponte para as partições corretas e não danificadas

Primeiro, execute sfdisk --list /dev/sdXe verifique se sua partição swap criptografada (no meu caso, /dev/sdX2) realmente funcionanãoaparece como uma partição swap (normal). Se isso acontecesse (como no meu caso), isso significava que a inicialização, por exemplo, usando um disco de recuperação provavelmente usaria aquela partição swap disponível, sobrescrevendo assim os metadados relacionados ao cryptsetup (frase-chave e UUID).

A seguir, dê uma olhada em /dev/disk/by-uuid e compare os respectivos UUIDs de suas partições criptografadas com aqueles contidos em /etc/crypttab. Meu palpite neste momento: no seu caso, há uma incompatibilidade.

Se a partição swap criptografada dedicada não for encontrada abaixo de /dev/disk/by-uuid, é porque ela está atualmente em uso pelo seu sistema de recuperação. Nesse caso, faça o seguinte:

certifique-se de parar de usar a partição:swapoff -a
reformate-o: mkfs.ext2 /dev/sdX2(isto écrucial, especialmente ao usar partições GPT[2], pois desfaz a falha que mencionei anteriormente. A causa provável da partição aparecer como tipo "swap" na listagem do sfdisk é que você/eu usei por engano mkswap /dev/sdX2ao configurar a partição no início.)
siga o tutorial para criptografar a partição e definir uma senha; depois, abra-o usando cryptsetup e reformate adequadamente oagora descriptografadopartição (usando algo como mkswap /dev/mapper/swap)
certifique-se de que sfdisk --list /dev/sdXnão identificará a partição swap como tal (nesse caso, repita os últimos passos)

Agora, verifique novamente se os UUIDs listados em /etc/crypttab estão alinhados com o que você vê abaixo de /dev/disk/by-uuid para suas respectivas partições criptografadas.

Novamente, para tornar as alterações permanentes, você deve executar update-initramfsconforme mostrado acima.

Se estiver satisfeito, certifique-se de que tudo esteja gravado no disco e reinicie o sistema (não há necessidade de desmontar tudo manualmente). Depois, seu problema deverá desaparecer.

[1] talvez eu não tenha prestado atenção na primeira vez ou a primeira mensagem de erro “mascarou” a segunda; ou seja, somente após a reinicialização (com use_lvmetad=0), me foi apresentado "Lendo todos os volumes físicos. Isso pode demorar um pouco..."(repetido várias vezes), seguido por"ALERTA! /dev/disk/by-uuid/... não existe.". (Deve-se notar que update-initramfstambém reclamou da falta de uma partição.)

[2] porque seu tipo é deduzido da análise de seu conteúdo e não especificado por um sinalizador/byte (é por isso que não há uma maneira fácil de, por exemplo, alterar o tipo de sistema de arquivos GPT usando [g]parted.)

Question 2

O Failed to connect to lvmetaderropodeacontecer porque o disco está 100% cheio. Para corrigir isso, inicialize a partir de um pen drive USB, monte o disco completo, exclua alguns arquivos desnecessários e reinicie. Também reinstalei o sistema de boot - não sei se é necessário ou não.

Estes são os comandos que resolveram o problema para mim, executados a partir de um terminal após inicializar a partir da unidade USB. Eu tenho o Ubuntu 18.04 em estoque com criptografia de unidade completa. YMMV.

Monte a unidade:

sudo cryptsetup luksOpen /dev/sda5 sda5_crypt
sudo vgscan --mknodes
sudo vgchange -ay
sudo mount /dev/mapper/ubuntu--vg-root /mnt

Exclua arquivos desnecessários ( cd /mnt/home/your_username... rm ...)

(pode não ser necessário) reinstale o sistema de inicialização:

cd /mnt/
sudo mount /dev/sda1 boot
for d in dev sys proc run; do sudo mount --bind /$d $d; done
sudo vi etc/crypttab # make sure first line uses "sda5_crypt"
sudo chroot .
update-grub
grub-install /dev/sda
update-initramfs -u -k all
exit
sudo umount dev sys proc run boot

Desmontar:

cd /
sudo umount /mnt
sudo vgchange -an
sudo cryptsetup close sda5_crypt

Reinício:
```
sudo reboot
```

Answer

O Failed to connect to lvmetaderropodeacontecer porque o disco está 100% cheio. Para corrigir isso, inicialize a partir de um pen drive USB, monte o disco completo, exclua alguns arquivos desnecessários e reinicie. Também reinstalei o sistema de boot - não sei se é necessário ou não.

Estes são os comandos que resolveram o problema para mim, executados a partir de um terminal após inicializar a partir da unidade USB. Eu tenho o Ubuntu 18.04 em estoque com criptografia de unidade completa. YMMV.

Monte a unidade:

sudo cryptsetup luksOpen /dev/sda5 sda5_crypt
sudo vgscan --mknodes
sudo vgchange -ay
sudo mount /dev/mapper/ubuntu--vg-root /mnt

Exclua arquivos desnecessários ( cd /mnt/home/your_username... rm ...)

(pode não ser necessário) reinstale o sistema de inicialização:

cd /mnt/
sudo mount /dev/sda1 boot
for d in dev sys proc run; do sudo mount --bind /$d $d; done
sudo vi etc/crypttab # make sure first line uses "sda5_crypt"
sudo chroot .
update-grub
grub-install /dev/sda
update-initramfs -u -k all
exit
sudo umount dev sys proc run boot

Desmontar:

cd /
sudo umount /mnt
sudo vgchange -an
sudo cryptsetup close sda5_crypt

Reinício:
```
sudo reboot
```

Question 3

Ubuntu 18.04.1 LTS aqui. Ele funcionou por alguns meses sem supervisão, mas quando voltei encontrei o teclado não reconhecido. Quando reiniciei, recebi a mensagem 'não é possível conectar-se ao lvmetad' e mais sobre não conseguir obter a "lista UEFI db".

Eu tinha instalado sem criptografia de disco.

A mensagem UEFI foi preocupante porque esta foi minha primeira instalação em um computador UEFI, então eu não tinha experiência e, francamente, ainda estou desinformado sobre a utilidade. Meu problema foi agravado pelo fato de eu ter usado 'lvm' no que seria meu '/', root, volume. (Na verdade, já esqueci como consegui ISSO! Ei. Estou velho.)

No entanto, quando a máquina não reinicializou, procurei uma solução e não encontrei nada definitivo, mas percebi que a) minha partição EFI era menor que os 500 MB recomendados em um site e b) a partição /boot/ separada que eu havia organizado pois provavelmente era irrelevante e não utilizado. Achei possível que uma atualização autônoma, talvez, tivesse feito com que algo, possivelmente, ocupasse o espaço alocado.

Decidi reinstalar - o que funcionou e deixei minha estrutura de diretórios /home/ intacta. Não verifiquei /etc/, mas fiz cópias de ambos antes[1], para poder verificar mais tarde. /etc/ é muito pequeno.

Também excluí e combinei as partições para EFI e /boot/ em uma única partição EFI maior (> 750 MB).

Ele reinicia agora, mas uma única mensagem de erro pisca rápido demais para ser lida, e não me é oferecido um 'menu' de inicialização de imagens do Linux para inicializar; em vez disso, ele inicializa diretamente no Ubuntu. Ainda há mais trabalho a fazer, suponho que com o grub, para resolver isso. Mas pelo menos meus arquivos estão de volta.

[1] Inicializei a instalação do Ubuntu a partir de um pendrive e optei por "experimentar" o Ubuntu, o que me permitiu fazer cópias do etc e do home, antes de escolher "Instalar" na área de trabalho.

Answer

Ubuntu 18.04.1 LTS aqui. Ele funcionou por alguns meses sem supervisão, mas quando voltei encontrei o teclado não reconhecido. Quando reiniciei, recebi a mensagem 'não é possível conectar-se ao lvmetad' e mais sobre não conseguir obter a "lista UEFI db".

Eu tinha instalado sem criptografia de disco.

A mensagem UEFI foi preocupante porque esta foi minha primeira instalação em um computador UEFI, então eu não tinha experiência e, francamente, ainda estou desinformado sobre a utilidade. Meu problema foi agravado pelo fato de eu ter usado 'lvm' no que seria meu '/', root, volume. (Na verdade, já esqueci como consegui ISSO! Ei. Estou velho.)

No entanto, quando a máquina não reinicializou, procurei uma solução e não encontrei nada definitivo, mas percebi que a) minha partição EFI era menor que os 500 MB recomendados em um site e b) a partição /boot/ separada que eu havia organizado pois provavelmente era irrelevante e não utilizado. Achei possível que uma atualização autônoma, talvez, tivesse feito com que algo, possivelmente, ocupasse o espaço alocado.

Decidi reinstalar - o que funcionou e deixei minha estrutura de diretórios /home/ intacta. Não verifiquei /etc/, mas fiz cópias de ambos antes[1], para poder verificar mais tarde. /etc/ é muito pequeno.

Também excluí e combinei as partições para EFI e /boot/ em uma única partição EFI maior (> 750 MB).

Ele reinicia agora, mas uma única mensagem de erro pisca rápido demais para ser lida, e não me é oferecido um 'menu' de inicialização de imagens do Linux para inicializar; em vez disso, ele inicializa diretamente no Ubuntu. Ainda há mais trabalho a fazer, suponho que com o grub, para resolver isso. Mas pelo menos meus arquivos estão de volta.

[1] Inicializei a instalação do Ubuntu a partir de um pendrive e optei por "experimentar" o Ubuntu, o que me permitiu fazer cópias do etc e do home, antes de escolher "Instalar" na área de trabalho.

Question 4

Não é necessário inicializar seu sistema a partir de um USB ou qualquer outra coisa. Tive o mesmo problema e um motivo - porque o disco está 100% cheio. A próxima solução me ajudou.

Reinicie seu sistema. Com o BIOS, pressione e segure rapidamente a tecla Shift, que abrirá o menu GNU GRUB.
Depois pressione 'e' para editar as configurações do Ubuntu. Emeste problemavocê pode encontrar telas. Encontre uma string começando como 'linux *', assim:
```
linux     /boot/vmlinuz-4-4.0-22-generic root=UUID=43ad24d3-e\
c5b-44ee-a099-a88eb9520989 ro  quiet splash $vt_handoff
```
Excluir:
```
ro  quiet splash $vt_handoff
```
E adicione:
```
init=/bin/bash
```
Quando estiver pronto, pressione Ctrl+xou F10para inicializar.
A partição raiz é montada somente leitura. Para montá-lo para leitura/gravação, digite o comando
```
mount -o remount,rw /
```
Descubra o que deu errado:
```
df -hT
```

Answer

Não é necessário inicializar seu sistema a partir de um USB ou qualquer outra coisa. Tive o mesmo problema e um motivo - porque o disco está 100% cheio. A próxima solução me ajudou.

Reinicie seu sistema. Com o BIOS, pressione e segure rapidamente a tecla Shift, que abrirá o menu GNU GRUB.
Depois pressione 'e' para editar as configurações do Ubuntu. Emeste problemavocê pode encontrar telas. Encontre uma string começando como 'linux *', assim:
```
linux     /boot/vmlinuz-4-4.0-22-generic root=UUID=43ad24d3-e\
c5b-44ee-a099-a88eb9520989 ro  quiet splash $vt_handoff
```
Excluir:
```
ro  quiet splash $vt_handoff
```
E adicione:
```
init=/bin/bash
```
Quando estiver pronto, pressione Ctrl+xou F10para inicializar.
A partição raiz é montada somente leitura. Para montá-lo para leitura/gravação, digite o comando
```
mount -o remount,rw /
```
Descubra o que deu errado:
```
df -hT
```

Ubuntu não inicializa por causa do lvmetad

Responder1

Responder2

Responder3

Responder4

informação relacionada