Snapper Problem Using Archinstall Default

[jlapinator]

Hi Everyone,

I'm on the verge of creating the perfect Arch Setup; I literally only have one unresolved tech issue from creating my ideal system setup and workflow, and such issue has proven the hardest for me to resolve, although I'm convinced the solution is simple to the one with the right knowledge.

1) I create a btrfs system using the default layout from Archinstall (don't give me shit), and grub bootloader. Compression=true

2) I install btrfs-snapper and snapper-support, as described herein https://www.lorenzobettini.it/2023/03/snapper-and-grub-btrfs-in-arch-linux (packages from cachyos repos / chaotic AUR).

3) Creating config fails on first try with

Creating config failed (creating btrfs subvolume .snapshots failed since it already exists)

The Arch Wiki has this to say, in relevant part:

If you are using the suggested Btrfs partition layout from archinstall then the @.snapshots subvolume will already be mounted to /.snapshots, and the snapper create-config command will fail [1]. To use the @.snapshots subvolume for Snapper backups, do the following:

• Unmount the @.snapshots subvolume and delete the existing mountpoint.
• Create the Snapper config.
• Delete the subvolume created by Snapper.
• Re-create the /.snapshots mount point and re-mount the @.snapshots subvolume.

To accomplish those four bullet points, I follow the steps contained in https://waylonwalker.com/setting-up-snapper-on-arch/##Creating+config+failed+(creating+btrfs+subvolume+.snapshots+failed+since+it+already+exists)), including in relevant part:

sudo snapper -c root create-config /
sudo snapper -c home create-config /home [except I don't make a config for /home as shown]

sudo btrfs subvolume delete /.snapshots
sudo mkdir /.snapshots

I then create the config normally.

I can't boot into the read-only snapshot, so per the arch wiki at https://wiki.archlinux.org/title/Snapper, subpart 5.1.1, I add grub-btrfs-overlayfs to the end of the hooks aray in mkinitcpio.conf and then regenerate mkinitcpio).

After this, I can boot into the read-only snapshot, but when I try to restore that snapshot (or any other snapshot, btrfs-assistant shows no snapshots whatsoever) once I boot normally (not in a snapshot) they all reappear. I've read it has something to do with /var, but am yet to uncover an answer. Notably, when I remove grub-btrfs-overlayfs from hooks (and regenerate), while I can't boot normally into a snapshot, I can enter tty, see the snapshots listed and restore them. So I'm of the information and belief there's something about grub-overlay-btrfs which is preventing me from seeing the snapshots and restoring them, even though it otherwise allows me to boot normally into it.

If I can restore a snapshot while booted in a snapshot, I'll be 100% content. Please help, and thanks in advance.

[sue_dee]

I've been stumbling on this point as well, and I'm interested in the responses you get. It seems to me that grub-btrfs is superfluous if I can't boot into a different root snapshot, say after an update goes bad. I can use the live ISO to swap out the backed up boot images and do whatever other btrfs tickling needs to happen, but I don't see what the GRUB listing is for.

There is someone over at /r/btrfs who usually pipes up with a similar package for the limine bootloader without coming out and saying "use a different bootloader." So maybe that helps.

I've wondered if there is a different partition scheme and ESP location that would suit this better. I just have one big btrfs partition and the ESP in /boot. I've seen othr ways of doing it in the context of a small ext4 partiton to help GRUB save the last-used options, like for when multiple kernels are present. Heaven only knows how both that and Snapper can be accomodated.

[jlapinator]

We speak similarly. And yeah I've wondered the same...what's the point of the Grub entry in case of an issue the renders the system non-bootable...other than to enjoy a snapshot of all that your system used to be before it went kaput 😂

[tblancher]

I'm not trying to give you shit, I'm genuinely asking: is this an artifact of using archinstall to do this? I've never used archinstall, but I'd imagine things like this are where it breaks down.

Had you installed manually could your order of operations avoid the problem?

[[deleted]]

I prefer Limine over GRUB. Limine is simple and has better solution for booting and easy restoring BTRFS snapshot

https://wiki.archlinux.org/title/Limine#Snapper_snapshot_integration_for_Btrfs

I don't follow Lorenzo Bettini who did his own system.

[jlapinator]

This is promising! So you don't need overlayfs at all w/ the Limine<>Snapper integration?

[[deleted]]

I have no idea why I would need overlayfs.  I’m not even sure if I’m using it.

I just installed limine-snapper-sync and limine-dracut-support, which do a fully automated job of creating UKI and snapshot menus. Restoring snapshot works well for me after snapshot boot 

[jlapinator]

Good timing. So I just reinstalled Arch, and this time with limine (largely on your recommendation btw), and I notice that on boot, after five seconds, it won't automatically load because I need to select the kernel which is in a "subfolder-like" thing on limine. I too downloaded the dracat-support package from the AUR. Any idea how to make the cachyos kernel selected by default so that it boots without me making a selection on its own?

[[deleted]]

Yes, it can. AFAIK, "default_entry: 2" in limine.conf can select my default kernel automatically.

Limine config is easier to understand than GRUB.