Yrurtj

HardenedArray has a helpful archlinux-installation guide at Efficient Encrypted UEFI-Booting Arch Installation.

However, I encountered difficulty early in the installation process -- specifically, at the point of opening my LUKS partition.

The command cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3 completes without error, but after I enter the command cryptsetup luksOpen /dev/sda3 tsundoku, /dev/mapper/tsundoku does not become available.

ls /dev/mapper lists /dev/mapper/control alone, and not also /dev/mapper/tsundoku as I would expect.

The following error message appears upon cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug:

"Trying to read ... LUKS2 header at offset .... LUKS header read failed (-22). Command failed with code -1 (wrong or missing parameters)."

Could anyone offer any hints at to the cause of this error? My attempts at online research to this point haven't been fruitful.

Thanks much

--- EDIT ---

I've asked this question for help to achieve any of three goals: (1) to install arch-linux (in any manner) on a 6ish-year-old x86-64 Intel Core i5 2.50GHz ASUS; (2) more specifically, to install arch-linux securely with an encrypted partition; (3) to learn why, despite my expectations, cryptsetup luksOpen /dev/sda3 tsundoku does not create a tsundoku mapping entry in the path /dev/mapper.

I'm a newcomer to arch-linux, so although I'd prefer installing the OS with encryption, I'd settle for installing it in any way.

I haven't had much luck following the installation instructions in the official arch wiki in the past, so upon seeing HardenedArray's clearly delineated installation guide, I thought I'd give it a go -- worst case scenario being that I might encounter a problem like the one described above, whereby I might learn something new.

As for the issue, here are some more details:

As per HardenedArray's guide: I gdisk /dev/sda and create the following partitions:

• /dev/sda1, default, 100M, EF00


• /dev/sda2, default, 250M, 8300


• /dev/sda3, default, default, 8300

Then I do the following:

mkfs.vfat -F 32 /dev/sda1

mkfs.ext2 /dev/sda2

At this point, I attempt to initialize a LUKS partition and set up a mapping.

> 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

Are the steps I've listed above inaccurate in any way? Perhaps there were alternatives I should have taken instead or intervening actions that I missed?

If not, is the command cryptsetup luksOpen /dev/sd{a} {volume} supposed to create a volume mapping in the path /dev/mapper?

If so, do the details I've added above allow anyone to ascertain why the path /dev/sda3/tsundoku does not appear on my machine? And if not, is there any additional information that I could add to make the problem clearer?

Thanks much.

You're using the wrong command instead use the following command until you complete install and boot into your new Arch OS:

# cryptsetup --type luks open /dev/sdaX plain1 #change **plain1** to your map location 

After you boot into your new OS then you can use the other one. Don't forget DuckDuckGo, Qwant, Google and so on are your friends. Carry on from there, good luck.