{"id":165027,"date":"2026-03-29T12:11:19","date_gmt":"2026-03-29T09:11:19","guid":{"rendered":"https:\/\/computingforgeeks.com\/void-linux-post-install-setup\/"},"modified":"2026-03-29T21:17:14","modified_gmt":"2026-03-29T18:17:14","slug":"void-linux-post-install-setup","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/void-linux-post-install-setup\/","title":{"rendered":"Void Linux Post-Installation Setup Guide"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

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<\/a> covers the full picture.<\/p>\n\n\n\n

Verified working: March 2026<\/strong> on Void Linux x86_64 (glibc), kernel 6.x<\/em><\/p>\n\n\n\n

Update the System<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Update xbps first:<\/p>\n\n\n\n

sudo xbps-install -u xbps<\/code><\/pre>\n\n\n\n
Once xbps is current, run a full system upgrade:<\/p>\n\n\n\n
sudo xbps-install -Syu<\/code><\/pre>\n\n\n\n
The -S<\/code> flag syncs the remote repository index, -y<\/code> confirms automatically, and -u<\/code> upgrades all installed packages. If the kernel was updated, reboot before continuing:<\/p>\n\n\n\n
sudo reboot<\/code><\/pre>\n\n\n\n
Enable the Nonfree Repository<\/h2>\n\n\n\n
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:<\/p>\n\n\n\n
sudo xbps-install void-repo-nonfree<\/code><\/pre>\n\n\n\n
Sync the package index so xbps picks up the new repository:<\/p>\n\n\n\n
sudo xbps-install -S<\/code><\/pre>\n\n\n\n
Verify both repositories are active:<\/p>\n\n\n\n
xbps-query -L<\/code><\/pre>\n\n\n\n
You should see two entries listed:<\/p>\n\n\n\n
 8404 https:\/\/repo-default.voidlinux.org\/current (RSA signed)\n    0 https:\/\/repo-default.voidlinux.org\/current\/nonfree (RSA signed)<\/code><\/pre>\n\n\n\n
The nonfree repo now appears alongside the main repository. Package counts will populate once you install something from it.<\/p>\n\n\n\n
Set Up System Logging<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
sudo xbps-install socklog-void<\/code><\/pre>\n\n\n\n
Enable both the userspace and kernel log services:<\/p>\n\n\n\n
sudo ln -s \/etc\/sv\/socklog-unix \/var\/service\/\nsudo ln -s \/etc\/sv\/nanoklogd \/var\/service\/<\/code><\/pre>\n\n\n\n
Runit picks up the new symlinks within a few seconds and starts the services automatically. Logs are stored in \/var\/log\/socklog\/<\/code> with subdirectories for each facility. To read recent system messages:<\/p>\n\n\n\n
sudo svlogtail<\/code><\/pre>\n\n\n\n
For a specific log category like authentication events:<\/p>\n\n\n\n
cat \/var\/log\/socklog\/secure\/current<\/code><\/pre>\n\n\n\n
Add your regular user to the socklog<\/code> group so you can read logs without sudo:<\/p>\n\n\n\n
sudo usermod -aG socklog your_username<\/code><\/pre>\n\n\n\n
Log out and back in for the group change to take effect.<\/p>\n\n\n\n
Install Essential Tools<\/h2>\n\n\n\n
The base install lacks most utilities you’d expect on a working system. Install a practical set of tools in one pass:<\/p>\n\n\n\n
sudo xbps-install htop neovim curl wget git bash-completion unzip tree<\/code><\/pre>\n\n\n\n
Confirm the installed versions:<\/p>\n\n\n\n
htop --version\nnvim --version | head -1\ngit --version<\/code><\/pre>\n\n\n\n
The output confirms the package versions pulled from the repo:<\/p>\n\n\n\n
htop 3.4.1\nNVIM v0.11.7\ngit version 2.53.0<\/code><\/pre>\n\n\n\n
Neovim replaces vi as your default terminal editor. If you prefer vim, install vim<\/code> 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<\/a> or deploy a full LAMP stack on Void Linux<\/a>.<\/p>\n\n\n\n
Configure the Firewall with nftables<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
sudo xbps-install nftables<\/code><\/pre>\n\n\n\n
Create a basic firewall configuration that allows SSH, established connections, and ICMP (ping) while dropping everything else:<\/p>\n\n\n\n
sudo vi \/etc\/nftables.conf<\/code><\/pre>\n\n\n\n
Add the following ruleset:<\/p>\n\n\n\n
#!\/usr\/sbin\/nft -f\n\nflush ruleset\n\ntable inet filter {\n    chain input {\n        type filter hook input priority 0; policy drop;\n\n        # Allow loopback\n        iif lo accept\n\n        # Allow established and related connections\n        ct state established,related accept\n\n        # Allow ICMP (ping)\n        ip protocol icmp accept\n        ip6 nexthdr icmpv6 accept\n\n        # Allow SSH\n        tcp dport 22 accept\n    }\n\n    chain forward {\n        type filter hook forward priority 0; policy drop;\n    }\n\n    chain output {\n        type filter hook output priority 0; policy accept;\n    }\n}<\/code><\/pre>\n\n\n\n
Enable and start the nftables service:<\/p>\n\n\n\n
sudo ln -s \/etc\/sv\/nftables \/var\/service\/<\/code><\/pre>\n\n\n\n
Verify the rules are loaded:<\/p>\n\n\n\n
sudo nft list ruleset<\/code><\/pre>\n\n\n\n
The output should mirror the configuration you wrote:<\/p>\n\n\n\n
table inet filter {\n\tchain input {\n\t\ttype filter hook input priority filter; policy drop;\n\t\tiif \"lo\" accept\n\t\tct state established,related accept\n\t\tip protocol icmp accept\n\t\tip6 nexthdr 58 accept\n\t\ttcp dport 22 accept\n\t}\n\n\tchain forward {\n\t\ttype filter hook forward priority filter; policy drop;\n\t}\n\n\tchain output {\n\t\ttype filter hook output priority filter; policy accept;\n\t}\n}<\/code><\/pre>\n\n\n\n
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<\/code>.<\/p>\n\n\n\n
Create a Regular User<\/h2>\n\n\n\n
Running everything as root is a bad habit that catches up with you eventually. Create a regular user account with a home directory:<\/p>\n\n\n\n
sudo useradd -m -s \/bin\/bash -G wheel sysadmin\nsudo passwd sysadmin<\/code><\/pre>\n\n\n\n
The -G wheel<\/code> 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:<\/p>\n\n\n\n
sudo xbps-install sudo<\/code><\/pre>\n\n\n\n
Edit the sudoers file to allow the wheel group:<\/p>\n\n\n\n
sudo visudo<\/code><\/pre>\n\n\n\n
Uncomment this line:<\/p>\n\n\n\n
%wheel ALL=(ALL) ALL<\/code><\/pre>\n\n\n\n
The user sysadmin<\/code> can now run privileged commands with sudo<\/code>. If you prefer a lighter alternative, Void also packages opendoas<\/code>, which is simpler to configure and popular in the BSD world. Install it with sudo xbps-install opendoas<\/code> and create \/etc\/doas.conf<\/code> containing permit persist :wheel<\/code>.<\/p>\n\n\n\n
Change the Default Shell<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
sudo xbps-install fish-shell<\/code><\/pre>\n\n\n\n
Check the installed version:<\/p>\n\n\n\n
fish --version<\/code><\/pre>\n\n\n\n
This confirms fish 4.6.0 is available:<\/p>\n\n\n\n
fish, version 4.6.0<\/code><\/pre>\n\n\n\n
Change your default shell:<\/p>\n\n\n\n
chsh -s \/usr\/bin\/fish<\/code><\/pre>\n\n\n\n
Log out and back in for the change to take effect. If you prefer zsh instead, install it with sudo xbps-install zsh<\/code> and run chsh -s \/usr\/bin\/zsh<\/code>. Both are excellent choices, though fish requires less initial configuration.<\/p>\n\n\n\n
Enable Network Time Synchronization<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
sudo xbps-install chrony<\/code><\/pre>\n\n\n\n
The default configuration in \/etc\/chrony.conf<\/code> uses public NTP pools and works without modification for most setups. Enable the service:<\/p>\n\n\n\n
sudo ln -s \/etc\/sv\/chronyd \/var\/service\/<\/code><\/pre>\n\n\n\n
After a few seconds, check the synchronization status:<\/p>\n\n\n\n
chronyc tracking<\/code><\/pre>\n\n\n\n
The output shows your system clock’s offset from the NTP source:<\/p>\n\n\n\n
Reference ID    : A29FC87B (time.cloudflare.com)\nStratum         : 3\nRef time (UTC)  : Sat Mar 29 10:15:32 2026\nSystem time     : 0.000023418 seconds fast of NTP time\nLast offset     : +0.000012354 seconds\nRMS offset      : 0.000045678 seconds\nFrequency       : 2.341 ppm slow\nResidual freq   : +0.001 ppm\nSkew            : 0.032 ppm\nRoot delay      : 0.024512 seconds\nRoot dispersion : 0.001234 seconds\nUpdate interval : 64.0 seconds\nLeap status     : Normal<\/code><\/pre>\n\n\n\n
A “System time” offset under 1 second means everything is working correctly.<\/p>\n\n\n\n
Understanding Runit Service Management<\/h2>\n\n\n\n
If you’re coming from systemd, runit will feel alien at first. The core concept is simple: service definitions live in \/etc\/sv\/<\/code>, and a service becomes active when you symlink it into \/var\/service\/<\/code>. The runit supervisor watches \/var\/service\/<\/code> and starts anything it finds there. Removing the symlink disables the service.<\/p>\n\n\n\n
Here’s a reference table for everyday service management:<\/p>\n\n\n\n
Task<\/th>Runit (Void)<\/th>systemd equivalent<\/th><\/tr><\/thead>
Enable a service<\/td>ln -s \/etc\/sv\/SERVICE \/var\/service\/<\/code><\/td>systemctl enable SERVICE<\/code><\/td><\/tr>
Disable a service<\/td>rm \/var\/service\/SERVICE<\/code><\/td>systemctl disable SERVICE<\/code><\/td><\/tr>
Start a service<\/td>sv start SERVICE<\/code><\/td>systemctl start SERVICE<\/code><\/td><\/tr>
Stop a service<\/td>sv stop SERVICE<\/code><\/td>systemctl stop SERVICE<\/code><\/td><\/tr>
Restart a service<\/td>sv restart SERVICE<\/code><\/td>systemctl restart SERVICE<\/code><\/td><\/tr>
Check status<\/td>sv status SERVICE<\/code><\/td>systemctl status SERVICE<\/code><\/td><\/tr>
View logs<\/td>cat \/var\/log\/socklog\/SERVICE\/current<\/code><\/td>journalctl -u SERVICE<\/code><\/td><\/tr>
List enabled services<\/td>ls \/var\/service\/<\/code><\/td>systemctl list-unit-files --state=enabled<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
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\/<\/code>, runit starts the service and will keep restarting it if it exits. To temporarily stop a service without disabling it, use sv down SERVICE<\/code>. It stays stopped until you run sv up SERVICE<\/code> or reboot.<\/p>\n\n\n\n
To see all available services (installed but not necessarily enabled):<\/p>\n\n\n\n
ls \/etc\/sv\/<\/code><\/pre>\n\n\n\n
Compare that to what’s actually running:<\/p>\n\n\n\n
ls \/var\/service\/<\/code><\/pre>\n\n\n\n
The difference between those two listings tells you which services are installed but disabled.<\/p>\n\n\n\n
Package Management with XBPS<\/h2>\n\n\n\n
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:<\/p>\n\n\n\n
Task<\/th>XBPS command<\/th>apt equivalent<\/th>dnf equivalent<\/th><\/tr><\/thead>
Install a package<\/td>xbps-install pkg<\/code><\/td>apt install pkg<\/code><\/td>dnf install pkg<\/code><\/td><\/tr>
Remove a package<\/td>xbps-remove pkg<\/code><\/td>apt remove pkg<\/code><\/td>dnf remove pkg<\/code><\/td><\/tr>
Remove with orphans<\/td>xbps-remove -Ro pkg<\/code><\/td>apt autoremove pkg<\/code><\/td>dnf autoremove pkg<\/code><\/td><\/tr>
Search for package<\/td>xbps-query -Rs keyword<\/code><\/td>apt search keyword<\/code><\/td>dnf search keyword<\/code><\/td><\/tr>
Show package info<\/td>xbps-query -R pkg<\/code><\/td>apt show pkg<\/code><\/td>dnf info pkg<\/code><\/td><\/tr>
List installed packages<\/td>xbps-query -l<\/code><\/td>dpkg -l<\/code><\/td>rpm -qa<\/code><\/td><\/tr>
List files in package<\/td>xbps-query -f pkg<\/code><\/td>dpkg -L pkg<\/code><\/td>rpm -ql pkg<\/code><\/td><\/tr>
Sync repos<\/td>xbps-install -S<\/code><\/td>apt update<\/code><\/td>dnf makecache<\/code><\/td><\/tr>
Full system upgrade<\/td>xbps-install -Syu<\/code><\/td>apt upgrade<\/code><\/td>dnf upgrade<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
One useful trick: xbps-query -Rs<\/code> searches remote repos, while xbps-query -s<\/code> (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.<\/p>\n\n\n\n
To clean up cached packages and reclaim disk space:<\/p>\n\n\n\n
sudo xbps-remove -Oo<\/code><\/pre>\n\n\n\n
The -O<\/code> flag removes cached package files, and -o<\/code> removes orphaned dependencies. Run this periodically to keep the system lean.<\/p>\n\n\n\n
Production Hardening<\/h2>\n\n\n\n
If this system will face the internet, a few additional measures bring it closer to production-ready:<\/p>\n\n\n\n