Learn Void Linux - Core Concepts & Main Architecture

#Introduction

After getting to know Void's history in episode 1, it's time to dissect its architecture. Episode 2 maps how Void is built from the bottom up: kernel, libc, init system, and package manager. Understanding this architecture is the key so that the commands in the following episodes don't feel like blind memorization.

Void has a clear pattern: each layer has one simple job. The kernel manages hardware, runit manages processes, and XBPS manages packages. There's no omnibus service that does everything at once.

Let's assemble the Void Linux architecture map layer by layer.

#The Void Architecture Map

#From Kernel to Userland

Void Linux is built on the Linux kernel, packaged by Void itself. Above the kernel sits the libc — glibc or musl depending on your choice during installation. On top of the libc, the entire userland runs: shells, utilities, and applications.

Here's a picture of the layer stack:

Applications and services
--------------------------
Libc (glibc / musl)
--------------------------
Linux kernel (linux / linux-lts)
--------------------------
Hardware

The libc choice determines how applications are compiled and run, while the kernel choice determines compatibility with hardware. Both are chosen at installation and can be changed later, as we'll discuss in episodes 6 and 11.

#runit as PID 1

When the system boots, the kernel runs the first init specified on the init= line in GRUB. In Void, that first process is runit, which then launches runsvdir — its supervisor. runsvdir runs a per-service supervisor called runsv for every service enabled through a symlink in /var/service/.

The boot flow looks like this:

Kernel -> runit -> runsvdir -> runsv per service

Each service is a directory in /etc/sv/ containing a run script. We'll practice the full details in episode 5.

#Core XBPS Components

#xbps-install: Installing and Upgrading Packages

xbps-install is the main gateway for installing packages. Sync the repositories with -S, then install a package name:

sudo xbps-install -S
sudo xbps-install htop

The xbps-install -S command updates the repository index, while xbps-install htop installs the package along with its dependencies. To upgrade the entire system, use xbps-install -Su as in episode 1.

#xbps-query: Searching and Inspecting Packages

xbps-query is used to query the package database. Search for packages by name or description with -s, list installed packages with -l, and check which files belong to a package with -f:

xbps-query -s 'nginx'
xbps-query -l | wc -l
xbps-query -f nginx | head

The output of xbps-query -l is a list of all installed packages. Counting them with wc -l gives you an idea of how lean your system is.

#xbps-remove and xbps-reconfigure

To remove a package along with its unused dependencies, use xbps-remove with the -R option. Meanwhile, xbps-reconfigure is used to re-run a package's configuration scripts — for example, after you change a service script:

sudo xbps-remove -R htop
sudo xbps-reconfigure -f openssh

The -f option on xbps-reconfigure -f openssh forces the openssh configuration to re-run even if there's no version change.

#xbps-pkgdb: Package Database Health Check

xbps-pkgdb checks the consistency of the package database. Run it with the -a option to check all packages:

sudo xbps-pkgdb -a

The xbps-pkgdb -a command reports packages with missing files, wrong ownership, or other issues. It's the right first step when the system feels strange.

#xbps-src and void-packages

#Building Packages from Source

xbps-src is Void's build system that works inside the void-packages repo. It lets you compile packages from source code, even packages that aren't available in the binary repository. The basic flow:

Package template -> xbps-src pkg -> local binary package

A package template contains metadata such as name, version, dependencies, and build steps. Episode 15 will discuss it fully.

#Conclusion

Episode 2 mapped the Void Linux architecture: the kernel at the bottom, the libc in the middle, and applications on top, with runit as PID 1 running runsvdir to supervise services. You also learned the role of each XBPS component — from xbps-install, xbps-query, xbps-remove, xbps-reconfigure, to xbps-pkgdb.

Key takeaways:

• Void's architecture is composed of kernel, libc, userland, and init.
• runit is PID 1, which launches runsvdir and runsv per service.
• A runit service is a directory containing a run script.
• xbps-install is used to install and upgrade packages.
• xbps-query is used to search and inspect packages.
• xbps-src and void-packages are used to build from source.

In the next episode, episode 3, we will practice installation and initial setup — using void-installer to partition the disk, configure the user, network, and bootloader, then set the hostname, timezone, and repositories so the system is ready for daily use.