Eu tenho uma configuração de inicialização tripla (3xLinux). Todos os Linux compartilham /homee swap, e suas /partições estão próximas umas das outras. Todos residem em um LVM no LUKS:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 951.8G 0 disk
|-nvme0n1p1 259:1 0 800M 0 part /boot/efi
|-nvme0n1p2 259:2 0 32G 0 part
|-nvme0n1p3 259:3 0 619M 0 part
`-nvme0n1p4 259:4 0 706.5G 0 part
`-cryptolvm 254:0 0 706.5G 0 crypt
|-cryptolvm-swap 254:1 0 32G 0 lvm [SWAP]
|-cryptolvm-home 254:2 0 430.0G 0 lvm /home
|-cryptolvm-centos 254:3 0 41G 0 lvm /mnt/centos
|-cryptolvm-arch 254:4 0 41G 0 lvm /
`-cryptolvm-opensuse 254:5 0 41G 0 lvm /mnt/opensuse
O openSUSE gerencia o GRUB2 (com criptografia completa, ou seja, senha de desbloqueio de disco necessária antes do menu grub que reside na partição do sistema openSUSE /).
Problema: O Arch não desbloqueia o cryptodisk /dev/nvme0n1p4e, portanto, não pode acessá-lo /durante a inicialização. Isso me leva a um prompt de emergência.
Esta é a configuração de um Arch Linux:
mkinitcpioconfiguração (e sim, eu recriei /boot/initramfs-linux.imgdepois de alterar isso):
# grep crypt /etc/mkinitcpio.conf | tail -1
HOOKS=(base udev autodetect modconf keyboard block encrypt lvm2 filesystems fsck)
Configuração do GRUB2 no openSUSE:
# grep --after=18 Arch /mnt/opensuse/boot/grub2/grub.cfg
menuentry 'Arch Linux (rolling) (on /dev/mapper/cryptolvm-arch)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa' {
insmod part_gpt
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod lvm
insmod ext2
cryptomount -u 99999999999999999999999999999999
set root='lvmid/VVVVVV-VVVV-VVVV-VVVV-VVVV-VVVV-VVVVVV/qqqqqq-qqqq-qqqq-qqqq-qqqq-qqqq-qqqqqq'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='lvmid/VVVVVV-VVVV-VVVV-VVVV-VVVV-VVVV-VVVVVV/qqqqqq-qqqq-qqqq-qqqq-qqqq-qqqq-qqqqqq' aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
else
search --no-floppy --fs-uuid --set=root aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
fi
linuxefi /boot/vmlinuz-linux cryptdevice=UUID=99999999999999999999999999999999:cryptolvm root=/dev/mapper/cryptolvm-arch resume=/dev/cryptolvm/swap splash=silent quiet showopts
initrdefi /boot/initramfs-linux.img
}
Dispositivos LVM:
# vgs -v
VG Attr Ext #PV #LV #SN VSize VFree VG UUID VProfile
cryptolvm wz--n- 4.00m 1 5 0 706.45g <120.51g VVVVVV-VVVV-VVVV-VVVV-VVVV-VVVV-VVVVVV
# lvs -v | grep arch
arch cryptolvm 1 -wi-ao---- <40.96g -1 -1 254 4 qqqqqq-qqqq-qqqq-qqqq-qqqq-qqqq-qqqqqq
UUIDs de disco/partição:
# blkid | egrep '(p4|arch)'
/dev/nvme0n1p4: UUID="99999999-9999-9999-9999-999999999999" TYPE="crypto_LUKS" PARTUUID="cccccccc-cccc-cccc-cccc-cccccccccccc"
/dev/mapper/cryptolvm-arch: UUID="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" PARTUUID="cccccccc-cccc-cccc-cccc-cccccccccccc"
Gambiarra:
O GRUB2 (ou initramfs) me deixa em um prompt porque não pode ser montado /dev/mapper/cryptolvm-archem /(ou em /new_root). Então durante cada boot eu entro manualmente:
> cryptsetup open /dev/nvme0n1p4 cryptolvm
(...)
> mount /dev/mapper/cryptolvm-arch /new_root
> ^D
Por que isso é necessário? A montagem é dada duas vezes ( cryptomounte cryptdevice) em grub.cfg(e isso é realmente usado).
EDITAR:
Talvez isso tenha a ver com EFI? Eu receberia um erro EFI se fosse? O openSUSE inicializa via EFI, carrega em cadeia o arquivo grub.cfg, /depois inicializa o Arch - está linuxeficorreto aqui?
Pouco antes do GRUB2 me deixar no shell de emergência, posso digitar as teclas e elas aparecem na tela. Quando o shell abre, os caracteres digitados ainda estão no buffer e são inseridos nesse shell.
Inicie seu sistema com o sinalizador de kernel rd.debug (init-ramdisk debug) adicionado. Isso deve lançar alguma luz sobre o que está acontecendo de errado.
Se você tiver, você pode exibir as últimas uma ou duas telas com saÃda xtrace se você não puder resolver o problema então.
Você também pode direcionar a saÃda para arquivos em adição (ou seja, adicionar rd.log=all sinalizador à s opções do kernel) e deve ser capaz de obter o log como texto copiável e melhor rolável após a inicialização ser concluÃda.
E, o que eu esqueci, em seus trechos acima, você anonimizou por qualquer motivo o UUID e eu não sei qual é sua configuração original, mas você esqueceu os traços.
Exemplo do meu sistema (o blkid é o comando que é executado para encontrar o dispositivo fÃsico da
cryptdevice=UUID=21685fd6-f2e3-4037-8645-3957cff3568c:cryptolvmopção Seu kernel, a parte entre cryptodevice= até os primeiros dois pontos será pesquisada com o comando abaixo):Você diz "GRUB2 me deixa em um prompt porque não pode ser montado
/dev/mapper/cryptolvm-archem/", mas isso não se parece com um prompt do GRUB. Os comandos que você está digitando não são comandos GRUB, mas comandos (Arch) Linux. Você já passou pelo EFI, pelo GRUB e, aparentemente, pelo Archinitramfs.O prompt se parece com um prompt de shell de emergência baseado em initramfs. O trabalho do GRUB é carregar duas coisas: um kernel e um arquivo initramfs. Uma vez que o GRUB tenha feito isso e passado o controle para o kernel, o trabalho do GRUB está feito . O
cryptomountcomando diz ao GRUB para desbloquear um disco criptografado para essa finalidade, mas o GRUB não tem como passar esse estado desbloqueado, ou mesmo uma senha de criptografia, para o kernel.Uma vez que o kernel é inicializado,
initramfsele deve ter todas as ferramentas necessárias para desbloquear a criptografia do disco novamente, seja solicitando a senha novamente ou armazenando a senha no arquivo initramfs; como o arquivo initramfs é armazenado em um disco criptografado no seu caso, isso pode ser aceitável.Além disso, observe que você disse "... porque não pode ser montado
/dev/mapper/cryptolvm-archem/". Se a mensagem de erro disser exatamente assim, o problema pode ser que o initramfs está tentando montar diretamente/por algum motivo. Você não pode fazer isso. Em vez disso, o novo sistema de arquivos raiz deve ser montado primeiro em outro lugar (como/new_root) e, em seguida, um comando especial dentro do initramfs mudará o novo sistema de arquivos raiz para o lugar.Em vez de olhar para EFI e GRUB, talvez você deva se concentrar no conteúdo do arquivo initramfs do Arch. Ele deve estar executando precisamente esses dois comandos que você está digitando manualmente (talvez substituindo
/dev/nvme0n1p4por umaUUID=sintaxe), mas por algum motivo isso não está acontecendo. Descubra o porquê, e você encontrará a causa de seus problemas.