HardenedArray ha un'utile guida all'installazione di archlinux in Efficient Encrypted UEFI-Booting Arch Installation.
Tuttavia, ho riscontrato difficoltà all'inizio del processo di installazione, in particolare al momento dell'apertura della mia partizione LUKS.
Il comando cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3 si completa senza errori, ma dopo aver immesso il comando cryptsetup luksOpen /dev/sda3 tsundoku , /dev/mapper/tsundoku non diventa disponibile.
ls /dev/mapper elenca /dev/mapper/control da solo, e non anche /dev/mapper/tsundoku come mi aspetterei.
Il seguente messaggio di errore appare su cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug :
“Sto cercando di leggere... Intestazione LUKS2 in offset... Lettura dell'intestazione LUKS non riuscita (-22). Comando non riuscito con codice -1 (parametri errati o mancanti)."
Qualcuno potrebbe fornire suggerimenti sulla causa di questo errore? I miei tentativi di ricerca online fino a questo punto non sono stati fruttuosi.
Grazie mille
— MODIFICA —
Ho posto questa domanda per aiuto per raggiungere uno qualsiasi dei tre obiettivi:(1) installare arch-linux (in qualsiasi modo) su un ASUS x86-64 Intel Core i5 2.50GHz di 6 anni fa; (2) più specificamente, per installare arch-linux in modo sicuro con una partizione crittografata; (3) per sapere perché, nonostante le mie aspettative, cryptsetup luksOpen /dev/sda3 tsundoku non crea uno tsundoku voce di mappatura nel percorso /dev/mapper .
Sono un nuovo arrivato in arch-linux, quindi anche se preferirei installare il sistema operativo con crittografia, mi accontenterei di installarlo in qualsiasi modo.
In passato non ho avuto molta fortuna seguendo le istruzioni di installazione nel wiki ufficiale di arch, quindi dopo aver visto la guida all'installazione chiaramente delineata di HardenedArray, ho pensato di provarci - lo scenario peggiore è che potrei incontrare un problema come quello descritto sopra, per cui potrei imparare qualcosa di nuovo.
Per quanto riguarda il problema, ecco qualche dettaglio in più:
Secondo la guida di HardenedArray:I gdisk /dev/sda e crea le seguenti partizioni:
- /dev/sda1, predefinito, 100 milioni, EF00
- /dev/sda2, predefinito, 250 milioni, 8300
- /dev/sda3, predefinito, predefinito, 8300
Quindi faccio quanto segue:
mkfs.vfat -F 32 /dev/sda1
mkfs.ext2 /dev/sda2
A questo punto, provo a inizializzare una partizione LUKS e a impostare una mappatura.
> 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
I passaggi che ho elencato sopra sono in qualche modo imprecisi? Forse c'erano alternative che avrei dovuto intraprendere o interventi che mi sono perso?
Correlati:registrazione solo dei file trasferiti con rsync?
In caso contrario, è il comando cryptsetup luksOpen /dev/sd{a} {volume} dovrebbe creare una mappatura del volume nel percorso /dev/mapper ?
In tal caso, i dettagli che ho aggiunto sopra consentono a chiunque di accertare perché il percorso /dev/sda3/tsundoku non appare sulla mia macchina? E in caso negativo, ci sono ulteriori informazioni che potrei aggiungere per chiarire il problema?
Grazie mille.
Risposta accettata:
Stai usando il comando sbagliato, invece, usa il seguente comando fino al completamento dell'installazione e all'avvio nel tuo nuovo sistema operativo Arch:
# cryptsetup --type luks open /dev/sdaX plain1 #change **plain1** to your map location
Dopo aver avviato il tuo nuovo sistema operativo, puoi utilizzare l'altro. Non dimenticare che DuckDuckGo, Qwant, Google e così via sono tuoi amici. Continua da lì, buona fortuna.