Eu vi o mesmo erro hoje em um laptop rodando o Ubuntu 15.10 que eu sempre mantive atualizado mas não reiniciei por um mês até que eu quisesse testar um kernel atual (ou seja, pode ter havido um recente mudança).
De qualquer forma, descobri que no meu caso a causa subjacente era na verdade uma partição de swap "perdida" devido a uma falha de configuração ao seguir o tutorial acima. Se esse for o caso e / ou você realmente estiver usando lvm , talvez seja possível pular a etapa 2 abaixo.
É claro, você também pode ver a mensagem de erro acima caso sua partição do sistema (ou dados secundários) tenha sido danificada ou não possa ser encontrada (veja a etapa 3).
Etapa 1: monte seu sistema, inicialize as partições seguindo o tutorial mencionado
Digamos que sua partição de boot (ext2) seja / dev / sdX1, sua partição de swap (criptografada) seja / dev / sdX2, sua partição de dados (criptografada) seja / dev / sdX3 e você tenha descriptografado com êxito usando cryptsetup luksOpen /dev/sdX3 data , seguido de montagem: mkdir /tmp/data; mount /dev/mapper/data /tmp/data .
Preste atenção às montagens de bind no tutorial e certifique-se de montar / dev / sdX1 para que possa acessá-lo a partir do diretório / boot de sua partição de sistema (isto é crucial, pois temos que executar update-initramfs ).
A seguir, estamos assumindo que você executou com sucesso o chroot /tmp/data/@ubuntu1510 (ou qualquer que seja a sua partição de sistema montada é chamada)
Etapa 2: Livre-se da mensagem de erro acima
Estou usando o btrfs (como você deve ter adivinhado a partir do nome do subvolume mencionado), então o lvmetad pode ser facilmente desativado da seguinte forma, sem perda de funcionalidade:
- edite /etc/lvm/lvm.conf e altere
use_lvmetad=1parause_lvmetad=0 - execute
update-initramfs -k *KERNEL_VERSION* -u ; sync
Agora, você pode reinicializar e a mensagem de erro deve ter desaparecido. No entanto, no meu caso, a próxima mensagem de erro [1] me apontou para o problema subjacente mencionado acima, então enquanto estamos nisso, ...
Etapa 3: verifique se o / etc / crypttab aponta para as partições corretas e não danificadas
Primeiro, execute sfdisk --list /dev/sdX e verifique se a partição de swap criptografada (no meu caso, / dev / sdX2) realmente não não aparece como uma partição de troca (normal). Se isso acontecesse (como no meu caso), isso significa que a inicialização, por exemplo, usando um disco de recuperação, provavelmente fará uso da partição swap disponível, sobrescrevendo os metadados relacionados à criptografia (keyphrase e UUID).
Em seguida, dê uma olhada em / dev / disk / by-uuid e compare os respectivos UUIDs de suas partições criptografadas com as contidas em / etc / crypttab. Meu palpite neste momento: no seu caso, há uma incompatibilidade.
Se a partição de troca criptografada dedicada não estiver em nenhum lugar abaixo de / dev / disk / by-uuid, isso é porque ela está atualmente em uso pelo seu sistema de recuperação. Nesse caso, faça o seguinte:
- não deixe de usar a partição:
swapoff -a - reformatá-lo:
mkfs.ext2 /dev/sdX2(isso é 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 sfdisk é que você / eu usou por enganomkswap /dev/sdX2ao configurar a partição no começo.) - siga o tutorial para criptografar a partição e definir uma frase secreta; depois, abra-o usando o cryptsetup e reformate corretamente a partição agora descriptografada (usando algo como
mkswap /dev/mapper/swap) - certifique-se de que
sfdisk --list /dev/sdXnão identifique a partição de troca como tal (nesse caso, repita as últimas etapas)
Agora, verifique novamente se os UUIDs listados em / etc / crypttab estão alinhados, o que você verá abaixo em / dev / disk / by-uuid para suas respectivas partições criptografadas.
Mais uma vez, para tornar as alterações permanentes, você deve executar update-initramfs conforme mostrado acima.
Se estiver satisfeito, verifique se tudo está gravado no disco e reinicialize o sistema (não é preciso desmontar tudo manualmente). Depois, seu problema deve ter desaparecido.
[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 ), fui presenteado com " Lendo todos os volumes físicos. Isso pode demorar um pouco ... " (repetido várias vezes), seguido por " ALERT! / Dev / disk / by-uuid / ... não existe. ". (Deve-se notar que update-initramfs também reclamou de uma partição ausente.)
[2] porque seu tipo é deduzido da análise do conteúdo e não é especificado por um flag / 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 .)