Follow opensuse's btrfs subvolumes layout

[pm4rcin]

Hi,
I think we should adopt suse's layout for subvolumes. In my opinion they have sensible arguments. One thing to note is that we don't have to create subvolume for /tmp since it's by default tmpfs. I don't know what about /boot, maybe you have an idea? Source

[classy-giraffe]

Yes we can add more subvolumes but if I move /boot (which atm is a fat32 partition) into a @boot btrfs subvolume it'd get encrypted and that wouldn't allow us to use LUKS2 (which means defaulting to LUKS1 and decrypting two times the system at boottime, with the first time being slow since we're not in userspace yet and the bootloader can't use all the CPU decryption algorithms). So TLDR, i can add /root, /opt etc... but not /boot unless we move to LUKS1...

[pm4rcin]

I think we shouldn't add /boot subvolume in our case. I forgot that suse encrypts the entire drive including /boot so it's different story. So let's create subvolumes with suse style just without /tmp and /boot. I'll also try to test the snapper-systemd-boot tomorrow and if it'll work I'll probably ask someone to package it on aur.

[paolomainardi]

It seems that grub can boot from a luks2 encrypted partition: https://keyb0ardninja.github.io/BTRFS.html#luks2-setup

[classy-giraffe]

Oh well it indeed can, the problem is that the early decryption (the one that happens to unlock grub first) will be very slow as there's no way to use CPU acceleration for the decryption algorithms. And btw if /boot/ is on a LUKS2 partition that will not work, you can encrypt /boot but it has to be inside a LUKS1 container.

[paolomainardi]

Not having the /boot directory as an integral part of the snapshot, makes the restore quite useless, in case of a kernel upgrade. That’s why I think it is quite important to address this.

Let me say that this project is very cool and the bash script clean and elegant.

[classy-giraffe]

@paolomainardi So you're suggesting to move the ESP to /efi and encrypt /boot right (that's a consequence of moving /boot to its own subvolume). I can try btw.

[DrymarchonShaun]

I think what they are requesting is that you switch to something more like what https://github.com/tommytran732/Arch-Setup-Script uses, albeit /var/ being that separate probably isn't totally necessary. AFAIK this is what SUSE uses, the main advantage being that you can actually run snapper rollback after booting any read only snapshot within grub, and it automatically saves a read only snapshot of your current (broken) system, and then creates a read/write copy of the snapshot you booted into from grub, and sets it as the default root partition. The fork I linked is currently non-functional, but I just forked it and got it working enough to create a bootable system, with snapper rollback functioning. (That being located Here)

[pm4rcin]

When we talk about the /var subvolumes there's just 1 folder in arch that makes it impossible (or painless at least) to create just one subvolume for that directory. It's the /var/lib/pacman/local which has to be there since it has information about every installed package so in case of rollback pacman could throw errors. But for arch we could create a few subvolumes for var like suse did before Jan 2018 and eventually add more later. What do you guys think? @ShaunTheQuietGamer yes it was all about snapper rollback support.

[pm4rcin]

I have found a solution to not create so many subvolumes in /var. We can create one subvolume for /var and backup pacman database for example via pacman hook. @classy-giraffe what do you think?

[TommyTran732]

I think what they are requesting is that you switch to something more like what https://github.com/tommytran732/Arch-Setup-Script uses, albeit /var/ being that separate probably isn't totally necessary. AFAIK this is what SUSE uses, the main advantage being that you can actually run snapper rollback after booting any read only snapshot within grub, and it automatically saves a read only snapshot of your current (broken) system, and then creates a read/write copy of the snapshot you booted into from grub, and sets it as the default root partition. The fork I linked is currently non-functional, but I just forked it and got it working enough to create a bootable system, with snapper rollback functioning. (That being located Here)

It is needed. The main reason being, you would either not want those subvols rolled back or if you make them part of the immutable system, the system wont boot from grub-btrfs. On the other hand, pacman stores their database in /var, so you can't just make 1 single subvol for /var, because the database will be out of sync with what's actually on the system after a rollback.

[classy-giraffe]

Still not sure about switching to LUKS1 in favor of this setup. I'm more than welcome to change layout when booting i can encrypt the entire system with LUKS2.

[pm4rcin]

@TommyTran732 what do you think about changing DBPath in /etc/pacman.conf? This way pacman database could be moved to another location outside of /var which would allow for one @var subvolume.

[classy-giraffe]

I need to check if that has some sort of side effects. If it doesn't we can do that. On a side note, does the script work now? Cause I've had people complaining it didn't work.

[TommyTran732]

@TommyTran732 what do you think about changing DBPath in /etc/pacman.conf? This way pacman database could be moved to another location outside of /var which would allow for one @var subvolume.

The way I think about it, if the user wanna split a subvol out, they can do it themselves. I am not sure splitting the entire @var out is the best idea, cuz lets say if I do a system rollback I do want my system flatpaks to also rollback.

openSUSE splits out @opt and it gets weird with apps relying on it, so idk. I didn't split it out from my script.

@classy-giraffe I just came back to Arch 2 days ago so I fixed up a bunch of stuff. The script should work now.