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

[phoronix]

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

Over the past year and a half of being on the Arch Linux install media, archinstall has made it dramatically quicker and easier to get this popular Linux distribution installed. Out today is Archinstall 2.5.1 with a number of fixes and other changes for this easy-to-use Arch Linux installer...

https://www.phoronix.com/news/Archinstall-2.5.1-Released

[middy]

• Added an option for parallel downloads (which is not visible by default, and the reasoning is mentioned in the comments #1397 (comment)) #1397
• So I cleaned up this a bit, using with open() instead of fh = open().
  I also hid the option behind --advanced, and it's not because it's advanced in any way.. The functionality is pretty straight forward. But it would put quite a bit of extra strain on the mirrors, something I'm not sure upstream is to happy about.
  
  The functionality is there, we can enable it.. and we'll have to come back and discuss how much of an impact this would have on overall mirrors if we made it "available"

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?

[Slithery]

Thanks Torxed. Your work is always appreciated.

[elatllat]

Wake me when the installer adds yay.

[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

[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]

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]

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]

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?

[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)