Não inicializa (drop to busybox) após a atualização do kernel (com discos criptografados)

Question

Eu tenho dois sistemas - um 14.04.03 LTS e um 16.04 LTS, ambos os quais não estão inicializando após atualizações recentes do kernel. Qualquer ajuda seria apreciada - não sou especialista, mas parece-me que o novo kernel simplesmente não está vendo os sistemas de arquivos criptografados no momento da inicialização.

Para ambos os sistemas, usei o instalador para criptografar a unidade de inicialização. Mais tarde, adicionei um segundo disco, criptografado usando o LUKS, montado automaticamente no momento da inicialização usando um arquivo de chaves. Eu (aproximadamente - foi feito depois que o sistema foi instalado e inicializado) segui as instruções aqui:

link

Veja mais alguns detalhes sobre os sistemas:

Para o sistema 16.04 LTS:

O hardware é um SSD mSATA em /dev/sdb , no qual o Ubuntu foi instalado usando a configuração de partição automática ( / e swap). Uma unidade Sata de 500 GB em /dev/sda é usada para /data - depois que o sistema estava ativo e em execução, a partição luks foi criada e configurada para montagem automática na inicialização com um arquivo de chaves.

$ uname -a
Linux <hostname> 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 X86_64 GNU/Linux

$ cat /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/ubuntu--vg-root /               ext4    errors=remount-ro 0       1

# /boot was on /dev/sdb2 during installation
UUID=5039XXXX-XXXX-XXXX-XXXX-d2b4XXXXXXXX /boot           ext2    defaults        0       2

# /boot/efi was on /dev/sdb1 during installation
UUID=1DXX-XX4D  /boot/efi       vfat    umask=0077        0       1
/dev/mapper/ubuntu--vg-swap_1 none            swap    sw              0       0

# encrypted disk /data (unlocked with keyfile
/dev/mapper/data_crypt  /data   ext4    errors=remount-ro   0   1

$ cat /etc/crypttab 
sdb3_crypt UUID=0bg9rz-XXXX-XXXX-XXXX-XXXX-XXXX-XXqvBH none luks
data_crypt UUID=453cXXXX-XXXX-XXXX-XXXX-6926XXXXXXXX /root/<keyfile> luks 

Quando 4.4.0-21 é selecionado no grub, um prompt de senha para desbloquear sdb3_crypt aparece imediatamente. O sistema então trava no prompt de inicialização do ubuntu. Pressionar delete mostra a seguinte mensagem de erro. Após alguns minutos, o sistema realmente inicializa e data_crypt é montado em /data conforme o esperado

[ 2.091698] [drm:intel_set_pch_fifo_underrun_reporting [i915]] ERROR uncleared pch fifo underrun on pch transcoder a
[ 2.091735] [drm:intel_pch_fifo_underrun_irq_handler [i915]] ERROR PCH transcoder A FIFO underrun
lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
cannot process volume group ubuntu-vg
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
Reading all physical volumes. This may take a while...
Found volume group "ubuntu-vg" using metadata type lvm2
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
WARNING: failed to connect to lvmetad. Falling back to internal scanning.
2 logical volume(s) in volume group "ubuntu-vg" now active
/dev/mapper/ubuntu--vg-root: clean 488960/6750209 files, 11825728/26996736 blocks
[  ***] A start job is running for dev-disk-by\x2duuid-0bg9rZ\X2deNSE\x2d1E8u\x2XXXXX\x2XXXXX\x2XXXX\x2dZpqvBH.device (xxS / 1min 30s)

A partir do menu Grub, selecione 4.4.0-22 ou 4.4.0-24 e, em seguida, pressione delete para exibir as seguintes informações (transcritas):

[ 2.091698] [drm:intel_set_pch_fifo_underrun_reporting [i915]] ERROR uncleared pch fifo underrun on pch transcoder a
[ 2.091735] [drm:intel_pch_fifo_underrun_irq_handler [i915]] ERROR PCH transcoder A FIFO underrun
lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
cannot process volume group ubuntu-vg
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
WARNING: failed to connect to lvmetad. Falling back to internal scanning.
Reading all physical volumes. This may take a while.

