Boot the Pre or Post for a Snapper entry?

English Install/Boot/Login
1

I had an incident with a Leap system (15.6 that do not use much - a secondary machine) that occurred on 03/20.

I was removing software I never use - and for whatever reason, “too much” software was removed (core KDE software). I could only boot to XFCE. I ran YasT and miraculously, it suggested installing a lot of those core KDE software (I guess because of missing dependencies).

And it seems to be working okay now … but after I had shutdown after the simple testing back on 03/20, I left the machine alone until today. (yes, three months later).
.
(see screenshot)
So, my thought is, I see a Pre and Post Snapshot on 03/16. Those entries are for boot up, then “zypper up” I did on 03/16, with no issues.

(Then the catastrophe happened on 03/20.)

So I think I might be better off if I boot back to the 03/16 Snapshot, just to be sure.

Should I boot the 03/16 “Pre” or “Post”? I think most would say “Pre”, assuming the 03/16 “zypper up was a bad outcome”. But it was fine. Maybe do the “Pre” just to be sure? (The bad things happened four days later.)

2nd question: after I boot to read-only 03/16 snapshot and if all looks good … what do I execute to make the 03/16 read-only snapshot the current-valid boot choice?
.

snaps
snaps640×484 102 KB

2

You may want to have a read in the snapper documentation:

You need to use a working snapshot. Doesn’t matter if pre, post or single. You need to know and decide which snapshot is working. It can easily be tested by simply booting into them.

Perform a rollback as described in the snapper documentation:
sudo snapper rollback

1 Like
3

not an answer to your question, strictly speaking, as no one here has a clue what your snapshots are. pre could be good, post could be good, pre could be bad, post could be bad, both could be excellent/rubbish.

the point is, you need to start learning how snapshots work and stop relying on the default behaviour. many libraries/programs have snapper plugins and they don’t help. it’s not helpful to have a pre/post yast/zypper snapshot everytime you change one thing or install one package (literally).

you need to be in charge of your system, stop system/auto snapshots and create your own manual snapshots after each event (e.g. system update). this means you will KNOW which snapshot is what.

for example, I only have this at ALL times:

  # │ Type   │ Pre # │ Date                         │ User │ Used Space │ Cleanup │ Description          │ Userdata
────┼────────┼───────┼──────────────────────────────┼──────┼────────────┼─────────┼──────────────────────┼──────────────
 0  │ single │       │                              │ root │            │         │ current              │
13* │ single │       │ Fri 12 Jun 2026 15:05:21 BST │ root │  48.00 KiB │         │ writable copy of #11 │
27  │ single │       │ Sat 27 Jun 2026 22:02:53 BST │ root │  48.00 KiB │         │ baseline             │ important=yes

happy to take questions :slight_smile:

4

Well, about an hour ago, I attempted to do the Rollback, but there is an issue (my luck). Below is the command line output.

So now, a quick drive to grocery store, then back home to research how this might be solved.

myuser@machine:~> sudo snapper rollback -d rollback-0316-271
[sudo] password for root:

Cannot detect ambit since default subvolume is unknown.
This can happen if the system was not set up for rollback.
The ambit can be specified manually using the --ambit option.
myuser@machine:~>
5
6

Well, I spent more time researching a few posts about Snapshot Rollback.

So today, this time I executed with --ambit argument (as most all have recommended):

myuser@machine:~> sudo snapper --ambit classic rollback -d rollback-0316-271
[sudo] password for root:
Ambit is classic.
Creating read-only snapshot of default subvolume.
I0 Error (.snapshots is not a btrfs subvolume).
myuser@machine:~>

So, the “classic” argument didn’t work (bad luck, again).

After that output, I did more research, and found this Reply from @arvidjaar, in a similar thread:

I checked “/etc/default/grub” and it contains:
"SUSE_BTRFS_SNAPSHOT_BOOTING=“true”

… then @arvidjaar’s other comment is:
“You need explicit /.snapshots mount point for the subvolume where snapshots are created”

