Seems with OpenRC 0.63, you can simply enable user services with

pam-auth-update --enable openrc

and making a user.$USER file, meaning you no longer have to compile and extract bits of Git OpenRC.

I do not recommend anyone else peform the following sequence of events, and instead hope that a fix comes someday to remove the need for all this bodging. However, if you think this is at all a good idea, here's what I did to fix my issue:

• Built OpenRC from source, copied /build/init.d/user from there to my /etc/init.d/, changing any references of /usr/lbexec/rc to /usr/lib/rc, as that's where OpenRC's internal utilities are installed on Devuan (Do not install all of OpenRC from source after building; that bricked my system, and you only need a single file from it anyway)

• Added the following to the end of /etc/pam.d/common-session (this was pulled from the Artix wiki, and it seems to work reasonably well):

  session [default=1 success=ignore] pam_succeed_if.so uid >= 1000
  -session optional pam_openrc.so

• Created a new /etc/pam.d/openrc-user file, with the following contents:

  #%PAM-1.0
  #OpenRC-User starts up the user session for OpenRC. It needs all the
  #stuff a common user session has
  session include common-session

• Symlinked /etc/init.d/user to /etc/init.d/user.(me), as instructed, in addition to creating /etc/user/init.d/, ~/.config/rc/runlevels, and ~/.config/rc/init.d .

Doing all this allows me to run user services of some description. Though I doubt you want to see my scripts for Pipewire, they can start automatically now.

And if unstable, that's why its happening. Its meant for developers lol.

Have a good day all the same.

(... I don't think it was worth it)

I'm honestly terrified of installing a new system. This is the culmination of six years of tinkering and bodging, and so many little things have been adjusted that I've forgotten what exactly I did to make it all happen.

In future I would recommend an install log. Every system I install I do this it is a text file where I document every change made to the system, the reason for the change and if relevant the URLs of the web page(s) where I found the solution. This method has saved many a headache in trying to figure out the changes. I also use a ## Changed by me comment section in every configuration file changed where it was changed with a similar explanation block used for the change as goes in the install log. This makes it an easy grep to find any file I have made changes to.

If you use testing, openrc would probably work for that too, but devuan unstable is just a good way to get a broken system.

If you don't know how to fix the problems that come with unstable, use testing or stable. I cannot recommend this enough.

So this may be the very occasion to install a fresh system

Seconding this excellent advice.

The standard installer does an excellent job.
Just know that Excalibur has implemented the "usr-merge" already. This makes a dist-upgrade v5 to v6 a bit tricky. Read the notes and instructions.
Good luck!

@rwall, add some double-quotes, and make that line 17 be

if [ ! -e "${RC_SVCDIR}/softlevel" ]; then

and then you won't have that problem (at least).

I've tried that on a fair few occasions. The same result occurs. I'm starting to think that RC_SVCDIR either has multiple paths or it's not set at boot. My computer has things all over the place - the root filesystem been transplanted over and over again onto different drives for six years, so it's possible things have gotten so messy that RC_SVCDIR is in multiple places.

if [ ! -e "${RC_SVCDIR}/softlevel" ]; then

and then you won't have that problem (at least).