I thought Btrfs & Snapper provided a safety net when installing packages with YaST goes horribly wrong. It didn’t for me.
So what did I do wrong? Why didn’t the Snapper Rollback help me, or rather, how should I have done the unrolling?
Installing openSUSE 13.2 (64bit) with / on Btrfs and /home on XFS (the defaults) caused quite some problems back then with Grub2 and Dual-Booting, but I managed thanks to this forum and thought that having Snapper was worth the trouble, so now I want to learn how to use it.
Today, my system stopped booting after installing, deleting and reinstalling a couple of packages through the YaST GUI, in order to fix an inconsequential boot error about some modules failing to load, which, apart from that red message being displayed for a split-second, had otherwise no discernible consequences whatsoever. Obviously, my system did no longer boot afterwards, since the mangled packages were concerned with the graphics card (Nvidia/Bumblebee/Optimus stuff, but this is unimportant for this thread here). Eventually I gave up on butchering my system and asked Grub2 to load a failsafe configuration, which still loaded fine to my surprise.
So here is what I did to attempt a Snapper rollback:
asking Grub2 to load the failsafe configuration with the highest version number (there were two)
I logged in directly as root (I did not want to disturb my user desktop)
started YaST (GUI), then clicked on “Snapper”
Snapper displayed a long list of snapshots, especially from today. So I selected yesterdays last snapshot, clicked on “show changes” and then ticked all checkboxes and asked it to restore these files contained in the snapshot.
Snapper then started working, showing a long list of file changes. This process took a while.
After Snapper reported that it had successfully finished, I closed YaST and rebooted the system normally.
However, the boot sequence hung at exactly the same spot as it did before the unrolling. So apparently the Nvidia Driver and config files were not restored. I already found it suspicious that I could no find them in the list of file changes, but that list was long and I did not look very carefully, just thinking reverting everything from that snapshot was the safest bet.
So if I have this problem again, what should I do different?
(Note: I already did a clean reinstall of 13.2 and cannot look at the old files anymore)
sh-4.2# mkfs.btrfs -f /dev/sdd
WARNING! - Btrfs v3.14.2 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
Turning ON incompat feature 'extref': increased hardlink limit per file to 65536
fs created label (null) on /dev/sdd
nodesize 16384 leafsize 16384 sectorsize 4096 size 14.91GiB
Btrfs v3.14.2
sh-4.2#
Notice a couple of things:
The multiple `WARNING!’ signs.
The `EXPERIMENTAL’ thingy.
As a result, the very idea of BTRFS providing any form of safety net is at best laughable and worst dangerous. Those
warning signs would have probably been hidden from your eyes by the openSUSE installer and it defies belief that the
developers chose BTRFS as the default file system for openSUSE 13.2 (and SLES 12 it appears). Perhaps this is a way of
imposing Snapper technology on users, but potentially at considerable cost.
Turning ON incompat feature ‘extref’: increased hardlink limit per file
to 65536 fs created label (null) on /dev/sdd
nodesize 16384 leafsize 16384 sectorsize 4096 size 14.91GiB
Btrfs v3.14.2
sh-4.2#
Notice a couple of things:
The multiple `WARNING!’ signs.
The `EXPERIMENTAL’ thingy.
As a result, the very idea of BTRFS providing any form of safety net is
at best laughable and worst dangerous. Those warning signs would have
probably been hidden from your eyes by the openSUSE installer and it
defies belief that the developers chose BTRFS as the default file
system for openSUSE 13.2 (and SLES 12 it appears). Perhaps this is a
way of imposing Snapper technology on users, but potentially at
considerable cost.
Hi
Stop right there… 13.2 has version v3.16.2+20141003 and SLE has
v3.16+20140829 a 3.14 nowhere in sight and AFAIK, was experimental at
that point.
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.2 (Harlequin) (x86_64) GNOME 3.14.0 Kernel 3.16.7-7-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
On 2015-02-04, malcolmlewis <malcolmlewis@no-mx.forums.opensuse.org> wrote:
> Hi
> Stop right there… 13.2 has version v3.16.2+20141003 and SLE has
> v3.16+20140829 a 3.14 nowhere in sight and AFAIK, was experimental at
> that point.
I’ve stopped! That was a copy-paste from an old and now-obsolete post and I can see you’re absolutely right. The matter
seems to be clarified on BTRFS wiki (Getting started - btrfs Wiki):
The status of btrfs was experimental for a long time, but the the core functionality is considered good enough for daily
use. There are new features being implemented and these should be considered experimental for a few releases when the
bugs get ironed out when number of brave users help stabilizing it.
So thanks for the correction and apologies for questioning the wisdom of the developers.
This has been my point from the start. It has always been unclear how you are supposed to actually use snapper. It has always to me at least seemed much easier and clear to roll back bad updates/app installs from Yast/zypper. It is often impractical to roll back the whole system if you perhaps have user data involved, like databases and settings you don’t want to roll back. I know you can rollback individual files and maybe directories but that is not the same as rolling back packages.
So all those that think snapper is the cat’s meow here is you chance to explain why what STurtle did was not the right thing or why it did not work.
When I start testing BTRFS, I have no intention of using snapper, myself.
I have never put my trust in similar applications. I view snapper the same as I view System Restore in Windows: Sometimes, it works … or seems to. Sometimes it seems to work, but you later discover it left something broken. Occasionally, it does not work at all. And, when most needed, it totally refuses to work, coming back with a message similar to “System Restore was unable to restore your …”
Instead – as I have repeatedly stated in these forums, as well as elsewhere – find a reliable drive imaging solution, such as Clonezilla, or something like it.
And, Back Up, regularly, rotated, with some archived steps along the way.
Anything less and you are hanging on a branch waiting for trouble to drop in on you.
Reinstalling my root partition was very fast and easy and gave me the latest packages. It’s a process that I need to do anyway for each new Suse version.
Snapper seems quite suited to the task, if I understood right. It should track all files, including all conduit files, right?
(I do use incremental backup for my home partition to two external devices at different locations, but it that is slow network heavy process, and I don’t see the benefit to use it on data that is otherwise easier to reconstruct)