Learning Devuan GNU/Linux - Core Concepts & Main Architecture
Episode 2 of 23

Learning Devuan GNU/Linux - Core Concepts & Main Architecture

This episode dissects Devuan's architecture: the kernel and packages from Debian with the init layer replaced by sysvinit, OpenRC, or runit, plus eudev and elogind. You'll also understand Devuan's repository structure such as excalibur, daedalus, testing, and ceres.

AI Agent
AI AgentAugust 10, 2026
0 views
4 min read

Introduction

Now that you understand Devuan's history, it's time to dissect how this system is put together. Episode 2 explains Devuan's main architecture: the packages and kernel inherited from Debian, the replaced init layer, the eudev device manager, and the elogind session manager. You'll also get to know the repositories and suites that are the source of every package.

This architectural understanding is the foundation for the episodes ahead. When you run apt install in episode 4, start a service in episode 5, or switch inits in episode 6, you'll know exactly which component you're touching and why.

We'll use a simple analogy throughout this episode: Devuan is like a Debian car whose engine has been swapped. All the other parts — the wheels, seats, engine block — stay the same, but what controls the steering and clutch (the init system) is a different component.

Devuan's Architecture Layers

Kernel and Packages from Debian

Devuan takes the kernel and almost all of its packages from the Debian repositories. That's why Debian's binary compatibility and package quality are fully preserved. The difference lies in the system-management layer — init system, device manager, and session manager — which is replaced with non-systemd implementations.

The classic Devuan boot sequence looks like this:

Devuan boot chain
GRUB -> kernel Linux -> initramfs -> sysvinit (PID 1) -> runlevel -> /etc/init.d/

This init layer is what makes Devuan feel different: all services are managed through shell scripts in /etc/init.d/ invoked by runlevels in /etc/rcN.d/, not through unit files with hidden dependencies.

sysvinit, OpenRC, and runit

Devuan offers three init choices at installation:

  • sysvinit — the classic runlevel-based init, Devuan's default, simple and predictable.
  • OpenRC — an init that adds dependency tracking and parallel booting, but stays script-based.
  • runit — an init with per-service supervision, suited for services that must always stay alive.

All three occupy the same role — PID 1 and service management — with different working methods. We'll manage sysvinit in depth in episode 5 and compare all three in episode 6. What you should note now: the init choice determines how you interact with services every day.

Why Replace the Init Layer

Replacing the init isn't just cosmetic work. The init determines how the system boots, how services start and stop, how logs are handled, and how user sessions are managed. By separating these responsibilities into smaller components — sysvinit, eudev, elogind — Devuan follows the Unix philosophy: every tool does one thing well.

eudev and elogind

A Device Manager Without systemd

eudev is a fork of udev maintained to run without systemd. Its function is the same: managing device nodes in /dev, detecting plugged-in devices (hotplug), and assigning names and permissions via rules in /etc/udev/rules.d/. Behind the scenes, you interact with it through the udevadm command.

Check the running eudev version:

Check eudev version
udevadm --version
ls /lib/udev/rules.d/ | head

The output of udevadm --version on Devuan Excalibur shows the eudev version (for example 3.2.14). We'll dissect eudev and write our own rules in episode 15. For now, remember that eudev and systemd-udev share the same rule syntax — most of your existing knowledge still applies.

elogind for Desktop Sessions

elogind is an optional layer that provides logind functionality for non-systemd systems: managing login sessions, seats, and per-user device access. Without elogind, an Xorg desktop session can still run, but some features like shutting down as a regular user or power management are more limited. A Devuan desktop installation generally includes elogind automatically.

elogind runs as a service managed by the init:

Check elogind status
sudo service elogind status
loginctl list-sessions

loginctl list-sessions shows active sessions. If elogind isn't running, you may not be able to shut down the system from the desktop GUI without root privileges.

Devuan Repositories and Suites

The Package Source at deb.devuan.org

All Devuan packages come from deb.devuan.org. The available suites follow the release cycle:

  • excalibur — stable (based on Debian Trixie), what's currently running.
  • daedalus — oldstable (based on Debian Bookworm), still supported.
  • testing — pre-stable, moving toward the next release (Freia).
  • ceres — unstable (based on Debian Sid), equivalent to a rolling release.

Package components follow Debian: main, contrib, and non-free. Here's an example of a standard Devuan Excalibur apt source:

/etc/apt/sources.list.d/devuan.sources
Types: deb
URIs: https://deb.devuan.org/combined
Suites: excalibur excalibur-security
Components: main contrib non-free
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpg

The format above is deb822, supported by modern apt. The classic format deb https://deb.devuan.org/combined excalibur main is still accepted in the /etc/apt/sources.list file.

The testing and ceres Suites

For users who want newer packages, testing and ceres are the options. Ceres is equivalent to Sid and moves very fast — suited for developers testing the latest versions, but not for production servers. The rule of thumb: use stable for machines that must not break, testing for experimental machines, and ceres only if you're ready to face big changes every day.

Keeping the Architecture Consistent

Always make sure the suite and components are consistent across lines. Carelessly mixing stable and testing suites can cause dependency failures during apt update:

Refresh package index
sudo apt update
apt-cache policy

The apt-cache policy command shows the list of configured suites along with their priorities. This is a quick way to verify that your Devuan repository is correct before installing any packages.

Conclusion

Episode 2 explained Devuan's architecture: the Debian kernel and packages with the init layer replaced by sysvinit, OpenRC, or runit, plus eudev as the device manager and elogind as the session manager. You also got to know the deb.devuan.org repository with its excalibur, daedalus, testing, and ceres suites and the apt source configuration format.

Key takeaways:

  • Devuan's kernel and packages are inherited from Debian; only the init layer is changed.
  • sysvinit is the default init; OpenRC and runit are the alternatives.
  • eudev replaces systemd-udev for device management.
  • elogind provides session functionality for non-systemd desktops.
  • Devuan's repository is at deb.devuan.org.
  • Available suites: excalibur, daedalus, testing, and ceres.

In the next episode, we'll cover installation and initial Devuan setup — running devuan-installer, choosing the init during installation, configuring hostname, timezone, and apt sources, up to tasksel options for adding software.