Debian 8 "Jessie" OpenRC Conversion



Debian packages an excellent dependency-based init system 1 named OpenRC. This page covers how to easily convert Debian 8 "Jessie"2 to use OpenRC3 + SysVInit's PID1 /sbin/init instead of the default systemd init, init scripts, service supervisor, etc., etc. The question arose on a mailing list:



Date: Thu, 6 Aug 2015 12:40:56 -0700
From: Rick Moen <rick@linuxmafia.com>
To: luv-main@luv.asn.au
Subject: Re: laptop sleep on closing lid

Quoting Mark Trickett:

> The fact [systemd] does binary logs is a very major defect in my opinion
> and experience.

For completeness, I'll note that it's pretty easy to disable handoff of logging information to systemd-journald and substitute a handoff to rsyslog or syslog-ng, instead. For example, Debian's systemd package defaults to rsyslog as system logger, not systemd-journald.

> I noted that it is possible to put OpenRC on Debian 8. I shall need to
> do a bit of research. Some notes from you and/or Rick Moen would be
> very appreciated.


OpenRC Installation / Systemd Removal Recipe:



At the console

Measures to prevent package systemd from being installed in the future via dependencies:

echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd
echo -e '\n\nPackage: *systemd*\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd

If your system uses multiarch (32- and 64-bit packages), do this too, to pin the 64-bit version of systemd:

echo -e '\nPackage: systemd:amd64\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd

In other multiarch cases where amd64 is the default architecture, you may have to pin the i386 package:

echo -e '\nPackage: systemd:i386\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd

You are done.

Above recipe is adapted from a without-systemd.org wiki article, and gratefully acknowledged. See that page for some other ideas.



A quickstart guide to OpenRC administration would be nice, and if time permits I might write one. So far, notfoss's OpenRC blog post looks most useful (ignoring some details specific to Arch Linux), and the Arch Linux wiki OpenRC page is also some help. The Gentoo wiki's OpenRC page is authoritative, but verbose, (IMO) murky, and (IMO) too interwoven with Gentoo-specific bits inapplicable to Debian.



Above is from my contemporaneous notes of changeover conducted in a VirtualBox VM (x86_64 arch), so I'm reasonably confident they're complete and correct. Getting rid of the systemd-entangled udev/libudev1 code, and getting any replacement (eudev, mdev, vdev) to work with the latest xserver-xorg packages, is a further experiment I've not yet undertaken. (The Devuan fork of Debian is doing great work with vdev, to make that practical.)

I strongly encourage using VM (virtual machine) software as a vehicle for system software experiments. Among other advantages, the VM framework lets you checkpoint the entire guest OS just before any such experiment, so you can revert with ease if your experiment fails, i.e., you needn't either risk a real system nor risk even having to reinstall a guest OS. Without the VirtualBox trick, I'm not sure I'd have chanced this test conversion, as the conditioned fear of destroying systems kicks in. Point is, VM software allows you to set aside this otherwise commendable caution without risk.

A few things such as bsdutils and util-linux have started to depend on libsystemd0, but that seems entirely harmless. I respect the developers behind Devuan, and know they have done & are doing a great deal more than just omitting systemd, but it seems to me that there was a lot of hyperventilating over mere presence of a lib that's doing zero harm just sitting there. If worried about it, run a nightly cronjob that ensures /lib/[$ARCH]-linux-gnu/libsystemd.so.* is set to 000 permissions.

In my experience and for my use-case (eschewing big DEs and NetworkManager — detailed below), my instructions completely suffice to create fully functional Debian 8 "Jessie" with my choice of init — without any need to fork the distribution.




Which Debian 8 "Jessie" Packages Depend on Package Systemd:



I spent time studying the dependency graph of Debian 8 "Jessie" packages and metapackages — to find which require (directly or indirectly) the systemd package (referred to in the paragraph below as being "adversely affected").

Summary: All of these Desktop Environments as a whole (as kitchen-sink metapackages) are adversely affected: GNOME, MATE, Cinnamon, KDE, and Razor-qt. You will certainly be able to install almost all applications from those DEs, but not the DEs as a whole. The hplip printing software for HP printers is adversely affected (but see workaround in the next section), because that package is (seemingly pointlessly) packaged to require policykit-1 (that requires libpam-systemd, that requires systemd). network-manager (from GNOME) and a number of its variant forms are adversely affected. And a couple of dozen individual applications are adversely affected. Attempting to install those packages/metapackages will result in apt-get erroring with a "Some packages cannot be installed" diagnostic citing a broken dependency — because of the above recipe's package-pinning via /etc/apt/preferences.d/systemd that bars installation of systemd.

Unaffected DEs include Xfce, LXDE, LXQt (not yet in Debian-stable), Enlightenment E17, fvwm-crystal, and Window Maker.

