I decided not to even make that snapshot. It didn't seem like a good time investment since its authorization was already broken. Network worked for awhile, but also ended up broken again somehow, even with root.

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.

before the dist-upgrade it is

Also maybe nothing but

:~#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)

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

Wow! That instantly worked.

I do have:

live-boot-initramfs-tools
live-boot-doc
live-config-sysvinit
live-config-doc
live-config
live-boot

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

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

If you keep your system image small, as with a fresh image, you could even do it on a low-RAM system. I used to have my whole install fit on a CD instead of a DVD and run it on less than 4GB of RAM.

Looks like I don't actually know how initrd fits into the whole authorization scheme down-stream, so any pointers (or full-blown tutorials for that matter) would be welcome.

Something relevant that I remembered: I started out in Devuan on Jessie. So at one point I likely did successfully do a dist-upgrade, though I can't specifically remember. I have always used Refracta with my primary use case for Devuan, in fact Refracta is what led me to Devuan.

Side note: I do have a Devuan disk install, it's just for a dedicated mostly-offline purpose that I don't use very often.

I had not caught that. Looking into that now. A question would be - why would that affect the dist-upgrade for a a live image and not countless dist-upgrades on disk? What's a difference between the two that could trigger the OP condition?

Tested. On the broken-authorization system in question, it does.

Interesting. Well, here we are testing it more fully. It can be done without total hell; just yesterday I again did a full dist-upgrade, in RAM in a live setup, from ascii to chimaera, and the only noticeable problem is the total disaster that happens with the typical authority setup. Everything else works perfectly. Happy to offer more details about what packages I use etc., just ask (I use NetworkManager not Wicd, for instance).

I guess one weird/significant thing is that I had to lose network-manager-gnome for some dependency related reason, but there's nm-tui and nm-tray and so forth until that gets sorted out.

And it is true that you need a lot of RAM. On a full daily driver or workstation system, you probably couldn't do it under 8GB.

The only thing I've tried along those lines (so far) is lxpolkit, which did not make any difference. Won't be trying the KDE one, as I loathe KDE (sorry KDE devs, you are very skilled and I respect u). I figure the MATE one isn't much different than the GNOME one, but I can try it, and also LXQT-policykit. It's also pretty cumbersome to iterate this part since the switch has to be before the snapshot/reboot for this test. My guess is that since lxplokit did nothing, neither will the others. Elogind sounds like an interesting test though, even moreso because it is what @fsmithred stated they use. Could be that exclusive use of elogind created a blind spot for issues with up-grading/dating other authentication mechanisms.

I sort of figured. Basically you're mapping your home directory onto a separate partition, potentially on a separate drive. Thanks for the comment though. Back in the day before I settled on the method I use now, I used to just carry my home directory on an encrypted USB and manually paste it into the home directory on a live install, logout and then back in ^_^

@rolfie:

I'm looking into this su/su - thing now, but do you have a little more detail on what to look at specifically?

There's this:

But the OP authority problem pertains to non-X applications as well, nmtui for instance. Maybe I'm not understanding something.

Again, it's a stumper why this would be at play in a live/memory dist-upgrade but not in same on a HDD install. There's something different about the snapshot process.

I wonder if I can try another snapshot tool and see if it has the same result, to help narrow things down. I'm a bit rusty on the alternatives to Refracta but...

How not? When you can update literally every package in the distro?

Meaning what are the specific technical blocks to it?

As I said, I had tried to upgrade to beowulf previously and had the same problem; skipping beowulf was not a material part of the problem.

I don't know what is meant by "persistent volume". Something for running from USB? Persistence sounds like it would defeat some of the security features that I use live systems for.

To incorporate updates into the iso, I load the previous copy of the iso into ram from a disc, then do the updates, then make a new snapshot, then use that iso until I determine it is time to incorporate some new updates to a "new" iso. I put "new" in quotes because though I have repeatedly made new isos every month or two for years, it ultimately is the same system, having the same packages, though those packages are repeatedly updated using the above method.

Updates to things like different settings I've decided I prefer over the previous ones, I also change before making the new snapshot.

So in a way, from the system's perspective, it's a constantly-updated system which has rarely if ever been used online for anything but updates. I may use the system in memory for weeks or months, but that state isn't what gets updated. It's the stored copy that does, used for only the time is takes to make the updates. The system state that sees the most use, which is loaded from that updated iso, just vanishes when I decide enough updates, or critical updates, are needed.

Something I've always worried about is the possibility that some changes might require a full restart, not just logout/login. As I've explained in the OP, however, It's worked for years, and by that I mean it has been rock-solid stable and reliable. And as I've explained in this reply, this includes the ability to update packages. New kernels, firmware, everything. The only thing it doesn't seem to be able to accomplish is a dist-upgrade, because the authority system breaks somehow afterward.

I don't remember this being a problem for other snapshot systems I've used in the past, like the ones Porteus and Salix and that one way back for Ubuntu had, but it's been a long time and I may have forgotten.

I'm also not well versed in the 'kits, though I know a bit more about polkit/policykit after looking into this problem. Consolekit and pam are possibly also involved? But I've yet to learn much about them. I feel like I had this problem before policykit started being the local authority for everything though, so maybe policykit isn't all there is to it.

side note: I don't really like the complexity of polkit and would much prefer keeping gksu in a single-user environment.