Introduction

This is my fork of easy-arch, a script made in order to boostrap a basic Arch Linux environment with snapshots and encryption by using a fully automated process.

This fork comes with various security improvements and fully working rollbacks with snapper. I do submit some of the changes here back to upstream as well.

How does it work?

1. Download an Arch Linux ISO from here
2. Flash the ISO onto an USB Flash Drive.
3. Boot the live environment.
4. Connect to the internet.
5. git clone https://github.com/tommytran732/Arch-Setup-Script/
6. cd Arch-Setup-Script
7. chmod u+x ./install.sh && ./install.sh
8. do arch-chroot /mnt and create your wheel user once the script is done. Remember to give the wheel group priviledges in visudo.

Snapper behavior

The partition layout I use rallows us to replicate the behavior found in openSUSE 🦎

1. Snapper rollback works! You will no longer need to manually rollback from a live USB like you would with the @ and @home layout suggested in the Arch Wiki.
2. You can boot into a readonly snapshot! GDM and other services will start normally so you can get in and verify that everything works before rolling back.
3. Automatic snapshots on pacman install/update operations
4. /boot/grub and /boot/efi are 2 seperate subvolumes which will not be rolled back with snapper. The kernel and initramfs are part of the snapshot.
5. For consistency with pacman's database, I deviate from SUSE's partition layout leave /usr/local/ and /opt as part of the snapshot. When you rollback, everything in those 2 directories rollback as well.

Changes to the original project

1. Enabled AppArmor
2. SUSE - like partition layout
3. Snapper snapshots & rollback
4. Default umask to 077
5. Firewalld is enabled by default
6. Minimally setup GNOME 40

Why a bunch of @var_xxx subvolumes?

Most of these subvolumes come from SUSE's partition layout prior to 2018, before they simply made @var its own subvolume. We cannot blindly do this however, since pacman stores its database in /var/lib/pacman/local, which needs to be excluded and rolled back accordingly to the rest of the system.

Other than that, /var/lib/gdm and /var/lib/AccountsService must have their own read-write subvolume in order to boot GNOME from a read only snapshot.

Why GNOME?

I only use GNOME and I know that I have to explicitly create a seperate a subvolume for /var/lib/gdm, /var/cache, /var/tpm and so on for a full desktop to boot from a read-only snapshot. I don't know how other desktop environments behave and which directories we need to create a seperate subvolume for. We will also change the partitioning scheme according to the DE selection as well, since it doesn't make any sense to create @var_lib_gdm on a KDE system. Any help with adding more DE options would be appreciated.

Partitions layout

Partition Number	Label	Size	Mountpoint	Filesystem
1	ESP	100 MiB	/boot/efi	FAT32
2	cryptroot	Rest of the disk	/	Encrypted BTRFS (LUKS1)

The partitions layout is pretty straightforward, it's inspired by this section of the Arch Wiki. As you can see there's just a couple of partitions:

1. A FAT32, 100MiB sized, mounted at /boot/efi for the ESP.
2. A LUKS encrypted container, which takes the rest of the disk space, mounted at / for the rootfs.
3. /boot is encrypted.

To do

1. Automate wheel user setup
2. Install yay and setup plymouth, hardened_malloc, opensnitch, zram-generator
3. Reduce the number of password prompts
4. Automatic secure boot setup with your own keys (no, we are not using shim).
5. Randomize MAC address
6. Optional Nvidia driver installation