Here are all Debian 8 "Jessie" packages/metapackages with dependencies traceable to the systemd package4:

  1. Depends directly on systemd: libpam-systemd, systemd-dbg, systemd-sysv, systemd-ui

  2. Pre-Depends directly on systemd: gummiboot, systemd-sysv

  3. Depends on systemd-sysv: systemd-cron, libpam-systemd

  4. Depends on libpam-systemd: policykit-1, gnome-bluetooth, udisks2, gdm3, gnome-settings-daemon, network-manager

  5. Depends on systemd-ui: systemd-gui

  6. Depends on policykit-1: aptdaemon, colord, ettercap-graphical, firewall-applet, firewalld, fprintd, gdm3, gnome-color-manager, gnome-system-log, gufw, hplip, libmatepolkit-dev, libpolkit-gtk-mate-1-0, libvirt-daemon-system, mate-polkit, mate-power-manager, nautilus-dropbox, network-manager, packagekit, policykit-1-gnome, polkit-kde-1, python3-plainbox, razorqt-policykit-agent

  7. Depends on libpolkit-gtk-mate-1-0: libpolit-gtk-mate-1-0-dbg, libmatepolkit-dev, mate-system-tools

  8. Depends on udisks2: python3-checkbox-support, daisy-player, gnome-disk-utility, gvfs-daemons, k3b, kde-plasma-desktop, kde-plasma-netbook

  9. Depends on gdm3: gnome-core, xfswitch-plugin

  10. Depends on gnome-core: gnome, task-gnome-desktop

  11. Depends on network-manager: modem-manager-gui, network-manager-dbg, network-manager-gnome, network-manager-openconnect, network-manager-strongswan, plasma-nm, python-networkmanager, sucrose-0.96, sucrose-0.98

  12. Depends on packagekit: apper, browser-plugin-packagekit, gnome-packagekit-session, gstreamer1.0-packagekit, listaller, packagekit-command-not-found, packagekit-dbg, packagekit-tools

  13. Depends on network-manager-gnome: cinnamon, design-desktop, gnome, parl-desktop

  14. Depends on network-manager-openconnect: network-manager-openconnect-gnome

  15. Depends on policykit-1-gnome: apper, cinnamon, gconf-editor, gnome-session-flashback, gnome-system-tools, gnome-core, network-manager-gnome

  16. Depends on gnome-settings-daemon: gdm3, cinnamon, gnome-control-center, gnome-core gnome-music, gnome-packagekit-session, gnome-power-manager, gnome-session, gnome-session-flashback, gnome-shell, indicator-session

  17. Depends on gnome-bluetooth: gnome-core, gnome-user-share

  18. Depends on gnome-disk-utility: gnome-core

  19. Depends on colord: gnome-color-manager, gnome-control-center

  20. Depends on gnome-color-manager: gnome

  21. Depends on gnome-system-log: gnome-core

  22. Depends on apper: apper-dbg

  23. Depends on daisy-player: daisy-player-dbg

  24. Depends on mate-polkit: gnome-system-tools, libmatepolkit-dev, mate-desktop-environment-core, mate-panel, mate-session-manager, mate-system-tools

  25. Depends on mate-system-tools: mate-system-tools-dbg

  26. Depends on kde-plasma-desktop: kde-full, kde-standard

  27. Depends on kde-plasma-netbook: kde-full, kde-standard

  28. Depends on polkit-kde-1: apper, kde-standard

  29. Depends on k3b: k3b-i18n

  30. Depends on razorqt-policykit-agent: razorqt

  31. Depends on ettercap-graphical: ettercap-dbg

  32. Depends on firewalld: firewall-applet, freedombox-setup

  33. Depends on gvfs-daemons: gvfs-backends

  34. Depends on hplip: hplip-data, hplip-gui, printer-driver-postscript-hp

  35. Depends on python3-plainbox: python3-checkbox-ng

  36. Depends on python3-checkbox-support: pythong3-checkbox-ng, plainbox-provider-resource-generic






Overcoming Dependency Obstacles



Let's say you want package hplip (printing software for HP printers), a common use-case. On a systemd-free Debian 8 "Jessie" system, package installation unfortunately is blocked by dependency chain hplip -> policykit-1 -> libpam-systemd -> systemd. What to do?

In that one case, the answer is that you only think you need the hplip package, which is an omnibus desktop-oriented packaging of the HPIJS and HPLIP drivers, and therefore includes GNOME-dependency hooks. The parts you want are in more-focussed subcomponent packages printer-driver-hpcups and printer-driver-hpijs, working with CUPS or your preferred print engine.

To pick another case, suppose you wish to use the daisy-player package to play talking books for the visually impaired. That package is built, seemingly gratuitously, to require udisks2, so installation is blocked by dependency chain daisy-player -> udisks2 -> libpam-systemd -> systemd. My best advice is to rebuild the package locally, omitting the gratuitous dependency on Freedesktop.org's intrusive udisks2 software.

