HardenedArray propose un guide d'installation archlinux utile sur Efficient Encrypted UEFI-Booting Arch Installation.
Cependant, j'ai rencontré des difficultés au début du processus d'installation, en particulier au moment d'ouvrir ma partition LUKS.
La commande cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3 se termine sans erreur, mais après avoir entré la commande cryptsetup luksOpen /dev/sda3 tsundoku , /dev/mapper/tsundoku ne devient pas disponible.
ls /dev/mapper répertorie /dev/mapper/control seul, et pas aussi /dev/mapper/tsundoku comme je m'y attendais.
Le message d'erreur suivant apparaît sur cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug :
"Essayer de lire ... l'en-tête LUKS2 à l'offset .... La lecture de l'en-tête LUKS a échoué (-22). La commande a échoué avec le code -1 (paramètres erronés ou manquants)."
Quelqu'un pourrait-il offrir des indices sur la cause de cette erreur? Mes tentatives de recherche en ligne jusqu'à présent n'ont pas été fructueuses.
Merci beaucoup
— MODIFIER —
J'ai posé cette question pour obtenir de l'aide pour atteindre l'un des trois objectifs suivants :(1) installer arch-linux (de quelque manière que ce soit) sur un ASUS x86-64 Intel Core i5 2,50 GHz de 6 ans ; (2) plus spécifiquement, pour installer arch-linux en toute sécurité avec une partition chiffrée; (3) pour savoir pourquoi, malgré mes attentes, cryptsetup luksOpen /dev/sda3 tsundoku ne crée pas de tsundoku entrée de mappage dans le chemin /dev/mapper .
Je suis un nouveau venu sur arch-linux, donc bien que je préfère installer le système d'exploitation avec cryptage, je me contenterais de l'installer de quelque manière que ce soit.
Je n'ai pas eu beaucoup de chance en suivant les instructions d'installation du wiki officiel de l'arche dans le passé, donc en voyant le guide d'installation clairement défini de HardenedArray, j'ai pensé que j'allais essayer - le pire des cas étant que je pourrais rencontrer un problème comme celui décrit ci-dessus, grâce auquel je pourrais apprendre quelque chose de nouveau.
En ce qui concerne le problème, voici quelques détails supplémentaires :
Selon le guide de HardenedArray :je gdisk /dev/sda et créez les partitions suivantes :
- /dev/sda1, par défaut, 100M, EF00
- /dev/sda2, par défaut, 250M, 8300
- /dev/sda3, par défaut, par défaut, 8300
Ensuite, je fais ce qui suit :
mkfs.vfat -F 32 /dev/sda1
mkfs.ext2 /dev/sda2
À ce stade, j'essaie d'initialiser une partition LUKS et de configurer un mappage.
> 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
Les étapes que j'ai énumérées ci-dessus sont-elles inexactes de quelque manière que ce soit ? Peut-être y avait-il des alternatives que j'aurais dû prendre à la place ou des actions intermédiaires que j'ai ratées ?
Connexe :Enregistrer uniquement les fichiers transférés avec rsync ?
Sinon, est-ce que la commande cryptsetup luksOpen /dev/sd{a} {volume} censé créer un mappage de volume dans le chemin /dev/mapper ?
Si tel est le cas, les détails que j'ai ajoutés ci-dessus permettent-ils à quiconque de déterminer pourquoi le chemin /dev/sda3/tsundoku n'apparaît pas sur ma machine ? Et si non, y a-t-il des informations supplémentaires que je pourrais ajouter pour clarifier le problème ?
Merci beaucoup.
Réponse acceptée :
Vous utilisez la mauvaise commande à la place, utilisez la commande suivante jusqu'à ce que vous terminiez l'installation et que vous démarriez dans votre nouvel Arch OS :
# cryptsetup --type luks open /dev/sdaX plain1 #change **plain1** to your map location
Après avoir démarré dans votre nouveau système d'exploitation, vous pouvez utiliser l'autre. N'oubliez pas DuckDuckGo, Qwant, Google et ainsi de suite sont vos amis. Continuez à partir de là, bonne chance.