How complete is dinit package?

[notramo]

I'm interested in switching to dinit. How complete is the Void package? If I install it and remove runit, is it able to boot up the system, or do I have to write some filesystem mounting logic, for e.g. ZFS? I don't care about docker, bluetoothd, or similar services that provide extra functionality, I only want to be able to log in to a dinit-booted system so I can configure the rest of the services.

[classabbyamp]

@dkwo

[dkwo]

It comes with upstream's reference services.
https://github.com/davmac314/dinit/blob/master/doc/linux/DINIT-AS-INIT.md suggest not to replace /sbin/init, but change kernel cmdline.
I have not tested this myself, and you may need to make some changes.
@dataCobra in a prior update said:

I've setup a VM with dinit as system init and user init successfully.
The service files in the doc folder need a bit of changing

[notramo]

The example scripts really only serve as an example, it's mostly incompatible with Void. It should be able to boot, but it's not designed for Void systems, e.g. it might accidentally run something as root when it's meant to be run as an unprivileged user in Void. Hostname, timezone, etc. changes are handled differently in Void.

My current setup boots with runit and the only enabled runit services are agetty-tty* and a system-wide dinit. All other services e.g. dbus, seatd, etc. are started by dinit (I converted the Void runit scripts to dinit). However, shutdown and sleep are still handled by runit. I also use vlogger for logging as svlogd can rotate the logs, but it's not the best solution as it still relies on runit. However, dinit can quite conveniently pipe the output to a logger service, supervise the logger and retains the log messages while the logger is restarted in case of a crash.

I want to switch the logging to a different solution before I switch the early boot scripts.

[ahesford]

The package should be complete. We intend to include everything that upstream provides. However, what you really want to know is whether the package is sufficient to facilitate a replacement of runit. It is not. We do not plan to support easy substitution of one service manager with another. If you want to do this, you will (as you observed) need to reimplement all of the services that you need and address all early-setup tasks now handled by runit core services.

Given that dinit now supports service templates, you may find the lowest-effort path to be writing templates that will invoke runit core services and regular system services. Whatever path you take, it will require expertise in the administration of Unix systems and a familiarity with the Void boot process.