systemd 260: The End of System V and a New Era for Linux Init
systemd 260: The End of System V and a New Era for Linux Init
- Apple’s Native Linux Container Tool Has Arrived — But Can It Really Replace Docker?
- 60% of MD5 Password Hashes Can Be Cracked in Under an Hour with a Single GPU
- Dirty Frag: Root Access on Every Major Linux Distribution — No Patch, No Warning
- Proton Mail: Data Transferred to FBI Again!
- How Close Are Quantum Computers to Breaking RSA-2048?
- What is the best alternative to Microsoft Office?
systemd 260: The End of System V,
and a New Era for Linux Init
After three months of development and four release candidates, systemd 260 shipped on March 17, 2026 — cutting the last thread of System V init compatibility and delivering a slate of modern capabilities for containers, cloud, and high-performance Linux environments.
From First Candidate to Stable
tpm2_id udev built-in to fix slow boots; confirmed FANCY_NAME Unicode support; added enqueue-marked verb.System V Compatibility: Fully and Finally Gone
The most disruptive change in systemd 260 is the permanent, unconditional removal of System V init script support. After more than a decade of carrying the compatibility layer as a courtesy, the following components are deleted entirely:
systemd-sysv-generator— the tool that auto-translated/etc/init.dscripts into transient unit files at boot.systemd-rc-local-generatorandrc-local.service— the legacy rc.local execution path.systemd-sysv-install— the hook used bysystemctl enable/disable/is-enabledfor SysV scripts.
“This is not a soft deprecation or a staged rollout — the components are deleted, and the fallback is gone for good.”
Any service that has not been migrated to a native .service unit file will silently fail or refuse to start after upgrading. Administrators running third-party software — older database installers, legacy monitoring agents, or enterprise middleware — should audit all running services with systemctl list-units --type=service before upgrading.
Kernel & Dependency Floor Raised
The official release notes confirm the previous kernel baseline was Linux 5.4; it has been raised to 5.10, with 5.14 or the 6.6 LTS series recommended for full functionality. Code supporting kernels older than 5.10 has been removed entirely.
Beyond the kernel, several core library dependencies have been bumped:
- glibc 2.31 → 2.34
- OpenSSL 2.x → 3.0
- Python minimum → 3.9
- libseccomp 2.3.1 → 2.4.0
- libidn support dropped — IDN now requires libidn2
Enterprise distributions such as RHEL derivatives and LTS Ubuntu builds are expected to delay adopting systemd 260. Rolling-release distributions like Arch Linux and Fedora will absorb it quickly. Verify your kernel version before scheduling an upgrade.
What systemd 260 Adds
-
mstack & systemd-mstack — A new mechanism for composing OverlayFS and bind-mount setups using a structured
.mstack/directory layout. A companion CLI tool,systemd-mstack, allows interactive management. Particularly useful for containerized and sandboxed service deployments. -
CPUSchedulingPolicy=ext — Services can now opt in to the
SCHED_EXTscheduler, enabling extensible, BPF-programmable CPU scheduling policies per service unit. - MemoryTHP= — A new unit setting provides per-service control over Transparent Huge Pages, useful for fine-tuning memory performance in high-throughput workloads.
-
FANCY_NAME= field — Added to
os-release, similar toPRETTY_NAMEbut explicitly allowing ANSI sequences and non-ASCII Unicode glyphs. Shown bysystemd-hostnamedandhostnamectl. - tpm2_id udev built-in — Extracts vendor and model identification from connected TPM2 devices as they are probed, simplifying TPM management.
-
systemctl enqueue-marked — A new verb that calls the
EnqueueMarkedJobs()D-Bus method directly from the command line. -
xaccess device delegation —
systemd-logindandsystemd-udevdgain thexaccessmechanism for delegating access to specific devices to users with specially marked sessions. - systemd-vmspawn –ephemeral — Virtual machines can now be marked ephemeral, created on demand and discarded after use — ideal for testing and automation pipelines.
-
AI tooling documentation — The project now ships
AGENTS.mdandCLAUDE.mdfiles, providing AI coding assistants with structured guidance on the codebase’s conventions and development workflow.
systemd-networkd Improvements
Several confirmed improvements land in the networking stack:
- ModemManager integration via the “simple connect” protocol, enabling easier mobile broadband management through
systemd-networkd. - The Varlink and JSON interfaces now report IP addresses as human-readable strings in addition to the existing integer array format — making monitoring and automation tooling more ergonomic.
.linkfiles gain additional parameters:ScatterGather=,TCPECNSegmentationOffload=,GenericReceiveOffloadList=, and more, for fine-grained Ethernet device tuning.
Integrity & Access Control
- systemd-repart adds basic integrity checks for encrypted volumes.
- The xaccess mechanism in
systemd-logindandudevenables more granular, session-scoped device access delegation. - systemd-portabled now runs as a user-level service, allowing unprivileged users to start portable services on supported kernel versions.
When Will It Reach Your System?
Rolling-release distributions — Arch Linux, Fedora, openSUSE Tumbleweed — are expected to absorb systemd 260 quickly, as their users typically track current kernels already. The release is intended for first-half 2026 Linux distributions.
Long-term support enterprise distributions and LTS Ubuntu builds will likely delay, as the kernel 5.10 requirement itself may be a significant ask for some server fleets. RHEL derivatives are expected to take additional time before shipping this update in their stable channels.
The most critical action item for all administrators: audit and migrate any remaining System V init scripts before upgrading. There is no automatic fallback in systemd 260.
