Snapshot not restored despite success message about snapper-rollback HOT 5 CLOSED

Thanks for your help. So from these checks I figured out it was an issue with the grub config booting from @rootfs instead of @, despite @ being the default subvolume.

It worked fine after changing the config to subvol_main = @rootfs.

from snapper-rollback.

Got it, so in that case, this sounds like different conventions across linux distros: @ for archlinux, @rootfs for Debian. Next week, I'll update the repo readme so that it flags this potential discrepancy.

from snapper-rollback.

Hmm, I see nothing here looks wrong to my non-expert eyes. but let's try to narrow down the issue:

• this one is obvious but let's check just in case. Your / and /home are btrfs, but /var and /tmp are ext4. / will roll back, but I'm assuming you're aware that /var and /tmp won't, right? Just double-checking.

• what's the UUID for /dev/nvme0n1p2? It should be the same as your root partition. ls -l /dev/disk/by-uuid

• you opened a PR that suggests you ran into a BTRFS issue (thanks for contributing back btw!). This makes me wonder whether your system is currently in a consistent state. Did you record the exception, and if so what does it say? What's the current default btrfs subvolume?

• let's rule out that this is grub booting into the wrong subvolume. When you try to boot into the system after running snapper-rollback, what menuentry are you selecting from grub? How is that menuentry configured? (Most likely under /boot/grub/grub.cfg)

• The script has a --dry-run mode which will output a few shell commands. If you run the commands directly, are there any errors anywhere?

from snapper-rollback.

Thanks for reporting back with the resolution.

Ideally, this situation wouldn't happen at all to begin with - can I ask how are you generating your grub.cfg? I'm thinking that we should take steps to avoid the next person running into the same issue -> I'm kind of surprised grub is trying to boot from @rootfs (where did that come from?), but if re-running update-grub doesn't generate the correct menuentry, it might be worth checking with the grub people whether it'd make sense to add that kind of auto-detection.

from snapper-rollback.

I am not familiar with how grub works in this context. @rootfs is what the debian installer creates when formatting a btrfs partition that is set as /, whereas @ is what I had created manually through btrfs commands while trying to follow the arch wiki.

The grub.cfg that I had was also the default that's auto-generated by debian. update-grub doesn't change it to point to @ instead of @rootfs if I manually play with btrfs subvol and set it as default.

from snapper-rollback.