So, I executed this (yes, /home is on a different drive and is XFS:

myuser@machine:~> cat /etc/fstab
UUID=49b2fffe-xxxx-2b968b63362a /          btrfs defaults 0 0
UUID=49b2fffe-xxxx-2b968b63362a /var       btrfs  subvol=/@/var 0 0
UUID=49b2fffe-xxxx-2b968b63362a /usr/local btrfs subvol=/@/usr/local 0 0
UUID=49b2fffe-xxxx-2b968b63362a /tmp       btrfs subvol=/@/tmp 0 0
UUID=49b2fffe-xxxx-2b968b63362a /srv       btrfs subvol=/@/srv 0 0
UUID=49b2fffe-xxxx-2b968b63362a /root      btrfs subvol=/@/root 0 0
UUID=49b2fffe-xxxx-2b968b63362a /opt       btrfs subvol=/@/opt 0 0
UUID=7d8c9d83-xxxx-3aa231b86b81 /home      xfs   defaults  0 0
UUID=49b2fffe-xxxx-2b968b63362a /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=49b2fffe-xxxx-2b968b63362a /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/1386-pc 0 0
UUID=764E-1886                            /boot/efi  vfat  utf8 0 2
UUID=d63f1cad-c198-42de-86e5-69a68a6b304d swap       swap  defaults 0 0
myuser@machine:~>

.
How strange - there is no “/.snapshots” entry, such as:

"UUID=xxxxxxx  /.snapshots  btrfs  subvol=/@/.snapshots 0 0"

.
However (confused on this), I am able to select a Snapshot from the GRUB menu today, and boot into it. (you can see the screenshot of the Snapshot list in my 1st post).

And yes, the [older, #271] Snapshot I just booted into is from that day (03/16).

So, a question … is there a way to create the:
“UUID=xxxxxxx /.snapshots btrfs subvol=/@/.snapshots 0 0”
… entry that I am missing, based on the Snapper list ??

Or maybe another way to Rollback??
(maybe “snapper -v undochange” ??)

7

What does sudo btrfs subvolume list / show?

Output should be something like this:

ID 256 gen 217912 top level 5 path @
ID 257 gen 415468 top level 256 path @/var
ID 258 gen 415419 top level 256 path @/usr/local
ID 259 gen 415180 top level 256 path @/srv
ID 260 gen 415390 top level 256 path @/root
ID 261 gen 415407 top level 256 path @/opt
ID 262 gen 413846 top level 256 path @/boot/grub2/x86_64-efi
ID 263 gen 406950 top level 256 path @/boot/grub2/i386-pc
ID 264 gen 415431 top level 256 path @/.snapshots

If there is a .snapshots subvolume, you should be able to manually add it to /etc/fstab:

UUID=7cd73905-d069-4894-b424-aa2598c4a009 /.snapshots btrfs subvol=/@/.snapshots 0 0

8

Thanks for the Reply @mendres82 …

I had just gone to that desktop machine and did an “ls” and then minutes later read your request :slight_smile: To save time, I simply took a photo of your request.

But first, here’s my “ls” output (and confused why it shows zero entries for “/.snapshots”):

machine:~ # ls -al /
total 0
drwxr-xr-x 1 root root 156 Nov 11  2024 .
drwxr-xr-x 1 root root 156 Nov 11  2024 ..
drwxr-xr-x 1 root root   0 Jun 29 15:46 .snapshots
drwxr-xr-x 1 root root 1736 Mar 4 09:39 bin
drwxr-xr-x 1 root root 2380 Mar 4 09:34 boot
...

machine:~ # ls -al /.snapshots/
total
drwxr-xr-x 1 root root   0 Jun 29 15:46
drwxr-xr-x 1 root root 156 Nov 11  2024
machine:~ #

.
And your request as a photo (sorry) … interesting it shows a “snapshot list”: … ( I marked “271” as the snapshot I want to rever to.)

req
req657×803 136 KB

9

If I am booted into a read-only Snapshot, can I really manually add the “.snapshots” subvol to “/etc/fstab”??
.

In my previous Reply, I included a photo of command output (requested by @mendres82 ).
Here’s the proper text output:

# btrfs subvolume list /
ID 256 gen 45628 top level 5 path @
ID 257 gen 48918 top level 256 path @/var
ID 258 gen 48501 top level 256 path @/usr/local
ID 259 gen 48900 top level 256 path @/tmp
ID 260 gen 30384 top level 256 path @/srv
ID 261 gen 48918 top level 256 path @/root
ID 262 gen 45664 top level 256 path @/opt
ID 263 gen 28652 top level 256 path @/boot/grub2/x86_64-efi
ID 264 gen 28652 top level 256 path @/boot/grub2/i386-pc
ID 265 gen 45085 top level 256 path @/.snapshots
ID 266 gen 15242 top level 265 path @/.snapshots/1/snapshot
ID 267 gen 15242 top level 265 path @/.snapshots/2/snapshot
ID 489 gen 44087 top level 265 path @/.snapshots/224/snapshot
ID 494 gen 44087 top level 265 path @/.snapshots/229/snapshot
ID 524 gen 44087 top level 265 path @/.snapshots/259/snapshot
ID 525 gen 44087 top level 265 path @/.snapshots/260/snapshot
ID 526 gen 44087 top level 265 path @/.snapshots/261/snapshot
ID 527 gen 44087 top level 265 path @/.snapshots/262/snapshot
ID 528 gen 44087 top level 265 path @/.snapshots/263/snapshot
ID 529 gen 44087 top level 265 path @/.snapshots/264/snapshot
ID 530 gen 44087 top level 265 path @/.snapshots/265/snapshot
ID 531 gen 44087 top level 265 path @/.snapshots/266/snapshot
ID 532 gen 44087 top level 265 path @/.snapshots/267/snapshot
ID 535 gen 44087 top level 265 path @/.snapshots/270/snapshot

... hoping to revert to "271"
ID 536 gen 44087 top level 265 path @/.snapshots/271/snapshot

ID 539 gen 44087 top level 265 path @/.snapshots/274/snapshot
ID 540 gen 44087 top level 265 path @/.snapshots/275/snapshot
ID 541 gen 44087 top level 265 path @/.snapshots/276/snapshot
ID 542 gen 44087 top level 265 path @/.snapshots/277/snapshot
ID 543 gen 44087 top level 265 path @/.snapshots/278/snapshot
ID 544 gen 44087 top level 265 path @/.snapshots/279/snapshot
ID 545 gen 44087 top level 265 path @/.snapshots/280/snapshot
ID 546 gen 44087 top level 265 path @/.snapshots/281/snapshot
ID 547 gen 44087 top level 265 path @/.snapshots/282/snapshot
ID 548 gen 44087 top level 265 path @/.snapshots/283/snapshot
#

I was curious what “mount” would show.
The first line shows evidence I’m booted into Snapshot 271

# mount
/dev/nvme1n1p2 on / type btrfs (rw,relatime,ssd,discard=async,space_cache=v2,subvolid=536,subvol=/@/.snapshots/271/snapshot)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=4096k,nr_inodes=8208720,mode=755,inode64)
tmpfs    on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
[...more mount entries]
#

And an “ls -al” output (if helpful):

# ls -al /
total 0
drwxr-xr-x   1 root root   156 Nov 11  2024 .
drwxr-xr-x   1 root root   156 Nov 11  2024 ..
drwxr-xr-x   1 root root     0 Jun 29 19:31 .snapshots
drwxr-xr-x   1 root root  1736 Mar  4 09:39 bin
drwxr-xr-x   1 root root  2380 Mar  4 09:34 boot
drwxr-xr-x  20 root root  4500 Jun 29 19:31 dev
drwxr-xr-x   1 root root  5230 Mar 16 18:30 etc
drwxr-xr-x   7 root root    83 Oct 20  2024 home
drwxr-xr-x   1 root root   106 Oct 13  2024 lib
drwxr-xr-x   1 root root  2222 Mar 16 18:29 lib64
drwxr-xr-x   1 root root    24 Aug 26  2024 mnt
drwxr-xr-x   1 root root    30 Apr 13  2024 opt
dr-xr-xr-x 399 root root     0 Jun 28 09:26 proc
drwx------   1 root root   242 Jun 29 19:31 root
drwxr-xr-x  43 root root  1100 Jun 28 09:26 run
drwxr-xr-x   1 root root  3788 Mar 16 18:29 sbin
drwxr-xr-x   1 root root     0 Mar 15  2022 selinux
drwxr-xr-x   1 root root    22 Sep  9  2025 srv
dr-xr-xr-x  13 root root     0 Jun 28 09:26 sys
drwxrwxrwt   1 root root 28984 Jun 29 19:30 tmp
drwxr-xr-x   1 root root   124 Apr 12  2024 usr
drwxr-xr-x   1 root root   110 Jan 27 18:07 var
#