Archinstall 2.5.1 Released With A Number Of Fixes For The Arch Linux Installer

[elatllat]

...

The only issues I have with a stratis like stack is lvm snapshots are ugly and integritysetup was slow to format.
But there is lvmcache which mdadm and btrfs do not have.
I think big implementations do custom things like backblaze or use distributed systems like ceph.
After ~15 years of LVM RAID use I moved 1 production array to btrfs RAID, as CoW is not really ideal for databases.

[integritysetup/]cryptsetup/lvm is commonly used as there is no performance penalty, no practical use case for per LV crypo, and per LV integrity make no sense.

[Anux]

lvm can do mdadm things so using both is ugly.

Those sneaky bastards implemented raid an told no one? In that case LVM would also be left outside the LUKS container to not encode parity. You might need a second LVM inside LUKS for partioning or have multiple LUKS devices.

Do you have any experience with LVM Raid? Changing discs, repairing, rebuilding? Is there a big player out there using it?

[Anux]

I don't think manufacturers need to do anything. The EFI binary could be arch developed (as an example), and as long as it has support for the DMCrypt logic (unlocking and dealing with everything) I suppose it could load the initramfs from the encrypted volume. But the limiting factor might be the actual size of the EFI storage on the motherboard if the encryption logic gets too big.

Cool, I guess I'm not so firm with UEFIs inner workings.

I have no idea how the memory handling of the EFI binaries are done tho, so there might be some limiting factors here making it impossible. As I suspect it can't utilize the full RAM at this stage.

And for Argon2 it would need quite a lot, I typically use 6GB as that is my lowest anchor of all systems (actually 8GB but there needs to be a safety margin).

LVM still happens inside. But I've seen people do LVM outside and encryption inside too, but I doubt that this is something a majority of people do?

For maximum security you would want to have everything inside the LUKS container, as soon as you start to put layers outside the posibillity of information leaking out start to arise. For example LVM -> LUKS might leak when and where data was edited and give you clues about the encrypted system. That also holds true for mdadm/Raid. Still one would have to leverage a securtiy hole in the encryption algorithm and write a attack script. But if you know the position of a known file than you can break atleast AES, see March 2016: https://en.wikipedia.org/wiki/Advanc...#Known_attacks I'm not sure if Argon2 helps against this.

All this needs regular inspection of the disk from someone with physical access, that isn't a usable vulnerability in my case, they could hit me with a wrech or install a keylogger while I'm not at home.

[elatllat]

lvm can do mdadm things so using both is ugly.
luks/integrity/lvm/(xfs|ext4) or luks/btrfs or zfs are the ways I use encryption.

My custom pools aside here is how popular installers offer encryption:

Ubuntu> lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 477G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
├─nvme0n1p2 259:2 0 732M 0 part /boot
└─nvme0n1p3 259:3 0 475.7G 0 part
└─nvme0n1p3_crypt 253:0 0 475.7G 0 crypt
├─vgubuntu-root 253:1 0 474.8G 0 lvm /
└─vgubuntu-swap_1 253:2 0 980M 0 lvm [SWAP]

Ubuntu> mount | grep " / "
/dev/mapper/vgubuntu-root on / type ext4 (rw,relatime,errors=remount-ro)

.

EndeavourOS> lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sr0 11:0 1 1024M 0 rom
vda 254:0 0 20G 0 disk
└─vda1 254:1 0 20G 0 part
└─luks-bf6c171c-7e09-4859-ac1b-ff90547327c6 253:0 0 20G 0 crypt /var/cache
/var/log
/home
/

EndeavourOS> mount | grep " / "
/dev/mapper/luks-bf6c171c-7e09-4859-ac1b-ff90547327c6 on / type btrfs (rw,noatime,compress=zstd:3,space_cache=v2,subvoli d=256,subvol=/@)

.

Fedora> lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sr0 11:0 1 1024M 0 rom
zram0 251:0 0 2.8G 0 disk [SWAP]
vda 252:0 0 120G 0 disk
├─vda1 252:1 0 1G 0 part /boot
└─vda2 252:2 0 119G 0 part
└─luks-17bf416e-0cb3-4b7f-8c6d-dc5220b03ac9 253:0 0 119G 0 crypt /home
/

Fedora> mount | grep " / "
/dev/mapper/luks-17bf416e-0cb3-4b7f-8c6d-dc5220b03ac9 on / type btrfs (rw,relatime,seclabel,compress=zstd:1,space_cache, subvolid=258,subvol=/root)

Trying to get luks/btrfs with the Debian installer was so painful I gave up and settled for the ugly luks/lvm/btrfs .

Debian> lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
vda 254:0 0 20G 0 disk
├─vda1 254:1 0 487M 0 part /boot
├─vda2 254:2 0 1K 0 part
└─vda5 254:5 0 19.5G 0 part
└─vda5_crypt 253:0 0 19.5G 0 crypt
├─Debian--vg-root 253:1 0 18.5G 0 lvm /
└─Debian--vg-swap_1 253:2 0 976M 0 lvm [SWAP]

