![](https://seccdn.libravatar.org/avatar/37ce46f3bb7af09b1da428d24b87bd4a.jpg?s=120&d=mm&r=g)
On Thu, Apr 14, 2016 at 10:01 PM, Andrei Borzenkov
15.04.2016 05:41, Chris Murphy пишет:
Rollback as documented is really intended to be used from read-only snapshot boot. If something goes wrong you boot into one of existing read-only snapshots and then call "snapper rollback" to make it (well, its clone actually) your permanent root. So there is no GUI because you are never really supposed to use GUI.
If snapper wants rollbacks done only from read-only snapshot boots, it should disallow me from using rollback subcommand from rw snapshot boot. *shrug* If it's a snapper limitation, OK fine, but then inform me or deny the option. It's definitely not a btrfs limitation, it doesn't care about switching default subvolumes as many times as you want back to back. I don't know why you wouldn't want to use the GUI to do a rollback though.
OK that's one way to do it I guess... Looks like there is no going back to the same filesystem tree/subvolume ID. But as it's a snapshot
Yes, which is one of things I actively do not like in SUSE implementation. Compare this with Solaris "boot environment" where you have multiple alternative versions of root and can switch between them (by "activating" boot environment).
I think the GRUB readonly snapshot listing is confusing. Right now every item in the list is named the same, with each name's tail end cut off so I don't really know what I'm booting. It's sort of a guess. And the YaST2+snapper GUI has a lot of snapshots in it that don't really cue me in to what the differences are in a summary. I'd like to see openSUSE maybe label the snapshot right before a system update as a particular rollback candidate that goes in the GRUB menu, and in a less verbose snapper menu; and label it by date like, "openSUSE Tumbleweed 20160404" and so on, so that I can pick a date to rollback to, rather than 20 snapshots on that date. I can see where a bunch of snapshots are handy if I want to restore a specific file. But if I want to rollback due to a bad update, I really only need 2 or at most 4 options for rolling back to. One day I'd like to see these be named trees such that anyone with the exact same named tree has the same versions of all relevant "core" binaries.
it is pretty much the same thing. However, keep in mind that since I'm currently booted still in /1/ any changes now are going in /1/ and not into /60/ so I probably ought to reboot sooner than later.
Hmm, failed to start modem manager, failed to start network manager, failed to start avahi, lots of failures on the next boot. It's not exactly revealing why... OK force power off. Choose the last (probably
Sounds like a bug, although I am not sure to which extent this feature was tested ("rollback" from live system).
Yeah the whole thing blew up subsequently. It may be (inadvertent) user sabotage, I had the VM on a qemu disk with cache set to unsafe, so that might have thwarted Btrfs COW. I did file an upstream bug and mentioned the mess on the list, just in case it's relevant to making Btrfs better. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org