In other cases, your best bet might be to construct a deb package using the upstream source tarball, using the superb debhelper utility to guide you through the process.

In still other cases, you may find a suitable unofficial deb package in a third-party apt repository. (Be wary of security implications of using third-party software sources.)

You could fall back on the old-school option of compiling a non-packaged installation, placed into /usr/local/*, starting from the upstream maintainer's source code. (Again, there are security concerns to beware of.) However, I would suggest always using debhelper to create a true local deb package, so that your system's package management knows what exists, can manage its dependencies, and can remove it cleanly upon request.

The equivs package can sometimes finesse a dependency if you judge it to be bogus: equivs provides a mechanism for convincing Debian a package is installed even though it is not.

Last, if you wish to supplement Debian's official repositories with those of the Devuan fork, there are instructions for doing so. That change is reported to restore ability to use software needing Freedesktop.org's udisks2 and policykit system software. Presumably, Devuan's versions of the latter lack a dependency on systemd.


1 Init system, but lacking an init. OpenRC provides all functions needed to control startup processes, except for the /sbin/init process (the actual init process) forked from your booting kernel as master process with PID1. This Web page uses SysVInit's /sbin/init as the Debian system's PID1 init process, because Debian 8 "Jessie" happens to install it. However, any other init will also do, e.g, FreeBSD's init and many others.

OpenRC includes cgroup (control group) management on the Linux kernel (cgroups being Linux-specific). It can do service supervision in conjunction with Runit

A history of modern init systems mentions that OpenRC is known to be runnable from Busybox init + mdev, which sounds intriguing, especially for servers, possibly with the minirc script. (See tutorial, background, instructions.)

I owe thanks to Steve Litt for pointing out that OpenRC requires a separate PID1 /sbin/init that spawns it and then permits OpenRC to run/control all subsequent services. Through dumb luck, my test conversion of Debian 8 "Jessie" to OpenRC in a VM benefited from Debian's installer default-installing the sysvinit package, thereby providing SysVinit's traditional /sbin/init binary. SysVInit's /sbin/init has the advantage of being a well-audited and reasonably scoped init binary, to which nobody really objects, whereas SysVInit's init scripts are widely deemed antiquated and no longer able to cope well with the needs of increasingly dynamic Linux system environments, exactly the area where OpenRC or your choice of other modern but modestly-scoped init systems (e.g., runit, s6, Epoch) wins without systemd's drawbacks of scope creep, dependency nightmares, intrusiveness, and hostile upstream maintainers. Other, even smaller init binaries can be used in its place. At this writing, the Debian OpenRC package lacks dependency metadata to guarantee a PID1 init package being also present, so that detail is worth double-checking manually.

During recent controversies over systemd, there's been much confusion between inits (the PID1 system process binaries), init script packages, service managers, and init systems (composite of two or more of the first three categories). I highly recommend reading the Arch Linux wiki's init page to help untangle these concepts. Notice that what I call an init system (a composite of two or more categories), Arch Linux calls "init (integrated)".

2 And, one hopes, Debian 9 "Stretch", Debian 10 "Buster", and later.

3 Or to any of the other init systems' packages in Debian 8 "Jessie": sysvinit, upstart, or runit, in addition to the openrc package. (dumb-init can be fetched from Debian-unstable and is a simple init and process supervisor intended for software-container setups.) The nosh init system (init, init scripts, and service manager) is also available directly from its author as binary packages for Debian. Conversion to OpenRC is the only one I've so far tested, but there's no reason my simple technique shouldn't work to change over to any of those others.

Also worth investigating albeit not yet Debian-packaged, and filling one or more of the roles init system, init (PID1), or service supervisor: ninit, sinit (suckless init), minit, finit, Epoch, uinit, busybox-init, anopa, eINIT, myinit, daemontools-encore, freedt, procer, watchman, s6-rc. Packaged by Debian: runit, supervisord, daemontools, monit, restartd. Third-party packaged for Debian: s6 (packaged), perp (packaged), nosh (packaged).

4 Gleaned mostly via commands like this: "apt-cache --no-pre-depends --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances rdepends libpam-systemd"



Copyright (C) 2017 Josef Grosch, <jgrosch@gmail.com> — though I have borrowed publicly-posted material from other helpers elsewhere on the Internet, and acknowledge those I can re-find.

The orignial copy of this is from my good friend, Rick Moen, a mench among men.

Verbatim copying, distribution, and display of this entire article (page) are permitted in any medium, provided this notice is preserved. Alternatively, you may create derivative works of any sort for any purpose, provided your versions contain no attribution to me, and that you assert your own authorship (and not mine) in every practical medium.