Systemd Can Now Install Your OS, Replace sudo, and Boot Without GRUB

April 2010. Lennart Poettering publishes a blog post titled “Rethinking PID 1,” proposing an init system that parallelises boot through socket activation. June 2026. systemd 261 ships with an OS installer (systemd-sysinstall), a cloud metadata service (systemd-imdsd), a storage management tool (storagectl), and support for the Linux kernel’s Live Update Orchestrator for rebootless upgrades.

The init system that was supposed to just launch daemons is now a full-fledged operating system platform. And it has no serious competition left.

The init war is over — systemd won

The last credible rival was Upstart, the event-based init system Canonical developed for Ubuntu. It was abandoned in 2014 when Ubuntu switched to systemd, never progressing past version 1.13. SysVinit survives in a handful of minimalist distributions (Alpine Linux, Devuan, Gentoo with OpenRC), but its last major release (3.10, October 2024) added… better compatibility with systemd’s machinectl command.

GNU Shepherd 1.0, released in December 2024 after 21 years in development, is used by GuixSD. It remains confined to the Guile Scheme ecosystem. Alternatives like runit (Void Linux) and s6 (Artix) occupy niches — none ships as the default on a major distribution.

The scorecard: 100% of mainstream Linux distributions (Fedora, Ubuntu, Debian, RHEL, openSUSE, Arch Linux) run systemd as PID 1. openSUSE Tumbleweed even began migrating from GRUB to systemd-boot in 2024 — a sign that the ecosystem is expanding well beyond init.

What systemd does today (beyond launching services)

Systemd hasn’t been “just an init system” for years. It’s a suite of 70+ binaries managing entire layers of the operating system:

• systemd-boot — a minimal UEFI bootloader, now being tested by Debian and adopted by openSUSE
• systemd-networkd — declarative network configuration with ModemManager integration since v260
• systemd-resolved — DNS resolver with DNSSEC, DNS over TLS, and per-interface split-DNS
• systemd-homed — portable, LUKS-encrypted home directories that migrate between machines
• systemd-sysext — system extensions for immutable OS images (overlay /usr/ without rebuilding the image)
• systemd-portabled — portable containerised services, usable without privileges since v260
• systemd-repart — reproducible declarative partitioning for disk images
• systemd-nspawn and systemd-vmspawn — lightweight containers and VMs managed as systemd services
• systemd-journald — structured binary logging with cryptographic signing
• systemd-timedated, hostnamed, localed, machined — standardised management of time, hostnames, locales, and virtual machines

The shift is that these components are no longer optional experiments: they ship enabled by default on Fedora, are integrated into GNOME through Germany’s Sovereign Tech Fund grants, and are landing in Debian.

Varlink is replacing D-Bus — and that’s a good thing

The most significant architectural decision of the past two years is invisible to end users. Since systemd 257 (December 2024), the sd-json and sd-varlink libraries are public APIs of libsystemd.

Varlink is an IPC protocol that uses JSON for marshalling, with no central broker (no dbus-daemon), no XML interface files, and none of D-Bus’s complex authentication model. The varlinkctl command lets you interact with Varlink services from the terminal:

varlinkctl call io.systemd.Manager ListUnits '{}'

Why this matters: D-Bus is 20 years old, its system bus is a bottleneck, and the attempts to move it into the kernel (KDBUS, BUS1) failed. Varlink is the clean exit — simpler, faster for small messages, and already used for shutdown calls, job management, and unit queries in systemd 261. The direction of travel is clear: more Varlink, less D-Bus.

run0: saying goodbye to sudo is no longer a joke

Introduced in systemd 256 (June 2024), run0 is a symlink to systemd-run that replaces sudo without being SUID. Instead of inheriting the caller’s execution context, it asks the service manager (PID 1) to spawn the command under the target UID in an isolated PTY. The implications:

• No setuid. The binary doesn’t carry the SUID bit — the attack surface shrinks dramatically.
• Clean context. The invoked command sees neither the caller’s environment variables nor their file descriptors.
• Visual indicator. The terminal background turns reddish during the privileged session — a constant reminder that you’re elevated.

