I just started to use btrfs and have been taking snapshots using yast → filesystem snapshots
My question is, how would I rollback to a snapshot I created.
Also after a rollback, is the previous operation saved or deleted?
Let’s say I wanted to rollback to a ID value I know is good and I also wanted everything after this to get deleted after the rollback. How could I go about doing this?
Hi, snapper list will show you all available snapshots. Snapshots that you have manually created by snapper create --description "Snapshot for week 2 2014" will appear as single under the Type column of snapper list output. They are not removed automatically when Snappers’ set snapshot configuration is full.
To delete a snapshot with the command line tool, you need to know its number. Get it by running snapper list. To delete a snapshot, run snapper delete NUMBER.
Information referenced from here > System Recovery and Snapshot Management with Snapper | Reference | openSUSE Leap 15.0
This linked doc is from Leap 15.0. There shouldn’t be that much differennce, but better link the actual reference handbook:
I have been unable to fix my nvidia problems in TW. There were no problems under kernel 6.9, so I looked at snapper (for the first time ever!) and found a file with 6.9 kernel. I boot from that file but I end up with a 6.10 kernel and no fix for the nvidia problem. Any answers to why the snapper didn’t roll back so I can fix it?
Hi, at ‘boot menu’ did you select ‘Start bootloader from a read-only snapshot’?
Then if prefered you can snapper rollback snapshot_ID, snapper rollback -d, or snapper rollback -d "Description-of-rollback".
Then powercycle the machine.
-Regards
You can’t use an out of the box configuration of snapper to rollback to older kernels. You might be able to combine your rollback followed with booting from an older kernel, but as TW is now on the 6.11 kernel there is a good possibility the 6.9 kernel is gone.
Maybe I’m wrong, but on my install /boot is part of the snapshots, so should a rollback not also include the kernel?
See section 3.1.3 of the guide referenced above.
I did this the way you describe. But, as described below, the 6.9 kernel was probably gone. So, it installed the kernel that was left.
I gave up hope of fixing this problem. So, I used the live usb and re-installed TW. It fixed the problem using only two files labeled “nvidia.” It was kernel-firmware and the MicroOs driver. I was disappointed that my data disappeared because I thought I spared my user files. However, I previously copied the data and re-installed it. So, all is good here and I learned about snapper.
Contained In the /etc/zypp/zypp.conf file on the machine here is a modification to line 580 as follows: > multiversion.kernels = latest,latest-1,latest-2,latest-3,latest-4,latest-5,latest-6,latest-7,latest-8,latest-9,running,6.6.11-1,6.9.9-1
I would recommend backing up /etc/zypp.conf first.
Then I recommend the line on your machine to be modified as follows: multiversion.kernels = latest,latest-1,latest-2,latest-3,latest-4,latest-5,latest-6,latest-7,latest-8,latest-9,running this will ensure that you retain and eventually (as upgrades pass) you have a multitude of previous kernels at your disposal during boot menu > Advanced options for openSUSE.
I am unaware of any problems that can occur from doing the above and do hope that if this information is not good please do say so.
-Greatest Hopes
Above /etc/zypp.conf is incorrect. It should be /etc/zypp/zypp.conf.
Thank you for this info. My re-install went better than I feared. I re-loaded files I had saved to DVD and am making things get back to how they were.
I will follow your recommendation on this.
System snapshots include the initial ram disk images and their respective kernels in /boot
@doscott only grub2’s own modules are excluded from system snapshots. For example, a user might need to add a grub2 module for different hardware or to boot a different OS.
As an example, I recently removed the longterm kernel in favor of keeping more default (“stable”) kernels. This change was captured on my system by snapper in the pre-post pair of snapshots 419 and 420. (The numbers are due to snapper, they don’t have any specific meaning or filesystem relevance.)
$ snapper --config=root --iso list --disable-used-space | grep 419
419 │ pre │ │ 2024-10-01 21:57:46 │ root │ number │ zypp(zypper) │ important=yes
420 │ post │ 419 │ 2024-10-01 22:00:48 │ root │ number │ remove k-lts │ important=yes
In 419, the longterm kernel is still available. In 420, it’s gone. (Snapshots depend on filesystem support, normally BTRFS although something can be done with LVM thin-provisioning.) Since system snapshots are nested under /.snapshots, they are automatically mounted and their contents can be read like any other part of the file hierarchy.
$ ls -1 /.snapshots/419/snapshot/boot/initrd-*
/.snapshots/419/snapshot/boot/initrd-6.10.11-1-default
/.snapshots/419/snapshot/boot/initrd-6.10.8-1-default
/.snapshots/419/snapshot/boot/initrd-6.10.9-1-default
/.snapshots/419/snapshot/boot/initrd-6.11.0-1-default
/.snapshots/419/snapshot/boot/initrd-6.6.49-1-longterm
/.snapshots/419/snapshot/boot/initrd-6.6.51-1-longterm
/.snapshots/419/snapshot/boot/initrd-6.6.52-1-longterm
$ ls -1 /.snapshots/420/snapshot/boot/initrd-*
/.snapshots/420/snapshot/boot/initrd-6.10.11-1-default
/.snapshots/420/snapshot/boot/initrd-6.10.8-1-default
/.snapshots/420/snapshot/boot/initrd-6.10.9-1-default
/.snapshots/420/snapshot/boot/initrd-6.11.0-1-default
If I read-only boot into 419, or do a rollback to 419, the lts kernel is available again.
So basically what I already said. The kernel images in /boot are part of the snapshots, while the boot loader configuration is not.
That is incorrect. /boot/grub2/grub.cfg is part of the snapshot.
While that’s true, can you tell me why the documentation states “A rollback of the boot loader configuration is not supported.”?
No. I am not the author of the document you quote. But the directories listed before this statement do not contain “configuration”, but the grub2 binaries.
It is true that you cannot revert the bootloader binaries themselves as well as the pre-boot configuration on ESP that locates the /boot filesystem. For most users “bootloader configuration” is equal to grub.cfg and so the quoted statement is incorrect.
That makes sense. In summary, a snapper rollback restores the kernel (which was the point of my previous post) as well as the boot configuration, which I got wrong. Sorry for the confusion.
I wonder if snapper undochange <number>..<number> command works the same?
The snapper undochange <number>..<number> command works a bit different. It keeps your default btrfs subvolume, but performs an undo action on the files that differ between the two snapshot numbers in the arguments of the command.
A snapper rollback instead changes the default btrfs subvolume to boot from the subvolume id of the snapshot.
For simple tasks an undochange might be sufficient. But if something is really borked or you want to revert the whole system to a working state, a rollback is the better option.