Though if you mean just for isolating the update that breaks user auth - sure. I can run a snap in a VM pretty easily.

Elogind was something I had installed deliberately on the snaphots which completed the dist-upgrade, in hopes of preemptively solving the broken auth that had happened in all previous dist-upgrade snaps. Of previous dist-upgrade snaps, I only have copies of the ones that I included elogind in (I usually delete failed snaps).

Anyway, full dist-upgrades seem to be broken in this system I am trying to upgrade, whether elogind is installed before snapshot or not.

The most functional progress I've made has been with a partial upgrade that only included chimaera updates from the security repo and didn't touch any polkit/consolekit/pam packages. On this fully functional snap,

dpkg -l | egrep "consolekit|logind|policykit|polkit|libpam"

gets us:

consolekit                                                   0.4.6-6
libpam-cap:amd64                                      1:2.25-1
libpam-ck-connector:amd64                      0.4.6-6
libpam-gnome-keyring:amd64                   3.20.0-3
libpam-modules:amd64                              1.1.8-3.6
libpam-modules-bin                                    1.1.8-3.6
libpam-runtime                                            1.1.8-3.6
libpam0g:amd64                                         1.1.8-3.6
libpolkit-agent-1-0:amd64                           0.105-25+devuan0~bpo2+1
libpolkit-backend-1-0                                  0.105-25+devuan0~bpo2+1
libpolkit-backend-consolekit-1-0:amd64    0.105-25+devuan0~bpo2+1
libpolkit-gobject-consolekit-1-0:amd64      0.105-25+devuan0~bpo2+1
policykit-1                                                   0.105-25+devuan0~bpo2+1
policykit-1-gnome                                       0.105-6

This snap, however, is the one which has now been full dist-upgraded several times and failed. One potentially interesting thing is that the polkit authorization agent is not set to autostart on this snapshot, is not running, and setting it to autostart doesn't seem to help. Running

:~#/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1

gets us:

(polkit-gnome-authentication-agent-1:26499): polkit-gnome-1-WARNING **: 08:50:21.019: Unable to determine the session we are in: GDBus.Error:org.freedesktop.ConsoleKit.Manager.GeneralError: Unable to lookup session information for process '26499'

My next move is to incrementally update packages until I can isolate which one triggers the effect. It will be very helpful if people more knowedgable about the 'kits and about the refracta process continue to offer insights or guesses though.

After doing all this, removing consolekit and libpam-ck-connector and installing elogind and libpam-elogind, I now have lost authority on that iteration including the ability to control nm-applet. I do seem to still have connectivity through controlling nmtui as root.

Unless someone comes in with some advice in the next couple minutes, I'm going to try and continue with the dist-upgrade and see what happens.

Install libpam-elogind and remove consolekit and libpam-ck-connector.

Ok. And when should I do this:

-before the dist-upgrade
-after the dist-upgrade
-doesn't matter

?

:~#dpkg-reconfigure libelogind0

returned

dpkg-query: error: --status needs a valid package name but "libelogind0" is not: ambiguous package name 'libelogind0' with more than one installed instance

Use --help for help about querying packages,
/usr/sbin/dpkg-reconfigure: libelogind0 is not installed

(libelogind0 is shown as installed in Synaptic)

(I am now going through all these packages and using dpkg-reconfigure on them because I have hope that it is magic)

(Update: dpkg-reconfigure has solved nothing except non-root ping)

consolekit
elogind (?!)
libelogind0:amd64
libelogind0:i386
libpam-cap:amd64
libpam-ck-connetor:amd64
libpam-gnome-keyring:amd64
libpam-modules:amd64
libpam-modules-bin
libpam-runtime
libpam0g:i386
lobpolkit-agent-1-0:amd64
libpolkit-gobject-consolekit-1-0:amd64
policykit-1
policykit-1-gnome

ugh you're welcome that was all manually transcribed

su was moved from the shadow source package to util-linux, and the behavior changed at that time. To revert to the old behavior (from man su):

echo 'ALWAYS_SET_PATH yes' >> /etc/default/su

I did that as soon as I found it. Did not have an effect that I could find.

Check the error log to see what happened with initramfs. If you run the cli version of refractasnapshot, add '-d' option to get a move verbose log. If you start the gui version from the menu, it's already in debug mode. (/var/log/refractasnapshot.log)

Very unfortunately that logfile is completely blank.

THAT output a *very long* list of packages.

But this is possibly interesting:

":~# dpkg-reconfigure initramfs-tools
/usr/sbin/dpkg-reconfigure: initramfs-tools is broken or not fully installed

<snip>
...installed, but these don't count toward that, correct?

And why might my initrd.img_pre-snapshot be missing?

Correct. No live-tools package in your system.

Check the error log to see what happened with initramfs. If you run the cli version of refractasnapshot, add '-d' option to get a move verbose log. If you start the gui version from the menu, it's already in debug mode. (/var/log/refractasnapshot.log)

Check this, too:

dpkg -l | egrep "consolekit|logind|policykit|polkit|libpam|ck"