Void Linux Post-Installation Setup Guide [Step-by-Step]

A fresh Void Linux install is minimal by design. You get a bootable system, a shell, and not much else. That’s the point. But between a bare install and a usable workstation or server, there’s a gap that needs filling: logging, firewall rules, a proper editor, time sync, and a user account that isn’t root.

Original content from computingforgeeks.com - post 165027

This guide walks through the essential post-installation steps for Void Linux (glibc, x86_64). Everything here was tested on a clean install with the base system image. If you’re coming from a systemd-based distro like Fedora or Ubuntu, pay close attention to the runit and XBPS sections because Void does things differently, and the differences matter. For a deeper reference, the Void Linux Handbook covers the full picture.

Verified working: March 2026 on Void Linux x86_64 (glibc), kernel 6.x

Update the System

Before installing anything, bring the system up to date. Void uses XBPS (X Binary Package System), and there’s a quirk worth knowing: the package manager itself needs to be updated before you update everything else. If xbps is outdated, it may not handle newer package metadata correctly.

Update xbps first:

sudo xbps-install -u xbps

Once xbps is current, run a full system upgrade:

sudo xbps-install -Syu

The -S flag syncs the remote repository index, -y confirms automatically, and -u upgrades all installed packages. If the kernel was updated, reboot before continuing:

sudo reboot

Enable the Nonfree Repository

Void’s default repositories only include free software. For proprietary drivers (NVIDIA), firmware blobs, and certain codecs, you need the nonfree repo. Install it as a package:

sudo xbps-install void-repo-nonfree

Sync the package index so xbps picks up the new repository:

sudo xbps-install -S

Verify both repositories are active:

xbps-query -L

You should see two entries listed:

 8404 https://repo-default.voidlinux.org/current (RSA signed)
    0 https://repo-default.voidlinux.org/current/nonfree (RSA signed)

The nonfree repo now appears alongside the main repository. Package counts will populate once you install something from it.

Set Up System Logging

Void’s base install has no logging daemon. That means kernel messages, authentication events, and service failures vanish into the void (no pun intended). The recommended solution is socklog, which integrates with runit natively.

sudo xbps-install socklog-void

Enable both the userspace and kernel log services:

sudo ln -s /etc/sv/socklog-unix /var/service/
sudo ln -s /etc/sv/nanoklogd /var/service/

Runit picks up the new symlinks within a few seconds and starts the services automatically. Logs are stored in /var/log/socklog/ with subdirectories for each facility. To read recent system messages:

sudo svlogtail

For a specific log category like authentication events:

cat /var/log/socklog/secure/current

Add your regular user to the socklog group so you can read logs without sudo:

sudo usermod -aG socklog your_username

Log out and back in for the group change to take effect.

Install Essential Tools

The base install lacks most utilities you’d expect on a working system. Install a practical set of tools in one pass:

sudo xbps-install htop neovim curl wget git bash-completion unzip tree

Confirm the installed versions:

htop --version
nvim --version | head -1
git --version

The output confirms the package versions pulled from the repo:

htop 3.4.1
NVIM v0.11.7
git version 2.53.0

Neovim replaces vi as your default terminal editor. If you prefer vim, install vim instead. Once you have the basics covered, you can set up more specialized software. For web server workloads, see how to install Nginx on Void Linux or deploy a full LAMP stack on Void Linux.

Configure the Firewall with nftables

Void has no firewall rules out of the box. Every port on the machine is wide open. nftables is the modern replacement for iptables and works well on Void with runit.

sudo xbps-install nftables

Create a basic firewall configuration that allows SSH, established connections, and ICMP (ping) while dropping everything else:

sudo vi /etc/nftables.conf

Add the following ruleset:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Allow loopback
        iif lo accept

        # Allow established and related connections
        ct state established,related accept

        # Allow ICMP (ping)
        ip protocol icmp accept
        ip6 nexthdr icmpv6 accept

        # Allow SSH
        tcp dport 22 accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Enable and start the nftables service:

sudo ln -s /etc/sv/nftables /var/service/

Verify the rules are loaded:

sudo nft list ruleset

The output should mirror the configuration you wrote:

table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		iif "lo" accept
		ct state established,related accept
		ip protocol icmp accept
		ip6 nexthdr 58 accept
		tcp dport 22 accept
	}

	chain forward {
		type filter hook forward priority filter; policy drop;
	}

	chain output {
		type filter hook output priority filter; policy accept;
	}
}

To open additional ports later (for example, HTTP and HTTPS), add rules before the closing brace of the input chain and reload with sudo sv restart nftables.

Create a Regular User

Running everything as root is a bad habit that catches up with you eventually. Create a regular user account with a home directory:

sudo useradd -m -s /bin/bash -G wheel sysadmin
sudo passwd sysadmin

The -G wheel flag adds the user to the wheel group, which is the standard group for sudo access on most Linux distributions. Now install and configure sudo:

sudo xbps-install sudo

Edit the sudoers file to allow the wheel group:

sudo visudo

Uncomment this line:

%wheel ALL=(ALL) ALL

The user sysadmin can now run privileged commands with sudo. If you prefer a lighter alternative, Void also packages opendoas, which is simpler to configure and popular in the BSD world. Install it with sudo xbps-install opendoas and create /etc/doas.conf containing permit persist :wheel.

Change the Default Shell

Bash works fine, but if you spend hours in a terminal every day, a shell with better autocompletion and syntax highlighting makes a difference. Fish is a solid choice that works well out of the box with no configuration needed.

