The only thing that didn't work for me there was networking.  There I had to add my network interface to the default runlevel, then I was off to the races.

# rc-update add <my interface's start script in /etc/init.d> default

I pre-checked my RPi, and saw that network-manager was already in the default runlevel.  When I rebooted, it Just Worked(tm).

The only thing I did extra was to ensure that my serial console would work (in case networking didn't come up) by adapting the Gentoo instructions:

# ln -s /etc/init.d/agetty /etc/init.d/agetty.console && rc-update add agetty.console default

I literally just did all this, so if my RPi blows up later today I will post an update.

HTH!

a fake init in this context, similar to runit  (frankeninits).

As someone who's gone through quite a bit of keyboard-snapping frustration with runit, I think this isn't an accurate assessment. runit does use sysVinit service scripts to fill in for gaps in support, but it's a genuine init system with a solid core.

In ceres now 21 packages have native runit integration

the keyword is "Ceres"

I've an impression that openrc scripts are simplier than runit scripts (I don't have experience with runit). One more advantage of openrc is that pipewire can be launched as user services and audio switchs automatically when hardware is changed.

Devuan only supports SysVinit, and OpenRC is considered a fake init in this context, similar to runit  (frankeninits). This means that even if I choose OpenRC during installation, the boot process will still be managed by SysVinit.

I don't think that's fair about runit. In ceres now 21 packages have native runit integration for their daemons and the runit-services package adds 55 additional services (of which 2 were added today). Most of the services on my laptop are now covered in stage 2.

The single-shot/startup actions (stage 1) are not so well covered but I think some commonality with other inits makes sense for these things.

OpenRC I think is held back by not having a second directory where openrc's own interpreter can be used to override the initscript fallbacks. I suspect that would be a useful improvement for the debian package, although this is guesswork as I don't use OpenRC and don't plan to.

Devuan only supports SysVinit, and OpenRC is considered a fake init in this context, similar to runit  (frankeninits). This means that even if I choose OpenRC during installation, the boot process will still be managed by SysVinit.

I've tried to create a pure OpenRC Devuan system but did not succeed. I added init=/usr/sbin/openrc-init to GRUB_CMDLINE_LINUX_DEFAULT in grub. The system starts and shows:

```
Setting up keyboard layout...done.
Starting swap...done.
Starting early crypto files...nvme01p5 crypt (running)...done.
Checking remaining crypto files...32/131072 files, 53216/54288 blocks
crypt file systems: fsck.fat 4.2 (2021-01-31)
boot:/dev/block/33:212 files, 6948/13682 clusters
done.
Cleaning up temporary crypto files...
Activating local filesystem swaps...if any...done.
Cleaning up temporary Swap, if any...done.
Starting up ArmorLoading applications profiles...done.
Starting Setting kernel variables: systl...done.
Configuring network interfaces...done.
Cleaning up temporary firewall rules...done.
Starting netfilter boot and shadow times into wtmpdb:
ntpd-update-boot.nb
Starting system message bus: dbus.
Starting default runtime cron daemon: elogind.
Starting anacron (hypothetical) service.
Starting rc-modules: bluetooth, network manager.
Starting console command scheduler: crond.
Starting network connection manager: NetworkManager.
```

Then it gets stuck.
/etc/runlevels/boot is empty. I've tried to fill it with symlinks, but that did not help.