Why not encrypt everything, you think. Well why not?
So you want something that plays nice with btrfs. And you don't feel like touching lvm so soon.
dm-crypt/luks on an entire partition, btrfs inside with subvolumes: almost everything is encrypted.
btrfs on partition, systemd-homed for user:
your user home can be encrypted, nothing else is,
eg: wifi passwords in
wireguard passwords somewhere in
cryptsetup luksFormat /dev/nvme0n1p2
cryptsetup open /dev/nvme0n1p2 rootlast arg is the name to be used in
mkfs.fat -F 32 /dev/nvme0n1p1
mount -o compress=zstd /dev/mapper/root /mnt
btrfs subvolume create /mnt/arch/@
mount -o compress=zstd,subvol=arch/@ /dev/mapper/root /mnt
mount /dev/nvme0n1p1 /mnt/boot
timedatectl set-ntp true
iwd station wlan0 connect $network
reflector --save /etc/pacman.d/mirrorlist -f 5 -p https
pacstrap /mnt base base-devel linux linux-firmware intel-ucode btrfs-progs zsh zsh-completions iwd git neovim, minimal set of things to work confortable after reboot
genfstab -U /mnt >> /mnt/etc/fstab, alternatively edit it to use
HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt filesystems fsck), sd-vconsole is optional
root UUID=..., this will get included in the initramfs so no kernel cmdlines are needed
mkinitcpio -por the foolproof way
pacman -S linux
echo "default arch\ntimeout 0\nconsole-mode max" > /boot/loader/loader.conf
root=/dev/mapper/rootis reliable enough since it is mapped from a UUID in our
title Arch Linux linux /vmlinuz-linux initrd /intel-ucode.img initrd /initramfs-linux.img options root=/dev/mapper/root rootflags=compress=zstd:3,ssd,space_cache,subvol=arch/@ quiet rw
The archwiki will at times refer to a boot partition and a efi/esp partition.
UEFI only cares about the bit that is FAT32 and contains efi things it can load: systemd-boot, kernel EFISTUB, grub, ...
Arch cares about the "boot partition" because by default hooks will dump the resulting files into
The lazy way mounts the efi partition at
/boot, UEFI things are contained in
the disadvantages being you need a bigger EFI partition to hold the kernel and stuff and they're not really protected.
The more involved way is the encrypted boot: grub (only grub supports this) is installed onto the unencrypted EFI partition, where it knows how to decrypt the encrypted boot partition and start the kernel from there. Note this doesn't protect against someone modifying your bootloader.
The correct solution is Secure Boot with your own keys: UEFI firmware verifies the bootloader, the bootloader verifies the kernel, the kernel verifies its drivers. It doesn't matter that the bootloader and the kernel sit out in the open unencrypted, they shouldn't have secrets in them and any attempt to tamper with them would invalidate the signature and break the verification chain.
you can either specify the devices to decrypt in the boot cmdline through the bootloader or as a file which gets built into the initramfs, cmdlines will override all file mounts.
/etc/crypttab is not necessary since the root device (our only one) needs to already be unlocked when it is read.
you can use a luks device to back a systemd-homed home, so you can have a luks in your luks...
alternatively you can back it with a btrfs subvolume in your already encrypted system.