authorization problems possibly due to frankendevuan (attn: fsmithred)

bitcrashr · 2022-01-20 09:18:51

I've got an odd, one might say embarrassing problem. Time to talk about it in public!

I've been on ascii for years. This is because every time I try and do a dist-upgrade, my authorization breaks. Unless I login as root, I cannot mount volumes, change APs in nm-applet, change time and date, basically anything that consolekit/polkit was in charge of facilitating.

So I just stayed on ascii, updating packages of course. But now ascii is WAY old. I am not up for a fresh install - this is a system I've used for years and I have too many packages installed to just pack up my home directory and start a new settlement in a fresh install.

Anyway, latest is that I tried to leapfrog over beowulf and go straight to chimaera. Same problem. I got a bootable system, but authorization is all borked up. Otherwise the system works in the most lovely way you could imagine. WTF is going on with these authorization problems?!

Possibly further complicating matters is that this is an install *always* run from ram. It is only installed on disc/iso. It has never existed as a hdd install. Hence the @fsmithred in the post title.

Here are some error messages I get:

When trying to start the polkit agent (does not run as startup as it is set to do):

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

(polkit-gnome-authentication-agent-1:5422): dbind-WARNING **: 01:06:06.223: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program org.a11y.Bus: No such file or directory

(polkit-gnome-authentication-agent-1:5422): polkit-gnome-1-WARNING **: 01:06:06.230: Unable to determine the session we are in: No session for pid 5422

Unable to determine the session we are in??! What? Here is the output of ck-list-sessions:

X@X:/home/XX# ck-list-sessions
Session3:
unix-user = '1000'
realname = 'XX'
seat = 'Seat1'
session-type = 'unspecified'
session-class = 'user'
session-state = 'online'
active = FALSE
x11-display = ''
x11-display-device = ''
display-device = '/dev/tty1'
remote-host-name = ''
is-local = TRUE
on-since = '2022-01-20T00:38:33.346383Z'
login-session-id = '5'
XDG_RUNTIME_DIR = '/run/user/1000'
VTNr = '1'
Session2:
unix-user = '1000'
realname = 'XX'
seat = 'Seat1'
session-type = 'unspecified'
session-class = 'user'
session-state = 'online'
active = FALSE
x11-display = ''
x11-display-device = ''
display-device = '/dev/tty3'
remote-host-name = ''
is-local = TRUE
on-since = '2022-01-20T00:38:33.344794Z'
login-session-id = '3'
XDG_RUNTIME_DIR = '/run/user/1000'
VTNr = '3'
Session1:
unix-user = '1000'
realname = 'XX'
seat = 'Seat1'
session-type = 'unspecified'
session-class = 'user'
session-state = 'online'
active = FALSE
x11-display = ''
x11-display-device = ''
display-device = '/dev/tty6'
remote-host-name = ''
is-local = TRUE
on-since = '2022-01-20T00:38:33.340212Z'
login-session-id = '2'
XDG_RUNTIME_DIR = '/run/user/1000'
VTNr = '6'
Session6:
unix-user = '1000'
realname = 'XX'
seat = 'Seat1'
session-type = 'unspecified'
session-class = 'user'
session-state = 'online'
active = FALSE
x11-display = ''
x11-display-device = ''
display-device = '/dev/tty4'
remote-host-name = ''
is-local = TRUE
on-since = '2022-01-20T00:38:33.377597Z'
login-session-id = '6'
XDG_RUNTIME_DIR = '/run/user/1000'
VTNr = '4'
Session5:
unix-user = '1000'
realname = 'XX'
seat = 'Seat1'
session-type = 'unspecified'
session-class = 'user'
session-state = 'online'
active = FALSE
x11-display = ''
x11-display-device = ''
display-device = '/dev/tty5'
remote-host-name = ''
is-local = TRUE
on-since = '2022-01-20T00:38:33.357860Z'
login-session-id = '4'
XDG_RUNTIME_DIR = '/run/user/1000'
VTNr = '5'
Session23:
unix-user = '1000'
realname = 'XX'
seat = 'Seat1'
session-type = 'unspecified'
session-class = 'user'
session-state = 'active'
active = TRUE
x11-display = ':0'
x11-display-device = '/dev/tty7'
display-device = ''
remote-host-name = ''
is-local = TRUE
on-since = '2022-01-20T01:20:05.444616Z'
login-session-id = '19'
XDG_RUNTIME_DIR = '/run/user/1000'
VTNr = '7'
Session4:
unix-user = '1000'
realname = 'XX'
seat = 'Seat1'
session-type = 'unspecified'
session-class = 'user'
session-state = 'online'
active = FALSE
x11-display = ''
x11-display-device = ''
display-device = '/dev/tty2'
remote-host-name = ''
is-local = TRUE
on-since = '2022-01-20T00:38:33.352225Z'
login-session-id = '1'
XDG_RUNTIME_DIR = '/run/user/1000'
VTNr = '2'

