ZFS no LUKS não reconhecido na inicialização

Question

Eu tenho 6 drives físicos no RAID-Z2, que pretendo converter um por um em dispositivos dm-crypt.

Meu processo foi aproximadamente:

1. dd if=/dev/zero of=/dev/sdf
2. Criar arquivo-chave /etc/crypttab.d/crypt-1.key
3. cryptsetup luksFormat /dev/sdf
4. Anexar crypt-1 <raw-disk-uuid> /etc/crypttab.d/crypt-1.key luks a /etc/crypttab
5. cryptsetup luksOpen /dev/sdf crypt-1
6. zfs replace my_pool <raw-disk-uuid> /dev/mapper/crypt-1

Uma vez que o resilvering foi concluído (o que funcionou bem), reiniciei a máquina para verificar a configuração antes de continuar com outros discos. O que eu encontrei, no entanto, foi que o ZFS rotulou crypt-1 como UNAVAIL.

ls /dev/mapper verificou que o dm-crypt ativou o contêiner LUKS corretamente. A execução de zpool online my_pool crypt-1 faz com que o ZFS inicie a recuperação, mas conclui e retoma a operação em segundos.

Eu estou supondo que o dispositivo dm-crypt simplesmente não é carregado quando o ZFS primeiro tenta acessar my_pool ? É uma questão de ordem de carregamento ou preciso usar um identificador diferente para o dispositivo LUKS em /etc/crypttab ? Como posso garantir que o ZFS veja esses dispositivos LUKS na reinicialização?

Esta é uma systemd box (Arch) se isso for importante.

Obrigado!

EDIT 1:

Durante a criação do cryptsetup, usei os identificadores SCSI (por exemplo, /dev/sdf ) para inicializar o dispositivo com o LUKS. No entanto, em /etc/crypttab estou especificando os dispositivos por meio do UUID do disco físico subjacente. A utilidade cryptsetup é sensível a como você identifica os destinos? Em outras palavras, preciso refazer meu cryptsetup e passar o UUID do disco em vez do nome SCSI?

EDIT 2:

Eu vejo o seguinte ls -alsvh /dev/disk/by-id :

0 lrwxrwxrwx 1 root root  10 Jul  8 08:18 dm-uuid-CRYPT-LUKS1-6bed03ceaafe4539a375536d11309ff0-locker-1 -> ../../dm-0

Pelo que sei, se estiver em /dev/disk/by-id , é - por definição? - não está sujeito a alterações (mesmo durante as reinicializações). Eu substituirei a definição do nome-crypt-dm locker-1 em meu zpool com o id-name /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-6bed03ceaafe4539a375536d11309ff0-locker-1 e reportarei de volta. Mesma unidade, mesmo contêiner LUKS, apenas uma maneira diferente de endereçá-lo.

EDIT 3:

Minha proposta da edição 2 acima não funcionou. Eu tive que limpar a unidade e refazer ocryptsetup do dispositivo porque o ZFS não me permitiria substituir o dispositivo por ele mesmo. Depois que o resilvering foi concluído, reiniciei e zpool status é DEGRADED e o dispositivo dm-uuid-CRYPT-LUKS1-71e12fa7dc034d919e800ba89aec3b17-locker-1 é UNAVAIL .

Vale a pena notar que locker-1 aparece em ls /dev/disk/by-id , bem como lsblk , por isso está sendo carregado corretamente. Posso verificar isso executando:

zpool online inground dm-uuid-CRYPT-LUKS1-71e12fa7dc034d919e800ba89aec3b17-locker-1

Que sai de forma limpa e traz o dispositivo de volta ao pool.

Talvez isso seja devido à ordem de carga de diferentes módulos durante a inicialização? Talvez a ativação de dispositivos dm-crypt seja feita de tal forma que o ZFS comece a importar pools antes que o contêiner LUKS esteja apropriadamente aberto?

    

Answer 1

Você pode tentar exportar seu pool e, em seguida, vincular simbolicamente os nós de dispositivos de componentes de chamada em, por exemplo. / dev / vdevs e execute

zpool import -d /dev/vdevs poolname

Se o vdev for encontrado dessa maneira, você poderá fazer com que o symlinking ocorra antes da importação de zpool no processo de boot (seja através do udev ou de um script) como uma solução alternativa.