Removing conflicts of init system

Josh Triplett josh at
Fri Dec 21 19:31:24 GMT 2018

Dmitry Bogatov wrote:
> [ I am not subscribed. Please keep me in CC. ]

[I'm assuming that CCing the various init system
addresses suffices?]

> Currently, init system packages (sysvinit-core, runit-init,
> systemd-sysv) are mutually exclusive -- each of them provides,
> among other, /sbin/init file and as such, conflicts with rest.
> This scheme has following drawbacks:
>  * switching between init systems is destructive:
>    once you switch, old /sbin/init is gone; should things go wrong, you
>    have no easy recover via init=/sbin/old-init kernel option.
>    Side note: switching from systemd is more safe, since systemd-sysv
>    provides only link to /lib/systemd.

sysvinit works similarly, with /lib/sysvinit/init. And GRUB has built-in
support for these. See /etc/grub.d/10_linux; if you have more than one
init system package installed, you will get separate boot options to
boot each of the inits that /sbin/init doesn't link to.

You might consider submitting a patch to GRUB to add runit to that list,
or better yet making that behavior look for symlinks in /lib/inits/ or
similar and make an entry for every link that doesn't match /sbin/init.
(If you do so with fallbacks to the existing entries for systemd and
sysvinit, that'll make a transition simpler, and GRUB can remove the
fallbacks as soon as systemd and sysvinit add links in /lib/inits/.)

Does that sound reasonable?

(Meanwhile, I don't think it's necessarily a good idea to handle
/sbin/init and associated programs with alternatives, not least of which
because of the complications of switching the running system's init.)

More information about the Debian-init-diversity mailing list