New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't snapshot anymore after a "snapper rollback" #159
Comments
OK, I think I understand what happens: one needs to have a dedicated entry for /.snapshots/ in /etc/fstab like
I'd suggest two things:
In any case, thanks for such great piece of software! |
Thanks @moy this actually saved me hours of research! |
I'm having the same error after rollback on external drive with btrfs (not registered in fstab). How do I solve this problem without fstab? I can't add drive entry to fstab for number of reasons. I just want to scratch all changes to my ext drive permanently - especially timestamps which don't seem to be preserved by undochange because I actually damaged mostly modification dates of files. |
As I run into this problem with a relatively fresh installed openSUSE Tumbleweed system (installed about two weeks ago), I fear that this problem is still open. Is it possible that the much-famed snapshot system per default fails because of a missing mount point entry?! Is there a reason that this mountpoint isn't set up automatically? |
I just experienced this after installing Snapper in Debian Jessie. I reverted to a snapshot and it broke snapper, just as described above. "btrfs subvolume list -a /" returns a list of the snapshots that should be available. "snapper --version" gives: I'd like to add the the rollback itself worked perfectly and un-broke my system after I broke it trying to satisfy dependencies, which is exactly what I wanted it to do. On that note, thanks. |
I gave up on BTRFS as a whole. It's simply not everyday-usable for the average user. The half-ready snapshot issue described in this thread for me was only one symptom. (ext4 with rsnapshot and backups seems more reliable.) |
@Larx The problem here isn't with btrfs, it's with snapper. |
Probably not even snapper, but the default configuration (and mountpoint/subvolume selection) of openSUSE. For me it was a great disappointment that the first time I really needed a rollback, I was completely left alone and searched for hours until I found in this thread how to get back a running system when "rolling back". (As the snapshot feature is much hyped, I had more or less expected it to work out of the box with some nice YaST frontend.) |
@Larx I can understand your frustration and that is good to know. I had been thinking that snapper and rollbacks was a strong selling point for SUSE (I'm a Debian person myself). With a little bit of clarification the solution offered by @moy worked: (I played around a bit at first, thinking that it wanted the UUID assigned by btrfs to the .snapshots subvolume. To make it work enter the UUID of the partition containing the / filesystem.) @Larx I'm not using SUSE and have no YaST, so my expectations weren't the same as yours. I manually added snapper-gui and have been playing with it to make it work properly. I've been documenting my steps/results so that I can possibly make a .deb package out of it; I've never done this before but have wanted to learn and I feel that the functionality added by btrfs/snapper is worth it. I actually strongly feel that if it was implemented smoothly it would be a critical part of the Linux user experience PERIOD. The ability to painlessly do rollbacks takes away the risk of installing unknown software, playing with dependencies, etc. (It even lets me undo browser updates that break my extensions and destroy my user experience. ;) ) |
Actually, the necessity for the mountpoint was mentioned in tutorial: http://snapper.io/2014/04/29/rollback.html
On the other hand, there is two distinct approaches to the problem of initial revert:
Therefore, current snapshots layout is a mess. Better variant, as sublimation of this thread https://bbs.archlinux.org/viewtopic.php?id=194491 would be:
umount /.snapshots # mounted from /@snapshots
mount -o subvol=/ /mnt
btrfs subvolume snapshot -r /mnt/root /mnt/@snapshots/nextN/snapshot
btrfs subvolume delete /mnt/root
btrfs subvolume snapshot /mnt/@snapshots/nextN-1/snapshot /mnt/root Please, @aschnell, comment on (3) why it wasn't adopted as default variant. |
After setting up plenty of snapshotted btrfs systems i came to conclusion that easiest, most reliable and relatively fastest way to perform full rollback is to boot from liveCD, In easiest case scenario i kept everything apart from /var/log in one snapshotted subvol and /tmp in tmpfs. Full system recovery was accomplished in 2 commands:
In around 30 seconds system was up and running again (after power failure in the middle of kernel update fml) |
Ah one note - it has to be done from liveCD - i tried to do such thing on live system but it didn't survive and crashed in the middle of some critical files overwriting (still after booting liveCD and doing above it worked) |
@lapsio, this Edit: not mentioning that on system with enabled quotas by doing |
Will there be a solution anytime for this issue? I also have this problem, that "snapper cleanup" isn't functional anymore after a rollback :-( |
We also observed the problem in https://progress.opensuse.org/issues/102942 in our SUSE internal openQA infrastructure on one of our machines after a rollback. |
So this means, that we might get a fix for this after being patient so many years? 🙏🏻 |
Sorry but I am just reporting where we saw the very same problem so I am not speaking for developers of snapper here. And at the very least by adding our story we can learn more, at least about workarounds and best practices :) |
My hope was/is: |
Sure, but it's not like SUSE is one person ;) |
I know 🤣 I've been at your office in Nuremberg some times for the "SUSE Expert Days" 👍 |
That's my conclusion: https://progress.opensuse.org/issues/102942#note-15 |
Hi,
I messed-up my system, and did a "snapper rollback " and rebooted to get back to a consistant state. My system is repaired, but now, my default subvolume is not the root anymore, and snapper stops working.
The subvolumes are still there, but not visible in /.snaphots since I'm now using a different root:
I'm not sure what's the expected behavior here (nor how I'm supposed to get back to a system that both works and is able to continue snapshoting), but either what I'm seeing is a bug, or at least the documentation of "snapper rollback" should be updated to explain the user that one of the consequences of doing a "snapper rollback" is to set the system to boot into a subvolume that doesn't show other snapshots and can't do snapshots anymore.
The text was updated successfully, but these errors were encountered: