Hopefully it will drive more users to Devuan, a system that has no systemd problems.

"verbatim" is a Google search option, on their search page.  Didint mean to imply a general search option.  Excuse my lack of clarification.

Rolling Stones Black and Blue.  Ron Wood was a such a great addition to RS.  Ive always thought this 1 of their best albums.

Jagger dosent stop.
https://www.youtube.com/watch?v=gVpzrxjiAtc

Richards and Wood.
https://www.youtube.com/watch?v=yaCYoCAOZbI

The openrc command to add a service to the default runlevel would be:

rc-update add lxdm default

This should create a symlink for the lxdm init script in /etc/runlevels/default (pointing to /etc/init.d), and thus openrc should autostart it upon boot.

Devuan Ascii is at JDK8-

https://pkginfo.devuan.org/stage/ascii/ … eb9u1.html

More discussion here-

https://dev1galaxy.org/viewtopic.php?id=2813

Maybe you need to tell openrc to start the script in a runlevel.  Assuming the service is named webmin and to have it start in default runlevel:

rc-update add webmin default

I had to work through on listening to this, but turns out very good.

Miles, nothing more needs to  be said.

I think I am correct with my response here, if not; please correct this post.  I believe you can see what packages are Devuan, and what packages are Debian by downloading the Packages.gz files from "Devuan" for Devuan and from "Merged" for Debian (see below for details).  Packages.gz contains a text file list of what I believe to be packages from Devuan (modified by Devuan), and from Debian (packages not modified). 

For stable ascii, amd64 for example.

if you go here, you can download the Devuan Packages.gz file.  Extract Packages.dev.  I believe this to be all packages modified by Devuan:
https://pkgmaster.devuan.org/devuan/dis … ary-amd64/

Go here for Debain "merged" packages that do not require Devuan modifications:
https://pkgmaster.devuan.org/merged/dis … ary-amd64/

You will see that the packages in Devuan requiring modification pales in comparison to the Debian base packages (luckily!).

Again, please correct me if this post is incorrect.

To document my findings.

Debians implementation of openrc init uses /sbin/init (obviously).  /etc/inittab, /etc/init.d/rcS, and /etc/rc are used to run openrc runlevel sysinit (until completion) and then runlevel default.  Note runlevel boot is not used in Debians implementation.  "running" these runlevels is executing /sbin/openrc with the runlevel as the commandline arg.

When running openrc-init (as demonstrated by @Geoff42), /sbin/init, initab, rcS, rc are not used.  Instead openrc-init has hard-coded (in openrc-init.c) the running of runlevel sysinit, followed by runlevel boot, followed by runlevel default.  "default" can be overridden with a commandline arg to openrc-init.

Also, it appears that Debian has added patches to openrc for the LSB and insserv support.  This support is not included in vanilla openrc.  This modification provides the ability for openrc to use stock sysvinit init scripts (via LSB) and thus not requiring all init scripts to be rewritten to openrc-run interpretive specs (/bin/sh can be used).  This is good in that it allows openrc to be run with minimal changes, from sysvinit.  Debians process for using LSB and insserv does not use the 3 hidden .depend.* files in /etc/init.d, instead processes the LSB headers directly (thus the 3 .depend.* files are not used).

Thanks @Geoff42 for your persistent work in getting openrc-init to boot!

Just to tidy up-
Yes, in effect; it would be "each level just get started asynchronously" from the code change in init(), but the new code moved the waitpid out of from init() down into do_openrc() at line 73:

while (waitpid(pid, NULL, 0) != pid)

Thus the return from do_openrc() wont happen until the "whatever we need to do to ensure all has started..."  has actually started.

EDIT- To clarify; The transition of sysinit-boot-default will not be asynchronously.  atleast in the intent of the coding.

It appears OpenRC does NOT use the .depend.* files in /etc/init.d.  Instead directly using the LSB header info within the scripts.  I ran some tests; changing the #Required-Start: in a particular script in /etc/init.d, and also manually changing the scripts entry in depend.boot to something different from that.  The change to the script file was picked up on next boot, and the change to .depend.boot was not picked up at all.  I then deleted the 3 .depend files, rebooted, and nobody complained.

The change I made to the script file was reflected in /run/openrc/deptree as well as the actual running of the script, at the next boot after the change.

Researching...

In openrc-init, the sysint and boot runlevels are hard-coded.  Default is also hard-coded, but can be overridded by 1st arguement on commandline of openrc-init.
waitpid is used to ensure the various runlevels are completed before the next one is run, I suppose this is how waitpid works (not familiar with it).
Thus openrc-init "should" run the runlevels correctly (started in proper order, waiting for each to complete).

static void init(const char *default_runlevel)
{
	const char *runlevel = NULL;
	pid_t pid;

	pid = do_openrc("sysinit");
	waitpid(pid, NULL, 0);
	pid = do_openrc("boot");
	waitpid(pid, NULL, 0);
	if (default_runlevel)
		runlevel = default_runlevel;
	else
		runlevel = rc_conf_value("rc_default_runlevel");
	if (!runlevel)
		runlevel = rc_default_runlevel;
	if (!rc_runlevel_exists(runlevel)) {
		printf("%s is an invalid runlevel\n", runlevel);
		runlevel = rc_default_runlevel;
	}
	pid = do_openrc(runlevel);
	waitpid(pid, NULL, 0);
	log_wtmp("reboot", "~~", 0, RUN_LVL, "~~");
}