A real Linux
for phones
and other mobile devices
A real Linux distribution for phones
and other mobile devices
For Linux enthusiasts
Latest news: The Road to systemd

Adding systemd to postmarketOS

March 05, 2024 7 min. read

A OnePlus 6 running postmarketOS with tmux showing systemctl status and hostnamectl from systemd, surrounded by a GNOME and a KDE gear

You heard it here first folks: systemd is coming to postmarketOS! As a mobile oriented OS, our main goal has always been to work for everyone. From technical folks to casual users. postmarketOS should have all the benefits you expect from a Linux based distribution, such as being free software, respecting your privacy, getting updates until your device physically breaks, respecting your attention and not shoving advertisements in your face. Your phone should be a tool you use, not the other way around.

This is of course not an easy task, one of the main blockers we found as we collaborate more closely with KDE and GNOME developers is that they have a hard time with our OpenRC-based stack. In order to get KDE and GNOME working at all, we use a lot of systemd polyfills on top of OpenRC. So while we are technically "not using systemd", in practice we already do use a large chunk of its components to get KDE and GNOME running, just different versions of those components. While we are very grateful for everybody who works on these polyfills, we must point out that most aren't a full replacement, and take additional effort to support and maintain. As much as we might want to romanticise the idea of spending 6, 12, 24 months attempting to come up with an even vaguely competitive alternative to systemd, we would quite simply rather be working on making postmarketOS better.

So, after first seriously considering this idea almost a year ago, we have made the decision to fix these incompatibilities and friction by just providing a version of postmarketOS that builds on top of systemd. We are happy to announce that it works, and we already have proof-of-concept images available that you can try out right now!

The proof-of-concept images were made only for a few devices, as they had to be built manually. You can also build your own by following the steps in the issue below, or wait for us to get this integrated into the build system. The patches that made the proof-of-concept possible currently live in branches of pmaports.git and pmbootstrap.git, and will go through the usual review process before we merge them. Read the following issue for an overview of building your own images, what tasks still need to be done and where you could help out if you are interested: #2632

As with text editors, some people are really passionate about their favorite init systems. When discussing this announcement, please keep a friendly tone. Remember that we all share the love for free and open source software, and that our communities work best if we focus on shared values instead of fighting over what implementations to use.

This has been a pretty huge undertaking for us - as part of our effort to sustainably grow postmarketOS into the mobile OS we all want it to be. If you like what we do, please consider joining our OpenCollective.


What about OpenRC, s6, runit, dinit?

For the die-hard fans of OpenRC and people who just have other use cases, such as building a very minimal system that doesn't need all the polyfills anyway: Don't worry, as long as OpenRC is in Alpine Linux (on which postmarketOS is based), you will still be able to select it in pmbootstrap when building your own images. Here is how it will look like, a new question in pmbootstrap init:

pmbootstrap init asks whether the user wants to use systemd or not

We have shown this announcement to Sxmo maintainers in advance, and they decided to stay with OpenRC. So pre-built images of Sxmo will continue to be OpenRC based and we plan to make it so that pmbootstrap doesn't ask about systemd after choosing Sxmo as UI.

Besides OpenRC, s6, runit and dinit are in Alpine. Right now we don't have any UI using them in postmarketOS, but in theory they could be used as well.

Is Alpine cool with this?

Of course we also considered how this announcement would impact our (very good!) relationship with Alpine Linux, which doesn't ship systemd. Even though we are adding systemd, we certainly aren't planning to move away from Alpine. We use Alpine for its incredibly fast package manager, the very readable and easy to write APKBUILD package descriptions (that neatly allow splitting into subpackages), the small/simple/secure musl libc, the awesome stable release schedule, and just the huge selection of packages available in their repos. We have shared this blog post with the Alpine devs before this publication, and we hope that they understand our reasoning.

What's wrong with the polyfills?

Wikipedia describes the term polyfill as "code that implements a feature of the development environment that does not natively support the feature". Here is an overview of the ones we have in our stack for compatibility with systemd, how maintained they are and what they are missing.

A table of polyfills currently in use in postmarketOS.
maintained, implements all features: openrc-settingsd, eudev;
maintained, missing features: elogind, superd, logbookd;
unmaintained: waked, corecollector
  • openrc-settingsd (hostnamed, localed, timedated): provides various D-Bus APIs that allow UIs to change locales, timezones etc. Originally, this was maintained by Gentoo's GNOME desktop team until we took over maintenance in 2021. Pablo wrote about it: "Luca and me have spent some precious time on fixing crashes and old legacy code on that, which we'd happily spend somewhere else. For a long time it would just crash upon trying to change language on first boot, and things like that."

  • eudev (udev): userspace devfs daemon, forked from systemd code.

What about systemd and musl libc?

Alpine Linux is based on musl libc, whereas systemd officially only supports glibc. Our current understanding having spoken to systemd developers is that we should be able to find a path that brings us much closer to upstream, if not entirely.

What fancy new features will we get with systemd?

What does this mean for device maintainers?

For devices where we build KDE- and GNOME-based images, any custom services will need a systemd version. We plan to adjust the existing device ports as part of integrating systemd.