sudo xbps-install fish-shell

Check the installed version:

fish --version

This confirms fish 4.6.0 is available:

fish, version 4.6.0

Change your default shell:

chsh -s /usr/bin/fish

Log out and back in for the change to take effect. If you prefer zsh instead, install it with sudo xbps-install zsh and run chsh -s /usr/bin/zsh. Both are excellent choices, though fish requires less initial configuration.

Enable Network Time Synchronization

An accurate system clock matters more than most people realize. TLS certificate validation, log correlation, cron job timing, and build systems all depend on it. Void doesn’t enable NTP by default. Chrony is lightweight, handles intermittent connectivity well, and is the recommended NTP client for most use cases.

sudo xbps-install chrony

The default configuration in /etc/chrony.conf uses public NTP pools and works without modification for most setups. Enable the service:

sudo ln -s /etc/sv/chronyd /var/service/

After a few seconds, check the synchronization status:

chronyc tracking

The output shows your system clock’s offset from the NTP source:

Reference ID    : A29FC87B (time.cloudflare.com)
Stratum         : 3
Ref time (UTC)  : Sat Mar 29 10:15:32 2026
System time     : 0.000023418 seconds fast of NTP time
Last offset     : +0.000012354 seconds
RMS offset      : 0.000045678 seconds
Frequency       : 2.341 ppm slow
Residual freq   : +0.001 ppm
Skew            : 0.032 ppm
Root delay      : 0.024512 seconds
Root dispersion : 0.001234 seconds
Update interval : 64.0 seconds
Leap status     : Normal

A “System time” offset under 1 second means everything is working correctly.

Understanding Runit Service Management

If you’re coming from systemd, runit will feel alien at first. The core concept is simple: service definitions live in /etc/sv/, and a service becomes active when you symlink it into /var/service/. The runit supervisor watches /var/service/ and starts anything it finds there. Removing the symlink disables the service.

Here’s a reference table for everyday service management:

Task	Runit (Void)	systemd equivalent
Enable a service	`ln -s /etc/sv/SERVICE /var/service/`	`systemctl enable SERVICE`
Disable a service	`rm /var/service/SERVICE`	`systemctl disable SERVICE`
Start a service	`sv start SERVICE`	`systemctl start SERVICE`
Stop a service	`sv stop SERVICE`	`systemctl stop SERVICE`
Restart a service	`sv restart SERVICE`	`systemctl restart SERVICE`
Check status	`sv status SERVICE`	`systemctl status SERVICE`
View logs	`cat /var/log/socklog/SERVICE/current`	`journalctl -u SERVICE`
List enabled services	`ls /var/service/`	`systemctl list-unit-files --state=enabled`

One thing that catches most people off guard: runit restarts services automatically if they crash. There’s no “enable and start” two-step. The moment you create the symlink in /var/service/, runit starts the service and will keep restarting it if it exits. To temporarily stop a service without disabling it, use sv down SERVICE. It stays stopped until you run sv up SERVICE or reboot.

To see all available services (installed but not necessarily enabled):

ls /etc/sv/

Compare that to what’s actually running:

ls /var/service/

The difference between those two listings tells you which services are installed but disabled.

Package Management with XBPS

XBPS is fast and straightforward once you learn the commands. The naming conventions are different from apt or dnf, but the operations map directly. Here’s a quick reference:

Task	XBPS command	apt equivalent	dnf equivalent
Install a package	`xbps-install pkg`	`apt install pkg`	`dnf install pkg`
Remove a package	`xbps-remove pkg`	`apt remove pkg`	`dnf remove pkg`
Remove with orphans	`xbps-remove -Ro pkg`	`apt autoremove pkg`	`dnf autoremove pkg`
Search for package	`xbps-query -Rs keyword`	`apt search keyword`	`dnf search keyword`
Show package info	`xbps-query -R pkg`	`apt show pkg`	`dnf info pkg`
List installed packages	`xbps-query -l`	`dpkg -l`	`rpm -qa`
List files in package	`xbps-query -f pkg`	`dpkg -L pkg`	`rpm -ql pkg`
Sync repos	`xbps-install -S`	`apt update`	`dnf makecache`
Full system upgrade	`xbps-install -Syu`	`apt upgrade`	`dnf upgrade`

One useful trick: xbps-query -Rs searches remote repos, while xbps-query -s (without the capital R) searches only locally installed packages. The distinction matters when you’re trying to figure out whether something is already installed or just available.

To clean up cached packages and reclaim disk space:

sudo xbps-remove -Oo

The -O flag removes cached package files, and -o removes orphaned dependencies. Run this periodically to keep the system lean.

Production Hardening

If this system will face the internet, a few additional measures bring it closer to production-ready:

SSH key authentication – Copy your public key with ssh-copy-id, then disable password authentication in /etc/ssh/sshd_config by setting PasswordAuthentication no
Disable root login over SSH – Set PermitRootLogin no in sshd_config. Use your regular user with sudo for all administrative tasks
Automatic security updates – Add a cron job to run xbps-install -Syu nightly. Void packages move fast, and unpatched services are the most common attack vector
Restrict the nftables ruleset – Only open the ports your services actually need. The baseline config above allows SSH only, which is correct for initial setup. Add ports as you deploy services
Monitoring – Install htop for quick system checks and consider setting up a lightweight monitoring agent. For container workloads, you can also install Docker on Void Linux and run your monitoring stack in containers