A inicialização falha: o Kernel não localiza o dispositivo do sistema

Question

Atualizar . Este problema foi resolvido por uma atualização do kernel em dezembro de 2017. Eu não conseguia descobrir qual era o problema - mas, em retrospectiva, vindo de outro problema que tive, entretanto, poderia ter surgido de problemas de compatibilidade ao gravar um disco UIID com ou sem hífens: o Linux quer hífens, mas o GRUB não.

Eu corro Parabola Linux com o kernel linux-libre 4.11.9-gnu-1 e Libreboot no meu computador.

Problem: I recently updated my system (pacman -Syu), and ever since my boot process fails. Specifically, the kernel seems to fail to find the logical volume on which my actual system resides. The error I get is ERROR: device '/dev/aether/core/' not found. Skipping fsck.

Qualquer ajuda para consertar ou diagnosticar este problema é muito apreciada. Meu entendimento é pequeno demais para consertar isso e estou bastante desesperado.

Em seguida, descreverei o problema com mais detalhes e, depois disso, descreverei o que fiz até agora.

Esta é minha configuração : Eu tenho um disco sólido com uma partição única e totalmente criptografada, sobre a qual eu tenho um volume lógico chamado core dentro de um grupo de volumes chamado aether . Meu diretório system / root está no volume lógico core . (O disco está criptografado com cryptsetup , os volumes lógicos são gerenciados com lvm .)

E aqui está o que acontece quando eu inicializo (como eu interpreto).

Fase do carregador de inicialização .

1. O Libreboot carrega com êxito o GRUB.

2. O GRUB pede uma senha para descriptografar a partição criptografada.

   a. Eu digito uma frase secreta.

   b. O GRUB descriptografa com sucesso a partição criptografada.

3. O GRUB carrega com êxito a imagem do kernel e o initramfs.

Fase do kernel . O seguinte acontece:

 …
 :: running early hook [udev]
 …
 :: running early hook [lvm2]
 …
 :: running hook [encrypt]
 Waiting 10 seconds for device /dev/aether/core ...
 [    4.250559] sd 4:0:0:0:  [sdb] No Caching mode page found.
 [    4.250612] sd 4:0:0:0:  [sdb] Assuming drive cache: write through
 ERROR: device '/dev/aether/core/' not found. Skipping fsck.
 :: mounting '/dev/aether/core' on real root
 mount: you must specify the filesystem type
 You are now being dropped into an emergency shell.
 sh: can't access tty; job control turned off
 [rootfs ]#

deixei de fora algumas mensagens, indicadas por … . O registro completo é aqui , mas não acho que o restante seja útil.

O GRUB está configurado no firmware do Libreboot. Aqui está a parte relevante do meu grub.cfg :

  cryptomount -a
  set root=lvm/aether-core
  linux /boot/vmlinuz-linux-libre root=/dev/aether/core cryptdevice=/dev/disk/by-uuid/〈uuid of the encrypted partition〉:core cryptkey=rootfs:/etc/〈keyfile〉
  initrd /boot/initramfs-linux-libre.img

Eu não acho que o problema esteja no próprio GRUB.

Coisas que fiz . Eu fiz o chrooted com sucesso no meu sistema. De dentro, /dev/aether/core existe. Tanto a frase secreta quanto o arquivo de chaves desbloqueiam com sucesso a partição criptografada. Eu também tentei fazer o downgrade do kernel para 4.10.*- (alguma versão onde eu sei que eu poderia inicializar), mas também não foi possível: O problema continua.

Esta questão diz respeito a um problema semelhante. O meu é diferente em que, por um lado, o nome do dispositivo correto é citado na minha mensagem de erro e não é encontrado de qualquer maneira; e eu posso digitar o shell de emergência.

What is the problem here? How can I fix this?

    

Answer 1

Como dito na atualização:

This issue has been resolved by a kernel update in December 2017. I could not figure out what the problem had been – but in hindsight, coming from another problem I had in the meantime, it might have stemmed from compatibility issues in writing a disk UIID with or without hyphens: Linux wants hyphens, but GRUB doesn’t.

Mas, mais provavelmente, isso foi simplesmente um bug do kernel.

No entanto, tive um problema semelhante nesse meio tempo. (Ou talvez exatamente o mesmo, não consigo me lembrar.) A solução era usar diferentes UUIDs na configuração do GRUB - um para o GRUB e outro para o Linux. Especificamente, na linha

linux /boot/vmlinuz-linux-libre root=/dev/aether/core cryptdevice=/dev/disk/by-uuid/〈uuid of the encrypted partition〉:core cryptkey=rootfs:/etc/〈keyfile〉

o ⟨uuid of the encrypted partition⟩ deve ler com hífens, enquanto o ⟨uuid of the encrypted partition⟩ em

cryptomount -u ⟨uuid of the encrypted partition⟩

deve ler sem hífens. (Essa linha substituiria a linha cryptomount -a na pergunta original.)

    

Answer 2

Um palpite é que você está confiando em alguns nomes do udev que não existem no initramfs. Ou seja a partição criptografada é descriptografada, mas não vinculada a / dev / aether / core.

Eu recomendaria tentar especificar a partição raiz por UUID, ou nome, ou usar o nome do dispositivo que você usou para chroot.

Tudo isso, supondo que você não esteja usando o LVM sobre a criptografia.