Note that the directory '/run/user/1000' does not exist on my machine.

Here is the error (consolekit? polkit?) message from nm-applet:

"Connection activation failed

(1) Not authorized to control networking."

And from trying to mount a drive:

"Error mounting filesystem

Not authorized to perform operation (udisks-error-quark, 3)"

I've even tried brute forcing it by copying over all of the consolekit/polkit directories in /etc and /usr/share from the ascii install to the "upgraded" install - no improvement.

I suspect consolekit/polkit complications only because of the research I've done on my own to try and fix this. Asking for help is my last resort.

HELP?!

fsmithred · 2022-01-20 11:31:14

I'm not good with all that 'kit stuff, and I haven't had good luck with consolekit. I use elogind instead. But before messing with any of that, there's a more important question.

Possibly further complicating matters is that this is an install *always* run from ram. It is only installed on disc/iso. It has never existed as a hdd install.

If this is running in ram from an iso, then it's a read-only system that can't be upgraded. If all the upgrades are happening in a persistent volume, then I think it's way past time to make a new iso. Please explain your setup a little more, because I don't really understand what you did. Thanks.

bitcrashr · 2022-01-20 13:03:08

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.

bitcrashr · 2022-01-20 13:52:26

fsmithred wrote:

If this is running in ram from an iso, then it's a read-only system that can't be upgraded.

Here you used the word "upgrade" and not "update". Are you saying that for a live system, packages can be updated - as I said I've successfully done - but a full system upgrade is impossible? This is a known thing? If so, how not?

hevidevi · 2022-01-20 14:07:51

so you snapshot a live snapshot every few months while remaining on the ascii branch but you decided to leapfrog over to Beowulf? There is your problem, you cant imo make drastic changes to live system snapshots such as this, you need to upgrade to the beowulf live iso and that means downloading the beowulf live iso and starting again as you are not working with a persistent operating system.

Last edited by hevidevi (2022-01-20 14:12:03)

bitcrashr · 2022-01-20 14:14:18

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.

hevidevi · 2022-01-20 14:16:36

bitcrashr wrote:

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.

you cannot upgrade/dist-upgrade to a new release (ascii to beowulf) with a live iso unless you remaster it.

Last edited by hevidevi (2022-01-20 14:18:19)

bitcrashr · 2022-01-20 14:17:06

I guess I didn't say it explicitly, but "having tried to upgrade for years" - meaning before chimaera - implies beowulf. Sorry for not being clearer.

bitcrashr · 2022-01-20 14:18:36

hevidevi wrote:

you cannot upgrade/dist-upgrade a live iso unless you remaster it.

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

Meaning what are the specific technical blocks to it?

Last edited by bitcrashr (2022-01-20 14:20:15)

hevidevi · 2022-01-20 14:24:30

bitcrashr wrote:

hevidevi wrote:
you cannot upgrade/dist-upgrade a live iso unless you remaster it.
How not? When you can update literally every package in the distro?
Meaning what are the specific technical blocks to it?

There are many subtle differences in what is considered a persistent operating system and a live build aka an iso that can be run inside ram. I dont have all the answers but im sure fsmithred will fill you in on this.

bitcrashr · 2022-01-20 14:59:09

I guess also I should say that I've done apt-get upgrade successfully countless times. Just not dist-upgrade and the repository change that goes along with it.

rolfie · 2022-01-20 15:49:49

Can't this simply be the su/su - issue with paths?

@OP: have you read the release notes of Beowulf/Chimaera and the changed path setting?

rolfie

fsmithred · 2022-01-20 16:46:42

bitcrashr wrote:

