O HardenedArray tem um útil guia de instalação do archlinux em Instalação Eficiente do Arco de Inicialização com UEFI Criptografado .
No entanto, encontrei dificuldades no início do processo de instalação - especificamente, no momento de abrir minha partição LUKS.
O comando cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3
é concluído sem erros, mas depois que eu digito o comando cryptsetup luksOpen /dev/sda3 tsundoku
, / dev / mapper / tsundoku não se torna disponível.
ls /dev/mapper
lista / dev / mapper / control sozinho, e não também / dev / mapper / tsundoku como seria de esperar.
A seguinte mensagem de erro aparece em cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug
:
"Tentando ler ... cabeçalho LUKS2 no deslocamento .... Falha na leitura do cabeçalho LUKS (-22). O comando falhou com o código -1 (parâmetros incorretos ou ausentes)."
Alguém poderia oferecer alguma sugestão para a causa desse erro? Minhas tentativas de pesquisa online até este ponto não foram frutíferas.
Muito obrigado
--- EDIT ---
Eu pedi esta pergunta para ajudar a alcançar qualquer um dos três objetivos: (1) para instalar o Arch-Linux (de qualquer maneira) em um ASUS Intel Core i5 2.50GHz x86-64 de 6 anos de idade; (2) mais especificamente, para instalar o arch-linux de forma segura com uma partição criptografada; (3) para saber porque, apesar das minhas expectativas,
cryptsetup luksOpen /dev/sda3 tsundoku
não cria uma entrada de mapeamento
tsundoku no caminho
/ dev / mapper .
Sou recém-chegado ao arch-linux, então, embora prefira instalar o sistema operacional com criptografia, gostaria de instalá-lo de qualquer maneira.
Eu não tive muita sorte seguindo as instruções de instalação no arch wiki oficial no passado, então ao ver o guia de instalação claramente delineado do HardenedArray, eu pensei em tentar - o pior cenário é que eu poderia encontrar um problema como o descrito acima, por meio do qual eu poderia aprender algo novo.
Quanto ao problema, aqui estão mais alguns detalhes:
De acordo com o guia do HardenedArray: Eu gdisk /dev/sda
e crie as seguintes partições:
- / dev / sda1, padrão, 100M, EF00
- / dev / sda2, padrão, 250M, 8300
- / dev / sda3, padrão, padrão, 8300
Então eu faço o seguinte:
mkfs.vfat -F 32 /dev/sda1
mkfs.ext2 /dev/sda2
Neste ponto, tento inicializar uma partição LUKS e configurar um mapeamento.
> cryptsetup --verbose -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3
Command successful
> cryptsetup -v isLuks /dev/sda3
Command successful
> ls /dev/mapper
control
> cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug
cryptsetup 2.0.0. processing "cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug"
Running command open.
Locking memory.
...
Trying to load any crypt type from device /dev/sda3.
Crypto backend ... initialized ...
Detected kernel Linux 4.14.9-1-ARCH x86_64.
...
Reading LUKS header of size 1024 from device /dev/sda3.
...
Activating volume tsundoku using token -1.
STDIN descriptor passphrase entry requested.
Activating volume tsundoku [keyslot -1] using passphrase.
...
Detected dm-ioctl version 4.37.0.
Device-mapper backend running with UDEV support enabled.
dm status tsundoku [ opencount flush ] [...] (...)
Trying to open key slot 0 [ACTIVE_LAST].
Reading key slot 0 area.
Using userspace crypto wrapper to access keyslot area.
Trying to open key slot 1 [INACTIVE].
# key slots 2-7 are also [INACTIVE]
Releasing crypt device /dev/sda3 context.
Releasing device-mapper backend.
Unlocking memory.
Command failed with code -2 (no permission or bad passphrase).
> ls /dev/mapper
control
> cryptsetup luksDump /dev/sda3
LUKS header information for /dev/sda3
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha512
...
UUID: 56d8...
Key Slot 0: ENABLED
...
Key Slot 1: DISABLED
# Key Slots 2-7 are also DISABLED
As etapas listadas acima são imprecisas de alguma forma? Talvez houvesse alternativas que eu deveria ter tomado em vez disso ou intervindo ações que eu perdi?
Se não, o comando cryptsetup luksOpen /dev/sd{a} {volume}
deve criar um mapeamento de volume no caminho / dev / mapper ?
Em caso afirmativo, os detalhes que eu adicionei acima permitem que alguém verifique por que o caminho / dev / sda3 / tsundoku não aparece na minha máquina? E se não, há alguma informação adicional que eu possa adicionar para tornar o problema mais claro?
Muito obrigado.