Super Mega Ultra Guide to Void Linux
00:00 intro
08:04 Single System Scenario Installation
13:09 Dual Boot Scenario
14:54 Inside the System
20:35 Managing Services in Void Linux wth Runit
27:27 Managing Void Linux with XBPS
32:44 Advanced Recovery with XBPS
36:14 Useful Tips
38:19 Conclusion
IMPORTANT
First of all, a couple of quick corrections. In the intro I said Artix is basically dead: that’s wrong, Artix is still developed. The distro I had in mind was ArcoLinux, which has changed direction in recent years. There’s also a small but important editing mistake: in the part about GRUB and the Void login screen, the two clips are flipped. And finally, there is a big audio difference between the “casual” install and the “realistic” install that can be a real barrier if you are hard of hearing. That part is entirely on me and I’ll do better next time.
The comment I mention adds depth in three main technical areas.
The first is the real-world difference between glibc and musl. In the video I focused on philosophy and on musl as lighter and cleaner; the comment rightly stresses practicality. Glibc is what most users should pick because it offers the best compatibility: some programs only run on glibc (proprietary Nvidia drivers, Steam, closed-source apps) and traditional 32-bit software is often painful on musl, so with Wine you typically need Wow64. Musl shines elsewhere: embedded systems and lightweight containers, with smaller attack surface, good memory behaviour and in some cases better performance on ARM. On x86, glibc often wins thanks to heavy optimisations. The short version is simple: for normal desktop users glibc is the safe choice, musl is for people who know exactly what they are building.
The second area is storage and partitioning. Void’s installer doesn’t touch some low-level details, for example NVMe logical block size. Many NVMe drives can be formatted as 512 or 4096 bytes; in some cases 4096 behaves better with Linux and Wine. To inspect and change that you need tools like `nvme-cli`, and formatting at that level wipes the drive completely, which is why I didn’t show it in the video. The GPT vs MBR topic also has nuance: I treated GPT as the modern default, but a safer rule of thumb is GPT for UEFI machines and MBR for pure legacy BIOS systems, even though GPT can be made to work there too. The comment also suggests an EFI partition of at least 500 MB, even 2 GB if you plan heavy multiboot on a big drive, and recommends splitting root and home on disks from about 120 GB up to make reinstalls easier. Finally, for many users a graphical tool like GNOME Disks, which shows drive models instead of just sda/sdb/nvme0n1, is less error-prone than only using classic partitioning tools.
The third area is boot, firmware quirks and display managers. Void lets you choose between a local and a network install. Besides the obvious fact that the network install doesn’t ship Xfce by default, there’s a subtle issue: on some UEFI firmwares (for example certain HP and Asus boards) the network install’s UEFI entry is not recognised correctly, while the local install works fine. Very old laptops can also have trouble rendering graphical bootloaders: the keyboard works but the graphics are corrupted, as the commenter saw on a ThinkPad T420 with a modern Debian, and the same can happen with Void if you enable a graphical GRUB theme. On the GRUB side, `os-prober` only makes sense after at least one OS is installed: set `GRUB_DISABLE_OS_PROBER=false` after installation, then run `update-grub` so it can actually detect other systems. A similar manual step is needed for display managers: if you install SDDM on top of the Xfce ISO, Void will not switch from LightDM automatically; you have to disable the LightDM service, enable the SDDM one under runit, and reboot. All the relevant commands are in the description.
There are a few extra points. Void never removes old kernels automatically, so you should learn to use `vkpurge` and periodically clean up the ones you don’t need. GPU drivers are more involved than what I showed: there are additional packages for video acceleration and different paths for AMD, Intel and Nvidia, both open and proprietary; the commenter maintains scripts that automate much of this and I’ve linked them below. Finally, if you enable Flatpak on Void, you really want to add Flathub explicitly as a remote, otherwise your Flatpak experience will be far more limited than it needs to be.
The point of this addendum is simple. My guide is “ultra mega”, but it’s not total. Linux never ends, and on a distro like Void there will always be a deeper layer, a corner case or a hardware quirk that one single video cannot cover. This is exactly what I love about this ecosystem: I release a big guide, someone else comes along and says “good job, here’s how to make it even better”, and suddenly the picture is richer for everyone.