fsmithred wrote:
If this is running in ram from an iso, then it's a read-only system that can't be upgraded.
Here you used the word "upgrade" and not "update". Are you saying that for a live system, packages can be updated - as I said I've successfully done - but a full system upgrade is impossible? This is a known thing? If so, how not?

I'm saying you can't upgrade the packages in a live-iso because it's read-only. But you found the way around that. You can upgrade packages in the running system if you have enough ram, and you can also make a snapshot directly from a running live system.

I've never tried upgrading a live system to the next release. I did try upgrading ascii to chimaera installed on a virtual hard disk, and it was very ugly. Problems were mostly around loss of python2 and loss of network connection when wicd went away. I don't think I even tried the desktop after the upgrade.

To test root's path, as root:

echo $PATH

and see if it contains /sbin and /usr/sbin.

Head_on_a_Stick · 2022-01-20 19:31:40

@OP: does elogind fix the problem?

Have you tried any other graphical authentication agents? For example lxqt-policykit (/usr/bin/lxqt-policykit-agent), lxpolkit (/usr/bin/lxpolkit), mate-polkit (/usr/lib/x86_64-linux-gnu/polkit-mate/polkit-mate-authentication-agent-1) or polkit-kde-agent-1 (/usr/lib/x86_64-linux-gnu/libexec/polkit-kde-authentication-agent-1).

alexkemp · 2022-01-20 22:23:04

bitcrashr wrote:

I don't know what is meant by "persistent volume"

My assumption here, not only because I'm not the original author but also because I'm far distant in time from my original use of them. My assumption, then:-

Whenever a Read-Only storage device is used, the problem becomes how to deal with data that needs to be carried over from one session to another. The fix is (for example) to format the storage so that a small section is Read-Write, and that is designated as a "Persistent Volume" (normally on a separate partition).

Added later: (I was hoping for an authoritative definition but could not find one quickly. Here is a web-page for creating a USB-stick with Persistent Storage which may be useful for some):
Create bootable USB Flash-Drive with Persistent Storage

Note the caveats for even this one:

You can’t modify system files, like the kernel. You can’t perform major system upgrades. You also can’t install hardware drivers. However, you can install most applications.

Last edited by alexkemp (2022-01-20 22:31:19)

bitcrashr · 2022-01-21 11:54:38

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.

rolfie wrote:

have you read the release notes of Beowulf/Chimaera and the changed path setting?

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?

fsmithred wrote:

To test root's path, as root:
echo $PATH
and see if it contains /sbin and /usr/sbin.

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

fsmithred wrote:

I've never tried upgrading a live system to the next release. I did try upgrading ascii to chimaera installed on a virtual hard disk, and it was very ugly. Problems were mostly around loss of python2 and loss of network connection when wicd went away. I don't think I even tried the desktop after the upgrade.

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.

Head_on_a_Stick wrote:

@OP: does elogind fix the problem?
Have you tried any other graphical authentication agents? For example lxqt-policykit (/usr/bin/lxqt-policykit-agent), lxpolkit (/usr/bin/lxpolkit), mate-polkit (/usr/lib/x86_64-linux-gnu/polkit-mate/polkit-mate-authentication-agent-1) or polkit-kde-agent-1 (/usr/lib/x86_64-linux-gnu/libexec/polkit-kde-authentication-agent-1).

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.

alexkemp wrote:

Whenever a Read-Only storage device is used, the problem becomes how to deal with data that needs to be carried over from one session to another. The fix is (for example) to format the storage so that a small section is Read-Write, and that is designated as a "Persistent Volume" (normally on a separate partition)

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:

5.3.2. Semantics for using environment variables for su changed
su has changed semantics in buster and no longer preserves the user environment variables DISPLAY and XAUTHORITY. If you need to run graphical applications with su, you will have to explicitly set them to allow access to your display. See bug #905409 for an extensive discussion.

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...

Last edited by bitcrashr (2022-01-21 12:28:09)

hevidevi · 2022-01-21 14:04:55

could this maybe be an initramfs issue when running a read only live iso?

Bit old link but provides some details.

https://superuser.com/questions/903142/ … otable-usb

you should have a read of how tails linux updates.

https://tails.boum.org/doc/upgrade/index.en.html

Last edited by hevidevi (2022-01-21 14:07:23)

hevidevi · 2022-01-21 14:24:32

