A dist-upgrade failed a few days ago, and left a not working desktop. I could complete the upgrade later in chroot.
The installation now seems to be sound, everything is working fine.
Meanwhile I ran 2 additional upgrades. Snapper did not work, and nothing is appended to /var/log/snapper.log.
linux-ihk5:~ # snapper list
Failure (org.freedesktop.DBus.Error.Spawn.ExecFailed).
linux-ihk5:~ #
I removed and reinstalled snapper.
linux-ihk5:~ # rpm -qa --last | grep snapper
yast2-snapper-4.0.1-1.1.x86_64 Sun Nov 12 12:19:29 2017
snapper-zypp-plugin-0.5.2-1.2.noarch Sun Nov 12 12:19:29 2017
snapper-0.5.2-1.2.x86_64 Sun Nov 12 12:19:29 2017
libsnapper4-0.5.2-1.2.x86_64 Wed Nov 8 04:02:16 2017
grub2-snapper-plugin-2.02-10.1.noarch Mon Oct 9 14:31:43 2017
linux-ihk5:~ #
I can invoke snapper from another installation - openSUSE Leap 43.2. You have to create a new config for the path.
The additional config is located in the other install. As far as I see, there is no dependency and no shared data. This setup worked before. I use it to set snapshots as consistency points by my backup script.
Of course, I can now revert to an earlier state with # snapper rollback <snapshot-no>. I just want to ensure that I will not run twice into the same issue. I forgot to mention, that the Tumbleweed install is btrfs on LVM.
Snapper rollback from another installation does not work,
# snapper -c tbw rollback 470
command 'rollback' cannot be used on a non-root subvolume
I understand that. Snapper does not know that it is indeed a root subvolume, and thus the command is to risky.
I had to enter the steps manually with # btrfs subvolume snapshot …
create a read-only snapshot of the present state
create a read-write snapshot of the previous working state
set this snapshot as the default subvolume
linux-ihk5:~ # btrfs subvolume get-default /
ID 1056 gen 42507 top level 258 path @/.snapshots/d0/new_default_917
linux-ihk5:~ #
I passed through some additional steps in chroot. I don’t know, if they are necessary. They are if you want to start from grub of another installation.
4) recreate the initramdisk (# mkinitrd …)
5) recreate grub.cfg (# grub2-mkconfig -o …)
IMO rollbacks should always be safe and never subject to a past problem that can’t be addressed as long as a historical snapshot that fixes the problem exists…
That is because even when you roll back, you’re still incrementing <forwards>, rolling back doesn’t actually send you back to that previous point in time… You keep moving forward based on the old snapshot.
So,
The only extra thing i’d suggest if you did this is to create a personal note about this specific rollback, and not <ever> roll back to a snapshot <between> what you rolled back to and when you did the rollback… because then you’d re-introduce the problem. But, even if you made this mistake in theory you should still be able to roll back to either the proper snapshot <or> ironically a snapshot <after> you had successfully eliminated the problem (Now, that’s a weird exercise in existentialism!).
Glad to hear about your alternate solution that seems to be working…
Yes, unfortunately it is not possible to reproduce and analyse the original issue with my skills. The situation will disappear soon, because Tumbleweed progresses so fast. Subsequent upgrades went smooth.