Snapper not working after upgrade

English Install/Boot/Login
#1

Hi all,

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.

Best regards,
Bequimão

#2

My guess is that you were on the right track about the cause of your problem, but your solution is faulty.

Have you tried “force re-installing” snapper?

eg

zypper in -f snapper

Remember to disable your modification pointing to your alternate snapper from another install.

TSU

#3

I invoked it now, but there is no change.

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.

Best regards,
Bequimão

#4

Meanwhile I got it working.

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 …

  1. create a read-only snapshot of the present state
  2. create a read-write snapshot of the previous working state
  3. 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 …)

Best regards,
Bequimão

#5

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…

TSU

#6

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.

Greetings,
Bequimão