HardenedArray hat eine hilfreiche Archlinux-Installationsanleitung unter Efficient Encrypted UEFI-Booting Arch Installation.
Ich bin jedoch zu Beginn des Installationsprozesses auf Schwierigkeiten gestoßen – insbesondere beim Öffnen meiner LUKS-Partition.
Der Befehl cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3 ohne Fehler abgeschlossen, aber nachdem ich den Befehl cryptsetup luksOpen /dev/sda3 tsundoku eingegeben habe , /dev/mapper/tsundoku nicht verfügbar.
ls /dev/mapper listet /dev/mapper/control auf allein und nicht auch /dev/mapper/tsundoku wie ich es erwarten würde.
Die folgende Fehlermeldung erscheint bei cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug :
„Versuch zu lesen … LUKS2-Header bei Offset …. Lesen des LUKS-Headers fehlgeschlagen (-22). Befehl fehlgeschlagen mit Code -1 (falsche oder fehlende Parameter).“
Kann jemand Hinweise auf die Ursache dieses Fehlers geben? Meine bisherigen Versuche der Online-Recherche waren nicht erfolgreich.
Vielen Dank
— BEARBEITEN —
Ich habe diese Frage um Hilfe gestellt, um eines von drei Zielen zu erreichen:(1) Arch-Linux (auf irgendeine Weise) auf einem 6 Jahre alten x86-64 Intel Core i5 2,50 GHz ASUS zu installieren; (2) genauer gesagt, Arch-Linux sicher mit einer verschlüsselten Partition zu installieren; (3) um zu erfahren, warum trotz meiner Erwartungen cryptsetup luksOpen /dev/sda3 tsundoku erstellt kein Tsundoku Zuordnungseintrag im Pfad /dev/mapper .
Ich bin ein Neuling in Arch-Linux, also würde ich es zwar vorziehen, das Betriebssystem verschlüsselt zu installieren, aber ich würde mich damit begnügen, es auf irgendeine Weise zu installieren.
Ich hatte in der Vergangenheit nicht viel Glück, den Installationsanweisungen im offiziellen Arch-Wiki zu folgen, also dachte ich, als ich die klar umrissene Installationsanleitung von HardenedArray sah, ich würde es versuchen – im schlimmsten Fall könnte ich auf ein Problem wie stoßen die oben beschriebene, wodurch ich etwas Neues lernen könnte.
Was das Problem betrifft, hier sind einige weitere Details:
Gemäß der Anleitung von HardenedArray:I gdisk /dev/sda und erstellen Sie die folgenden Partitionen:
- /dev/sda1, Standard, 100M, EF00
- /dev/sda2, Standard, 250 MB, 8300
- /dev/sda3, Standard, Standard, 8300
Dann gehe ich wie folgt vor:
mkfs.vfat -F 32 /dev/sda1
mkfs.ext2 /dev/sda2
An diesem Punkt versuche ich, eine LUKS-Partition zu initialisieren und eine Zuordnung einzurichten.
> 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
Sind die Schritte, die ich oben aufgeführt habe, in irgendeiner Weise ungenau? Vielleicht gab es Alternativen, die ich stattdessen hätte ergreifen sollen, oder Zwischenmaßnahmen, die ich übersehen habe?
Verwandt:Nur übertragene Dateien mit rsync protokollieren?
Wenn nicht, ist der Befehl cryptsetup luksOpen /dev/sd{a} {volume} soll ein Volume-Mapping im Pfad /dev/mapper erstellen ?
Wenn ja, erlauben die Details, die ich oben hinzugefügt habe, jedem, festzustellen, warum der Pfad /dev/sda3/tsundoku erscheint nicht auf meinem Rechner? Und wenn nicht, gibt es weitere Informationen, die ich hinzufügen könnte, um das Problem klarer zu machen?
Vielen Dank.
Akzeptierte Antwort:
Sie verwenden den falschen Befehl. Verwenden Sie stattdessen den folgenden Befehl, bis Sie die Installation abgeschlossen und Ihr neues Arch-Betriebssystem gestartet haben:
# cryptsetup --type luks open /dev/sdaX plain1 #change **plain1** to your map location
Nachdem Sie Ihr neues Betriebssystem gestartet haben, können Sie das andere verwenden. Vergessen Sie nicht, DuckDuckGo, Qwant, Google und so weiter sind Ihre Freunde. Mach weiter so, viel Glück.