IMPORTANT NOTE:  If you have live-config installed, when you try to install runit-init, apt will want to remove live-config (and refractasnapshot, if that's installed.) The way to get around this is to include live-config-runit in the command to install runit-init.

For beowulf, I just made an easy single live-config-runit package that isn't in the repo. You can get that here: http://distro.ibiblio.org/refracta/file … u1_all.deb  Install it before you try to install live-config and after you install runit. (i.e. stuff might get put on the autoremove list. Just reinstall things if you need to.)

Another note: I did not replace the live-config init script with a run script. That's a project for a later date.

then did as Head_on_a_Stick said and

gpasswd -a $USER input 

because I'm running headless over SSH.  Not sure if this is strictly necessary?

No, it isn't. Don't add users to the input group unless you have to.

When I ran `# apt install runit-init`, it said:

...
dpkg: sysvinit-core: dependency problems, but removing anyway as you requested:
 init depends on sysvinit-core | runit-init: however:
  Package sysvinit-core is to be removed.
  Package runit-init is not installed.
...
Unpacking runit-init (2.1.2-36) ...
Setting up runit-init (2.1.2-36) ...

And there was no question asked like, "To continue type in the phrase" etc. Is this normal?

However I ran `reboot` and it said at the end:

Will now restart.
Give root password for maintenance
(or press Control-D to continue):

New to Devuan, but I finally got fed up with Systemd on my Raspberry Pi, so I just installed Beowulf on my Raspberry Pi 3B (rev1.2). I used the images supplied at https://arm-files.devuan.org/ which are super easy to use, but do not offer options to install runit during install. So I just switched following the OPs instructions and I had this same error message:

sudo apt install runit-init
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  fgetty getty-run runit runit-helper sysuser-helper
The following packages will be REMOVED:
  sysvinit-core
The following NEW packages will be installed:
  fgetty getty-run runit runit-helper runit-init sysuser-helper
0 upgraded, 6 newly installed, 1 to remove and 0 not upgraded.
Need to get 199 kB of archives.
After this operation, 418 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://deb.devuan.org/merged beowulf/main arm64 runit-helper all 2.8.6 [4,900 B]
Get:2 http://deb.devuan.org/merged beowulf/main arm64 sysuser-helper all 1.3.3 [3,844 B]
Get:3 http://deb.devuan.org/merged beowulf/main arm64 runit arm64 2.1.2-25 [109 kB]
Get:4 http://deb.devuan.org/merged beowulf/main arm64 getty-run all 2.1.2-25 [18.3 kB]
Get:5 http://deb.devuan.org/merged beowulf/main arm64 runit-init arm64 2.1.2-25 [40.1 kB]
Get:6 http://deb.devuan.org/merged beowulf/main arm64 fgetty arm64 0.7-5 [22.2 kB]
Fetched 199 kB in 2s (114 kB/s)
Selecting previously unselected package runit-helper.
(Reading database ... 65737 files and directories currently installed.)
Preparing to unpack .../runit-helper_2.8.6_all.deb ...
Unpacking runit-helper (2.8.6) ...
Selecting previously unselected package sysuser-helper.
Preparing to unpack .../sysuser-helper_1.3.3_all.deb ...
Unpacking sysuser-helper (1.3.3) ...
Selecting previously unselected package runit.
Preparing to unpack .../runit_2.1.2-25_arm64.deb ...
Unpacking runit (2.1.2-25) ...
Selecting previously unselected package getty-run.
Preparing to unpack .../getty-run_2.1.2-25_all.deb ...
Unpacking getty-run (2.1.2-25) ...
dpkg: sysvinit-core: dependency problems, but removing anyway as you requested:
 init depends on sysvinit-core | runit-init; however:
  Package sysvinit-core is to be removed.
  Package runit-init is not installed.
...

BEFORE I restarted, I noticed it hadn't completely removed sysvinit, so manual removed it:

sudo apt remove sysvinit init

then reinstalled runit-init:

sudo apt install runit-init

which completed without errors, and then did as Head_on_a_Stick said and

gpasswd -a $USER input 

because I'm running headless over SSH.  Not sure if this is strictly necessary?
Not sure what you would have to do if you had restarted already... glad I caught it beforehand.

apt install runit-init

It was still running with the old init so I wanted to reboot it. From Dom0 I tried to shutdown via Xen

xl shutdown chimaera

which had no effect, so I hit it with a bigger hammer

xl destroy chimaera

which did stop it!

On booting it again it recovered the disk from the journal, but did come up.
It gave no login prompt, which was due to my not having set up the virtual console for Xen, hvc0.
However, reconnecting to Chimaera via ssh and VNC worked as normal.

The only services running under runsvdir are getty and ssh.
To set up hvc0 as the console, I copied the set up for tty1.

cd /etc/sv/
cp -rp getty-tty1/ getty-hvc0
cd getty-hvc0

edit run and finish to change tty1 to hvc0

rm supervise
ln -s /run/runit/supervise/getty-hvc0 supervise
cd /etc/sv
runsv getty-hvc0

This does not return, which I believe is correct, and the login prompt now appears on the console (the window on Dom0)

To set it up to work automatically needs it linked in to /etc/service

cd /etc/service
ln -s /etc/sv/getty-hvc0/ .

The other glitch is shutting it down.

Using LXQt to shutdown closes the LXQt window but I was still logged in on the console.

shutdown -hH now

did not shut it down.
Coming back to Dom0 I was able to give the command to Xen to shut it down

xl shutdown chimeara

which did work.
Having booted it up again, I was able to shut down with

init 0

I noticed that /sbin/shutdown is a link to /lib/runit/shutdown

Geoff

Lorenzo

It worked fine for me on both testing devuan and devuan beowulf, can't say if the others it works well on.

But, on devuan beowulf when you switch from openrc to runit and add runit-init and then try to go back for some reason to openrc, I once had some issues on beowulf.  heh... weird stuff. 

If you intend to install runit-init + runit the moment you install devuan beowulf, don't install openrc right off the bat. Unless you know something I don't...

That kind of thing caused me some issues once, where dependency hell got in the way...

PS, in my experience, runit + runit-init cut my boot time in half.  and shutdown happens in a 1/3 less time if I recall correctly.

I played a bit with Runit on Void, and contrary to many comments I read, this is a full featured Runit. The few directories changes are just to be compliant with Filesystem Hierarchy Standard.

When  comments say that Runit support is not complete in Debian, this is because these persons wait a full distro that choose Runit as a main init system and provide all init scripts for it. But as I think Devuan is a "base" for other distributions as Debian is and its goal is to stay an "independent" init distro, it is unlikely they can maintain init scripts for Openrc and Runit in addition to Sysv scripts.

So yes Runit in Debian just "embed" sysv scripts, but this is not a Debian hack, Debian just did what is described in Runit manual, in "Step 5: Service migration chapter".

So if the goal is to use sv to manage all services, do not choose Debian/Devuan, otherwise it is fine for me.

(RTFM) will have to do some reading along the way to also check why sv stopped $service still keeps a `runsv $service` & `svlogd -tt $service` running.
and also lookup runit scripts for more daemons.

This permission issue is new to me but is bad enough that I need to double check if this can be reproduced in Debian

I can confirm that the user needs to be added to the input group to get the keyboard &c working in Debian buster if an alternative init system is used. I've tested with runit-init, sysvinit and openrc-init as PID1.

In my test elogind was installed and the elogin-daemon process was running.

This permission issue is new to me but is bad enough that I need to double check if this can be reproduced in Debian and possibly fix there. I'm not sure though, could be also something that is caused by some Debian-Devuan delta.

Besides sysvinit-core, was any other package removed?
I'm not surprised that Xorg is not working with runit, without elogind or any other means that gives permission on input devices to your user, but what puzzles me is how was working with sysvinit..

Lorenzo

using a dm is a must when switching to runit (to avoid problems that needs manual changes otherwise).

Yes, I've just confirmed that — the user must be in the input group if a display manager isn't used.

I've added a note to the OP.