Debian> mount | grep " / "
/dev/mapper/Debian--vg-root on / type btrfs (rw,relatime,space_cache,subvolid=256,subvol=/@rootfs)

[Torxed]

But motherboard manufacturers would need to support luks I think?

I don't think manufacturers need to do anything. The EFI binary could be arch developed (as an example), and as long as it has support for the DMCrypt logic (unlocking and dealing with everything) I suppose it could load the initramfs from the encrypted volume. But the limiting factor might be the actual size of the EFI storage on the motherboard if the encryption logic gets too big.

I have no idea how the memory handling of the EFI binaries are done tho, so there might be some limiting factors here making it impossible. As I suspect it can't utilize the full RAM at this stage.

With soft raid the encryption should happen on the raid device not under

raid
/boot
LUKS
LVM
/
...

True, that is if they use RAID.
LVM still happens inside. But I've seen people do LVM outside and encryption inside too, but I doubt that this is something a majority of people do?

[Anux]

Full disk encryption would for us require that we pick and employ a strategy:
* Should we place `/boot` on a separate block device (USB device)?
* Should we only offer it for GRUB on legacy BIOS boot and hide it in MBR otherwise?
* Should we implement LVM/RAID inside one big DMCrypt device and do partitioning in there? (We'd still need to deal with the two above)

Sorry I was not precise, I'm happy with unencrypted /boot for the time being. All fully encrypted solutions I can think of require the use of closed source hardware that I don't trust.
If the EFISTUB unlocking doesn't lock me out from encrypting with non UEFI devices than it would be an ok solution. But motherboard manufacturers would need to support luks I think?

With soft raid the encryption should happen on the raid device not under, because under the raid you have more writes (parity) and therefore slower performance/more CPU usage, also changing the defect drives would be a pain. I used to run it under the raid in the early days due to having more threads but with modern hardware acceleration that is not needed any more. One exception might be raid 0.

The typical layout I use is:

raid
    /boot
    LUKS
        LVM
            /
           ...

[Torxed]

I still haven't used the install script. Is it now possible to use full disc encryption with LUKS and configure details like Argon2id?

Short answer: yes!

----

Long answer full of opinions and risk of loosing cred:

We do offer tweaking iteration times and most of the parameters. Argon2id being the only hardcoded parameter: https://github.com/archlinux/archins...ks.py#L91-L103

And regarding encryption, so the only way you can achieve "full disk encryption" is if you omit the `/boot` partition and hide it some where. Which we don't support at the moment. it's going to be a method of dealing with the boot partition separately and call it "full disk encryption" because it's as close to "full" you're going to get. Because I don't know of a way to unlock a DMCrypt device using EFI binaries for instance.

Full disk encryption would for us require that we pick and employ a strategy:
* Should we place `/boot` on a separate block device (USB device)?
* Should we only offer it for GRUB on legacy BIOS boot and hide it in MBR otherwise?
* Should we implement LVM/RAID inside one big DMCrypt device and do partitioning in there? (We'd still need to deal with the two above)

The LVM approach is something that is still on the TODO list so that will happen regardless I believe. Because people want that for the flexibility if nothing else.
But what we are currently doing is not so far off from what you're probably asking for - which is to encrypt your partitions. The main difference being that you can see how many partitions you have with the current encryption strategy (shouldn't impact the data protection in any negative way either way).

I'd love to discuss this more tho because what we've implemented is literally just the way me and a friend of mine used to encrypt our stuff, it's far from what everyone else is doing so bouncing benefits and downsides is a key to success before we start implementing!

When EFISTUB can handle unlocking encrypted volumes, I'd be happy to ditch the unencrypted /boot when people choose EFISTUB as their bootloader.
Or in case of netbooting having a unencrypted /boot makes no sense either.

[Anux]

I still haven't used the install script. Is it now possible to use full disc encryption with LUKS and configure details like Argon2id?

[Torxed]

Thanks Torxed. Your work is always appreciated.

Thank you! And thank you to everyone contributing! Been a rough couple of months so the added help have been awesome to have!

Wake me when the installer adds yay.

What if I told you.. `archinstall --plugin https://archlinux.life/aur.py`
I get what you mean tho, and I wish the same thing. But the support staff is very clear on this. If we want the darn thing to be supported there cannot be any AUR.

if you don't know if the mirrors can handle the stress, then why did arch add the option to begin with in pacman? shouldn't it have been added after it was deemed safe for mirror loads? nevertheless, i've been using the parallel option since arch released it but i find it odd that the hesitation for the arch developers in setting it as default is because they don't know if the mirrors can handle the stress?

Some of them wouldn't even notice probably. Others would.
But it's one thing to enable it one by one like you did because you want that additional speed.
And another thing to enable it for every single person. Mirror wise you're less likely to hit any rate limiting put in to place as well so the safe bet is always one download per user.

That said, there is `archinstall --advanced` which will prompt you for parallel downloads

[elatllat]

Wake me when the installer adds yay.