Boot from latest snapshot after snapper rollback

English Install/Boot/Login
1

My Tumbleweed system locked up in the middle of a zypper dup, forcing me to power cycle the machine. This broke Very Many Things™; fortunately I was still able to log in as root in the text-mode console. After reading the man page for snapper I figured the right thing to do was a zypper rollback to the previous snapshot and reboot. This seemed to work; everything was restored to the way it was before the accident, and I was able to run zypper dup all over again (this time successfully). However, even though the zypper and YaST package managers end up creating new snapshots, subsequent reboots always take me back to the snapshot I originally rolled back to. Trying to snapper mount a more recent snapshot doesn’t seem to have any obvious effect; using snapper rollback to a more recent snapshot does seem to work, but the choice of snapshot again seems to persist for every boot.

Below is the current output of snapper list on my system. You can see the two rollbacks (#106 and #117), that a lot of new snapshots have subsequently been created (by zypper or YaST), and that the system is planning to use the old snapshot #117 on the next reboot rather than the latest #123.


   # | Type   | Pre # | Date                     | User | Cleanup | Description             | Userdata     
-----+--------+-------+--------------------------+------+---------+-------------------------+--------------
  0  | single |       |                          | root |         | current                 |              
106  | single |       | 2019-06-02T10:48:03 CEST | root | number  | rollback backup of #97  | important=yes
112  | pre    |       | 2019-06-07T18:51:47 CEST | root | number  | yast sw_single          |              
113  | pre    |       | 2019-06-07T18:53:21 CEST | root | number  | zypp(ruby.ruby2.6)      | important=yes
114  | post   |   113 | 2019-06-07T18:55:29 CEST | root | number  |                         | important=yes
115  | post   |   112 | 2019-06-07T18:55:38 CEST | root | number  |                         |              
116  | single |       | 2019-06-07T19:05:58 CEST | root | number  | rollback backup of #107 | important=yes
117* | single |       | 2019-06-07T19:05:58 CEST | root |         |                         |              
118  | pre    |       | 2019-06-15T17:06:32 CEST | root | number  | yast sw_single          |              
119  | post   |   118 | 2019-06-15T17:28:32 CEST | root | number  |                         |              
120  | pre    |       | 2019-06-15T17:35:14 CEST | root | number  | zypp(zypper)            | important=no 
121  | post   |   120 | 2019-06-15T17:35:16 CEST | root | number  |                         | important=no 
122  | pre    |       | 2019-06-16T18:03:18 CEST | root | number  | zypp(zypper)            | important=no 
123  | post   |   122 | 2019-06-16T18:03:20 CEST | root | number  |                         | important=no

So my two questions:

  1. How can I get my system behaving the way it used to, where zypper up and zypper dup not only create new snapshots, but also set my system to boot from the latest such snapshot?
  2. What, if anything, did I do wrong that got me in this mess to begin with, so that I don’t repeat it next time?
2

Was it while updating “btrfsmaintenance”?

I ask, because that seems a common problem and there are open bug reports on it.

3

I don’t think so. The only obvious problem was that zypper reported running out of disk space while installing a package (which also happens to be a very common and much remarked-upon problem). Normally this is annoying but not catastrophic; I just free up some space in the root partition and tell zypper to retry. But in this case I must have been running some other processes that did not cope will with the lack of space. They must have started thrashing, bringing the entire system to a standstill.

4

Yes, running out of disk space is a problem – and a common one.

5

You are mistaken. Snapshots exist only as backup. One of those snapshots is your actual root and it never changes. All changes are applied by zypper to your actual root filesystem. After initial installation it is snapshot #1 simply because it is the very first and only one. When you perform rollback, some other snapshot is promoted as your root and remains root from now on.

6

Did you just contradict yourself? How can snapshots exist “only as backup” if one of them is the live filesystem? How can changes be applied to the root if the root never changes? Or did you mean that the designation of a particular snapshot as the root filesystem never changes?

After initial installation it is snapshot #1 simply because it is the very first and only one. When you perform rollback, some other snapshot is promoted as your root and remains root from now on.
How do I know which snapshot is the root filesystem? According to the Display of special snapshots article on the Snapper website, snapper list marks the currently mounted snapshot with a -, the snapshot that will be mounted on the next boot with a +, and if these two happen to be the same snapshot, it is marked with a *. Is the “actual root filesystem” just whichever snapshot happens to mounted?

7

Yes, that’s correct. Non-native language multiplied by the whole day of intensive training conducted in another non-native language … you got the idea :slight_smile:

Is the “actual root filesystem” just whichever snapshot happens to mounted?

I really never got to study snapper intricacies. I’m usually content with “btrfs subvolume get-default /” and “grep ’ / ’ /proc/self/mountinfo”. But yes, “actual root filesystem” resides on snapshot that is currently mounted.

8

OK, thanks for the clarification. So I guess my snapper is working as intended; I had just misinterpreted or misunderstood the instructions and the console output.

9

Probably the simplest and clearest way to think about btrfs snapshots is that you’re always “rolling forward,” even when you do a rollback, you’re actually creating a new snapshot still rolling forward.
So, you shouldn’t actually experience some kind of “returning” to some alternate snapshot without your intervention because by default you’re always going to be moving forward.

TSU