the way i see it is i dont believe the update-initramfs will update/ugrade a live read only root file system, so you will be stuck with an initrd that is always going to use ascii authorization tools. I could be wrong here but that is my take on it unless refracta-snapshot can bypass this hurdle?

im going to test this myself with a live iso upgrade, im intrigued by it now.

Last edited by hevidevi (2022-01-21 14:27:52)

bitcrashr · 2022-01-21 14:26:59

hevidevi wrote:

could this maybe be an initramfs issue when running a read only live iso?

I do have an initrd image in /boot, but, interestingly, the initrd.img_pre-snapshot file typically present in / after snapshot is not there. How would initramfs be involved in a problem such as this though?

I also just noticed that even when using sudo to get nm-applet/NetworkManager to connect to a previously saved AP, it connects to the AP and has speed stats, but can't ping or transfer any packets beyond that. Maybe unrelated.

Last edited by bitcrashr (2022-01-21 14:28:37)

bitcrashr · 2022-01-21 14:32:34

hevidevi wrote:

im going to test this myself with a live iso upgrade, im intrigued by it now.

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.

hevidevi wrote:

an initrd that is always going to use ascii authorization tools

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.

Last edited by bitcrashr (2022-01-21 14:37:07)

hevidevi · 2022-01-21 14:34:07

bitcrashr wrote:

hevidevi wrote:
could this maybe be an initramfs issue when running a read only live iso?
I do have an initrd image in /boot, but, interestingly, the initrd.img_pre-snapshot file typically present in / after snapshot is not there. How would initramfs be involved in a problem such as this though?
I also just noticed that even when using sudo to get nm-applet/NetworkManager to connect to a previously saved AP, it connects to the AP and has speed stats, but can't ping or transfer any packets beyond that. Maybe unrelated.

possibly due to updating the initramfs not being able to complete successfully due to read only filesystem.

not sure on NetworkManager issue. I dont believe NM should be run as root either??

bitcrashr · 2022-01-21 14:38:27

hevidevi wrote:

I dont believe NM should be run as root either??

It shouldn't. But we are testing,

fsmithred · 2022-01-21 14:44:51

hevidevi wrote:

the way i see it is i dont believe the update-initramfs will update/ugrade a live read only root file system, so you will be stuck with an initrd that is always going to use ascii authorization tools. I could be wrong here but that is my take on it unless refracta-snapshot can bypass this hurdle?
im going to test this myself with a live iso upgrade, im intrigued by it now.

If the live-tools package is installed, update-initramfs gets diverted. You could run 'update-initramfs.orig.initramfs-tools...' instead. I prefer to remove or not install live-tools. I could never figure out what it was good for.

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

To give user permission to run ping in chimaera:

dpkg-reconfigure iputils-ping

bitcrashr · 2022-01-21 15:02:23

fsmithred wrote:

To give user permission to run ping in chimaera:
dpkg-reconfigure iputils-ping

Wow! That instantly worked.

fsmithred wrote:

If the live-tools package is installed, update-initramfs gets diverted.

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?

fsmithred · 2022-01-21 15:11:04

bitcrashr wrote:

<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"

The officially official Devuan Forum!

#1 2022-01-20 09:18:51

authorization problems possibly due to frankendevuan (attn: fsmithred)

#2 2022-01-20 11:31:14

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#3 2022-01-20 13:03:08

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#4 2022-01-20 13:52:26

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#5 2022-01-20 14:07:51

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#6 2022-01-20 14:14:18

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#7 2022-01-20 14:16:36

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#8 2022-01-20 14:17:06

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#9 2022-01-20 14:18:36

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#10 2022-01-20 14:24:30

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#11 2022-01-20 14:59:09

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#12 2022-01-20 15:49:49

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#13 2022-01-20 16:46:42

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#14 2022-01-20 19:31:40

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#15 2022-01-20 22:23:04

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#16 2022-01-21 11:54:38

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#17 2022-01-21 14:04:55

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#18 2022-01-21 14:24:32

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#19 2022-01-21 14:26:59

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#20 2022-01-21 14:32:34

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#21 2022-01-21 14:34:07

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#22 2022-01-21 14:38:27

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#23 2022-01-21 14:44:51

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#24 2022-01-21 15:02:23

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

#25 2022-01-21 15:11:04

Re: authorization problems possibly due to frankendevuan (attn: fsmithred)

Board footer