run0 apt update        # Runs apt as root, terminal tinted red
run0 -- bash            # Root shell in isolated context

This isn’t a gimmick: run0 eliminates the class of environment-inheritance vulnerabilities that plagued sudo for 30 years (CVE-2023-22809, CVE-2023-27320, to name two).

UKI, Secure Boot, and verified boot chains

Unified Kernel Image (UKI) support continues to mature. A UKI combines the Linux kernel, initramfs, kernel command line, and Secure Boot signatures into a single signed PE binary — which systemd-boot can load and verify in one step.

systemd 257 added the systemd-sbsign tool for signing EFI PE binaries, and systemd-keyutil to centralise certificate operations. systemd 258 allows embedding UEFI firmware images inside UKIs for confidential computing use cases. systemd 261 adds RestrictFileSystemAccess=, which uses a BPF LSM program to restrict execution to binaries residing on a dm-verity-signed filesystem.

In practice: a complete trust chain from firmware to userspace, with no GRUB, no shim, no moving parts.

systemd-sysinstall: the installer that didn’t exist

systemd 261 (June 2026) introduces systemd-sysinstall, a text-mode installer that leverages systemd-repart for partitioning, systemd credentials for configuration, and copies the OS from a temporary boot medium. The reasoning: if systemd already handles partitioning, networking, encryption, and user management, why hand off OS installation to a third-party tool?

It’s not meant to compete with Anaconda or Calamares — it’s a building block for minimal images, appliances, and automated deployments where a graphical installer is dead weight.

mstack, IMDSD, storagectl: the new arrivals

The feature cadence shows no sign of slowing down:

• mstack (v260) defines a .mstack/ directory specification that behaves like a structured OverlayFS, designed for containers and lightweight sandboxing. systemd-mstack is the accompanying CLI tool.
• systemd-imdsd (v261) unifies access to cloud instance metadata (AWS EC2, Azure, GCP, Oracle Cloud, Hetzner, Tencent) through a standard interface. No more per-provider scripting to fetch the local IP or SSH keys.
• storagectl (v261) exposes storage resources through a unified Varlink API for managed user storage.

What got removed: cgroup v1 and SysVinit scripts

Systemd is also cleaning house. systemd 258 (July 2025) dropped cgroup v1 support. systemd 260 (March 2026) removed System V service script support. The minimum kernel requirement moved from Linux 5.4 to 5.10.

The message is unambiguous: systemd no longer provides backward compatibility with pre-2015 infrastructure. If you still have /etc/init.d/ scripts, you’ve had a decade to migrate.

Verdict: systemd is the platform, not the alternative

There is no more “systemd vs X” debate. The market has spoken: every major distribution converged, alternatives are confined to niches, and systemd keeps absorbing the layers around it — boot, DNS, networking, containers, OS installation, cloud metadata.

For a Linux administrator in 2026:

• If you manage a fleet of servers, learn systemd-networkd and systemd-resolved — they replace NetworkManager and resolv.conf on the server side.
• If you deploy to public cloud, adopt systemd-imdsd to unify metadata access across providers.
• If you work on desktops, test run0 as a sudo replacement — the security gain is real, with zero habit change.
• If you build immutable images, combine systemd-sysext, systemd-repart, and UKI — you eliminate an entire class of boot and update problems.

Systemd won the init system war. It’s now winning the system platform war.

References

• systemd 261 release notes — June 19, 2026
• systemd 260 release notes — March 17, 2026
• systemd 258-rc1 — Phoronix — July 23, 2025
• systemd 257 released — Phoronix — December 10, 2024
• systemd 2024 highlights — Phoronix — December 25, 2024
• systemd run0 — Phoronix — April 30, 2024
• Systemd Looking At A Future With More Varlink — Phoronix — September 28, 2024
• Rethinking PID 1 — Lennart Poettering — April 30, 2010
• ArchWiki: systemd — accessed July 2026
• GNU Shepherd 1.0 — Phoronix — December 9, 2024