As últimas 3 linhas se repetem 30 vezes e depois de alguns minutos caem em um shell do busybox. Executar manualmente cryptsetup luksOpen /dev/sdb3 sdb3_crypt (e digitar a frase secreta) é ok, mas não consigo montá-lo (provavelmente porque está no initramfs e não sei o que estou fazendo lá).

A exclusão de linhas relacionadas a data_crypt de /etc/fstab e /etc/crypttab não faz diferença, portanto, não acho que isso esteja relacionado à monta automática desse disco causando problemas.

Eu também tentei recriar o initramfs para esses kernels, o que não fez nenhuma diferença.

Eu também estou tendo um problema semelhante em um sistema LTS 14.04.03, como descrito abaixo, mas não posso fornecer detalhes exatos (é o sistema que estou postando isso).

Para 14.04.03 Sistema LTS:

Hardware é um SSD NVMe para / e swap, e um disco SATA de 1TB para /data . Novamente, o Ubuntu foi instalado no SSD e, posteriormente, a unidade SATA foi conectada, configurada como uma partição criptografada usando luks e, em seguida, adicionada ao automount na inicialização com um arquivo de chaves.

pacotes para o kernel xenial foram instalados:

• linux-generic-lts-xenial
• linux-headers-generic-lts-xenial
• linux-image-generic-lts-xenial

Saída de comando:

Linux hostname 4.2.0-36-generic #42~14.04.1-Ubuntu SMP Fri May 13 17:27:22 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/fstab

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/ubuntu--vg-root /               ext4    errors=remount-ro 0       1

# /boot was on /dev/nvme0n1p2 during installation
UUID=0657XXXX-XXXX-XXXX-XXXX-1be3XXXXXXXX /boot           ext2    defaults        0       2

# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=AEXX-XX66  /boot/efi       vfat    defaults        0       1
/dev/mapper/ubuntu--vg-swap_1 none            swap    sw              0       0

# encrypted disk /data (unlocked with keyfile
/dev/mapper/data_crypt  /data   ext4    errors=remount-ro   0   1

$ cat /etc/crypttab 
nvme0n1p3_crypt UUID=61235695-XXXX-XXXX-XXXX-962cXXXXXXXX none luks,discard
data_crypt UUID=2e92XXXX-XX57-XXXX-XXXX-af9fXXXXXXXX /root/<keyfile> luks

Qualquer um dos kernels da série 4.4 não inicializa. O kernel da série 4.2 é inicializado bem.

    

Answer 1

Ok, descobri.

O UUID de sdb3_crypt (onde / e swap estão localizados) de alguma forma não estava correto em / etc / crypttab. Eu verifiquei isso comparando os UUIDs listados em / etc / crypttab com aqueles listados em / dev / disk / by-uuid /. Não faço ideia de como isso deu errado, mas eu devo ter digitado em algum lugar ao longo do caminho.

Eu corrigii o / etc / crypttab com o UUID correto de / dev / sdb3, depois atualizei o initramfs ($ update-initramfs -c -k 4.4.0-24-generic). Reinicie e agora funciona ok.

    

Answer 2

Eu tive um problema semelhante, exceto que meu /etc/crypttab estava completamente ausente. Recentemente eu atualizei meu disco rígido mecânico para um SSD. Em ambos tenho tudo, mas /boot criptografado, e o processo de inicialização estava funcionando muito bem. Além disso, verifiquei um backup de algumas semanas antes e o crypttab estava lá.

Eu segui a resposta para este post para corrigir o meu problema.

Reinstale as partições criptografadas existentes

Observe o comentário de três das montagens. Estes estão errados e devem ser:

# mount --bind /dev /mnt/ubuntu/dev
# mount --bind /sys /mnt/ubuntu/sys
# mount -t proc none /mnt/ubuntu/proc

Além disso, observe que o UUID no crypttab deve ser para o contêiner que contém o volume LUKS (no meu caso, /dev/sda5 ), não para o volume LUKS depois que ele é descriptografado. (Isso diz isso, mas eu perdi na primeira vez, então pensei em apontar isso.)

Nota final, tenho que dizer que esse mau comportamento por parte do atualizador - tornar o computador não inicializável - é o tipo de problema que impede o Linux de obter um público mais amplo entre usuários típicos de desktop.