I’ll fallback to scripts :-)

Mostly because I want this somewhat rare combination in partioning where LUKS2 is used together with EXT4 and encryption is done without LVM2 layer and swap space huge to allow testing hibernate (especially encrypted hibernate):

!/usr/bin/env sh

set -e

# Partition
sgdisk -Z /dev/nvme0n1
sgdisk -n1:0:+5G -t1:ef00 -c1:EFI /dev/nvme0n1
sgdisk -n2:0:+75G -t2:8200 -c2:secswap /dev/nvme0n1
sgdisk -N3 -t3:8304 -c3:secroot /dev/nvme0n1
partprobe -s /dev/nvme0n1

# Encrypt
cryptsetup luksFormat --type luks2 \
                      --force-password \
                        /dev/disk/by-partlabel/secroot
cryptsetup open /dev/disk/by-partlabel/secroot root
cryptsetup open --type plain \
                --key-file /dev/urandom \
                /dev/disk/by-partlabel/secswap swap

# Initialize swap
mkswap -L swap /dev/mapper/swap
swapon -L swap

# Format
mkfs.fat -F32 -n EFI /dev/disk/by-partlabel/EFI
mkfs.ext4 -L /dev/mapper/root

# Mount
mount /dev/mapper/root /mnt
mount --mkdir /mnt/boot

# Install
pacstrap -K /mnt base base-devel linux linux-firmware amd-ucode intel-ucode lvm2
genfstab -U /mnt >> /mnt/etc/fstab

In the final version TPM2 will unseal the rootfs.

So only intermediate layer in this is dm-crypt. I like how raw and transparent it will become :-) Given trivial filesystem layering and simple rootfs type (ext4) to begin with I can finally have single unified configuration for both my hosts and vm guests. And maximum transperency for debugging given tons of tools to debug ext4.

#archlinux

@gromit The reason such a huge swap is that I want to be able to test encrypted hibernate on this :-) or have that option w/o reinstall. So the goal is to get TPM2 encrypted boot on ext4, and arch gives me environment to realize that.

@gromit

after some sleep i look into getting UKI on top of this:

❯ cat partition.sh 
#!/usr/bin/env sh

set -e

# Partition
sgdisk -Z /dev/nvme0n1
sgdisk -n1:0:+512M -t1:ef00 -c1:EFI -N2 -t2:8304 -c2:pv0 /dev/nvme0n1
partprobe -s /dev/nvme0n1
cryptsetup luksFormat --type luks2 --force-password /dev/nvme0n1p2
cryptsetup luksOpen /dev/nvme0n1p2 pv0
cryptsetup luksDump /dev/nvme0n1p2
pvcreate /dev/mapper/pv0
vgcreate vg0 /dev/mapper/pv0
lvcreate -L 80G vg0 -n swap
lvcreate -l 100%FREE vg0 -n root

# Format and mounnt
mkfs.ext4 /dev/mapper/vg0-root
mkswap /dev/mapper/vg0-swap
mount /dev/mapper/vg0-root /mnt
swapon /dev/mapper/vg0-swap
mkfs.vfat -F32 /dev/nvme0n1p1
mount --mkdir /dev/nvme0n1p1 /mnt/boot

@ikkeT this whole immutability is overrated imho. get in the context of data center but not in the context of my lab desktop :-)

modern example of https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/

@ikkeT not really, i update to get ext4 back mainly. arch makes sense because it is not a product so no big "drop support". that's exactly why I decided to change the distribution.

@sl Look into "reserved set size".

@sl This another totally misunderstood concept. Only thing that gets reserved is a range of addresses. Memory pages get reserved only when they are accessed.

@gromit I like how clean this will be. Still quite robust (dynamic volumes) but nothing where I would not understand what is going on.

@gromit I.e. along the lines of

nvme0n1                259:0    0 931.5G  0 disk  
├─nvme0n1p1            259:1    0   512M  0 part  
└─nvme0n1p2            259:2    0   931G  0 part  
  └─private            254:0    0   931G  0 crypt 
    ├─private--vg-swap 254:1    0    80G  0 lvm   
    └─private--vg-root 254:2    0   851G  0 lvm   

@gromit It is also for the sake of example interesting.

I've seen mostly either luks1-lvm-ext4 topology with passphrase and luks2-btrfs topolgy.

And I'm going to give a shot on luks2-lvm-ext4, which is something I'm also interested to see if it can work properly.

So it is also "for the benefit of the mandkind" ;-) Not listed here: https://wiki.archlinux.org/title/dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS

Have to give up on archinstall achieve this and make a script.

I've bumped into misconception that swap is useless because computers have so much DRAM.

Not true. It is just kept relatively small (like 2GB and similar figures) because its main job is these days to provide depth in failure tolerance for near OOM situations.

Back in the day it was for "spare slow memory space", which is of course not applicable anymore.

Except: if hibernation is used it obviously need to be larger than the system memory.

it does the job it was meant to in any case

need this for my #btrfs to #ext4 migration 🤷 https://codeberg.org/jarkko/adhoc-backup #git

#codesberg - “Probably the best git hosting in the world”

@moritz and pretty much anything starting from kitchen toasters can read and write ext4, even Windows can. that's a another huge advantage.

like if your machine breaks, maybe there's only a windows laptop available, no problem with ext4 :-) i'd figure there's some shaky btrfs windows drivers out there too but u know... would not put my life on them :-)

that's why I like also fat and its variants... (exfat is ace).

@moritz I think btrfs is great. I just don't need in on my desktop :-)

I know ext4 well enough that I could probably write myself some code to read a partition if I really had to. Or even fix some mainline bugs because I know how it does what it does in great granularity.

Btrfs is like that I need to call helpdesk or something if it ever flipped on me :-) And not that much interest that I would want to climb to a mountain for the sake of btrfs tbh... My ASUSTOR NAS does use btrfs tho.

workaround:

❯ cat user_credentials.json 
{
    "!root-password": null,
    "!users": [
        {
            "!password": "SecretSanta2022",
            "sudo": true,
            "username": "jarkko"
        }
    ],
    "encryption_password": "SecretSanta2022"
}

Now I need to only remember that the password is SecretSanta2022 whenever I use this :-)

would be total pain to automate this or like do large deployments just because the features fight with each other in this area.

you have three passwords here: user, root and hard drive encryption.

why the heck they can't have exact same semantics is beyond me. especially since more privileged (root) has this flexibility but less privileged (user) does not.

and it will be a nightmare to recall their slight differences few months from now...

why not? 🤷luks allows to do that why build imaginary blocks...

turnoff in this that you cannot even by manually editing the json enforce "no password" for the user