Installation de Void Linux : la distribution minimaliste qui paraît étonnamment moderne

Pourquoi Void paraît moderne malgré son minimalisme

Void Linux est minimal d’une manière qui a du sens opérationnel. Vous n’obtenez pas un enchevêtrement de « services cadre » que vous n’avez pas demandés.
Vous obtenez un arbre de fichiers propre, un gestionnaire de paquets sensé et un système d’init qui préfère la clarté à l’ambition.
Cette dernière partie compte : le profil de fiabilité d’un système est souvent dicté par le démarrage et la supervision des services.

Void utilise runit pour l’init et la supervision. Ce n’est pas à la mode. C’est, en revanche, remarquablement direct :
les services sont des répertoires avec des scripts run ; l’activation est un lien symbolique ; les logs peuvent être gérés par un service compagnon.
Quand quelque chose échoue, vous pouvez généralement voir exactement ce qu’il a tenté d’exécuter et pourquoi ça n’a pas fonctionné.

Le gestionnaire de paquets est xbps. Il est rapide, cohérent et rafraîchissant dans sa modestie.
Il n’y a pas d’« opéra du solveur de dépendances » avant chaque transaction. Il installe des paquets, vérifie l’intégrité, et passe à la suite.
Pour une distro minimaliste, c’est la modernité adéquate : se concentrer sur les mécanismes qui réduisent la friction opérationnelle.

Une citation qui devrait être imprimée à l’intérieur de chaque capot d’ordinateur portable :
Idée paraphrasée (Werner Vogels) : tout finit par tomber en panne ; concevez des systèmes pour que la panne soit attendue et récupérable.

La force de Void est qu’il ne prétend pas que la panne n’arrivera pas. Il vous donne moins de pièces mobiles et une meilleure visibilité.
Cela n’élimine pas les erreurs. Ça les rend juste plus faciles à diagnostiquer, et c’est là le vrai bénéfice.

Faits intéressants et contexte (les éléments qu’on oublie)

• Void est indépendant : ce n’est pas un dérivé de Debian/Ubuntu/Fedora. Cette indépendance se voit dans les outils et les choix par défaut.
• Origine de runit : runit remonte au début des années 2000 et a été utilisé en production dans des contextes embarqués et des appliances.
• xbps n’est pas un wrapper : c’est un système de paquets natif (paquets binaires + dépôts), pas une interface pour autre chose.
• Builds glibc et musl : Void maintient les deux, vous permettant de choisir compatibilité (glibc) ou une libc plus légère (musl).
• Rolling release, mais curation : c’est une rolling release, pourtant les paquets restent généralement cohérents — moins de « roulette de rebuild quotidienne ».
• Philosophie de l’installateur : l’ISO live est volontairement spartiate ; vous n’obtenez pas un assistant qui cache le partitionnement derrière des animations joyeuses.
• Modèle de stages de runit : le démarrage est découpé en étapes, et « l’arbre de supervision des services » est explicite plutôt qu’émergent.
• xbps-alternatives : Void utilise un système d’alternatives pour gérer les implémentations par défaut (par ex., quel éditeur est « vi »).
• XBPS garde des métadonnées localement : vous pouvez inspecter ce qui est installé et pourquoi avec des requêtes simples, sans contacter un serveur externe.

Blague 1/2 : Void s’appelle « Void » parce qu’il commence vide ; l’avantage, c’est qu’il commence aussi sans drame.

Décisions à prendre avant de lancer l’installateur

glibc vs musl

Choisissez glibc sauf si vous avez une raison précise de ne pas le faire. La plupart des binaires tiers l’attendent.
musl est excellent pour certains usages (conteneurs plutôt statiques, systèmes plus petits), mais il peut représenter un coût de compatibilité
que vous ne voulez pas sur une machine d’usage quotidien ou un poste de travail.

UEFI vs BIOS legacy

Si votre machine date de la dernière décennie, vous êtes presque certainement en UEFI. Utilisez-le correctement :
partitionnement GPT, une partition système EFI (ESP), et un chargeur d’amorçage qui correspond à votre modèle de menace et à votre tolérance au bidouillage.

Choix du système de fichiers (la bifurcation ennuyeuse qui compte ensuite)

Si vous voulez un seul système de fichiers qui se comporte bien, choisissez ext4.
Si vous avez de très gros fichiers et que vous vous souciez du parallélisme I/O, XFS est adapté (mais respectez les contraintes de redimensionnement).
Si vous voulez des snapshots et que vous êtes prêt à apprendre la discipline opérationnelle, btrfs peut être excellent.
Si vous êtes un spécialiste stockage et que vous voulez checksumming + send/receive à grande échelle, ZFS est un choix légitime — ne faites simplement pas croire que c’est « configuré et oublié ».

Chiffrement

Pour les ordinateurs portables et tout ce qui quitte un rack, utilisez le chiffrement complet du disque. LUKS2 est le choix habituel.
Les deux vraies questions : voulez-vous un /boot non chiffré séparé, et avez-vous besoin d’un déverrouillage à distance ?
Si vous ne savez pas, gardez la simplicité : ESP non chiffré, root chiffré, et acceptez de taper une passphrase au démarrage.

Swap et hibernation

Si vous hibernez, vous avez besoin d’un swap dimensionné correctement et configuré convenablement.
Si vous ne le faites pas, le swap reste utile comme soupape de pression. Un petit fichier ou partition de swap suffit.
N’appliquez pas le dogme « jamais de swap » à moins d’aimer voir des compilations étouffées par l’OOM killer.

Installation : guide pratique (UEFI + ext4 + option chiffrement)

L’installateur de Void est simple. Le mode d’échec le plus courant n’est pas « l’installateur est cassé ».
C’est « vous avez fait une hypothèse sur la disposition du disque que vous n’avez pas vérifiée ».
Nous allons donc tout vérifier au fur et à mesure, et préférer les commandes qui montrent ce qu’elles font.

Étape 0 : démarrez l’ISO live et confirmez le mode firmware

Si vous pensez être en mode UEFI mais que ce n’est pas le cas, votre ESP restera là comme un tiroir bien étiqueté dans une maison sans portes.

cr0x@server:~$ ls /sys/firmware/efi
config_table  efivars  fw_platform_size  runtime  runtime-map  systab

Ce que signifie la sortie : Si /sys/firmware/efi existe et contient des entrées, vous avez démarré en mode UEFI.
Décision : Continuez avec GPT + ESP. Si c’est absent, redémarrez et sélectionnez l’entrée de démarrage UEFI dans le firmware.

Étape 1 : identifiez le disque cible (ne devinez pas)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MODEL
NAME   SIZE TYPE FSTYPE MODEL
sda   476.9G disk        Samsung SSD 860
├─sda1  512M part vfat
└─sda2 476.4G part

Ce que signifie la sortie : Vous voyez les disques et partitions, avec tailles et (si présents) types de système de fichiers.
Décision : Confirmez que vous installez sur le bon périphérique (/dev/sda ici). Si vous êtes sur un serveur avec plusieurs disques, arrêtez-vous et étiquetez-les.

Étape 2 : partitionnement (exemple de layout)

Layout UEFI minimal :
une ESP (512 MiB) + une partition root (le reste). Si vous chiffrez, la root devient un conteneur LUKS.

cr0x@server:~$ sudo parted -s /dev/sda mklabel gpt
cr0x@server:~$ sudo parted -s /dev/sda mkpart ESP fat32 1MiB 513MiB
cr0x@server:~$ sudo parted -s /dev/sda set 1 esp on
cr0x@server:~$ sudo parted -s /dev/sda mkpart primary 513MiB 100%
cr0x@server:~$ sudo parted -s /dev/sda print
Model: Samsung SSD 860 (scsi)
Disk /dev/sda: 512GB
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB                ESP   boot, esp
 2      538MB   512GB   511GB                primary

Ce que signifie la sortie : GPT existe, la partition 1 est marquée ESP, la partition 2 est la charge utile principale.
Décision : Si les flags n’affichent pas boot, esp sur la partition 1, corrigez cela maintenant. Les problèmes de démarrage UEFI sont souvent auto-infligés.

Étape 3 : formatez les systèmes de fichiers (chemin non chiffré)

cr0x@server:~$ sudo mkfs.vfat -F32 -n EFI /dev/sda1
mkfs.fat 4.2 (2021-01-31)
cr0x@server:~$ sudo mkfs.ext4 -L void-root /dev/sda2
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 124999680 4k blocks and 31250432 inodes
Filesystem UUID: 9f6b7f39-3c4a-4cb2-8f54-5c3c2f9911a2
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000

Ce que signifie la sortie : L’ESP est en FAT32, la racine en ext4 avec un label et un UUID.
Décision : Si vous prévoyez d’utiliser le chiffrement, ne formatez pas /dev/sda2 en ext4 maintenant — suivez plutôt le chemin chiffré suivant.

Étape 3b : chemin chiffrement (LUKS2 + ext4 à l’intérieur)

cr0x@server:~$ sudo cryptsetup luksFormat /dev/sda2
WARNING: Device /dev/sda2 already contains a 'ext4' superblock signature.
Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sda2:
Verify passphrase:
cr0x@server:~$ sudo cryptsetup open /dev/sda2 cryptroot
Enter passphrase for /dev/sda2:
cr0x@server:~$ sudo mkfs.ext4 -L void-root /dev/mapper/cryptroot
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 124900352 4k blocks and 31227904 inodes
Filesystem UUID: 5c1a1d6b-6a4f-4b2e-88fb-f0b4af56c0a3

Ce que signifie la sortie : La partition est maintenant un conteneur chiffré, ouvert comme /dev/mapper/cryptroot, et ext4 vit à l’intérieur.
Décision : Notez l’UUID LUKS plus tard pour crypttab/dracut. Décidez aussi si vous avez besoin d’un fichier-clé (souvent non sur les portables).

Étape 4 : montez la disposition cible

cr0x@server:~$ sudo mount /dev/mapper/cryptroot /mnt
cr0x@server:~$ sudo mkdir -p /mnt/boot/efi
cr0x@server:~$ sudo mount /dev/sda1 /mnt/boot/efi
cr0x@server:~$ mount | grep -E '(/mnt|efi)'
/dev/mapper/cryptroot on /mnt type ext4 (rw,relatime)
/dev/sda1 on /mnt/boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

Ce que signifie la sortie : La racine et l’ESP sont montées là où l’installateur placera le système et les artefacts de démarrage.
Décision : Si l’ESP est montée ailleurs, corrigez-le. Vous voulez un point de montage ESP unique et évident.

Étape 5 : lancez l’installateur et gardez-le honnête

Void fournit un installateur TUI. Utilisez-le. Mais vérifiez ce qu’il a fait : vous êtes l’ingénieur d’astreinte maintenant, pas l’installateur.

Après l’installation, chrootez ou démarrez dans le nouveau système et vérifiez les fondamentaux : /etc/fstab, le chargeur de démarrage, l’initramfs, le réseau, l’heure, les utilisateurs.
Le reste est une question de préférences.

Étape 6 : état d’esprit pour la première mise en route

Votre premier démarrage n’est pas « est-ce qu’on arrive à un prompt de connexion ». Votre premier démarrage est « est-ce que je comprends comment il se comportera le pire jour de ma semaine ».
Cela signifie : comment les services démarrent, où vont les logs, comment les mises à jour sont appliquées, et comment la machine est récupérée si le réseau est cassé.

Tâches pratiques : commandes, sorties et décisions suivantes

Ce sont les vérifications que je fais sur toute installation neuve. Elles ne sont pas cérémoniales.
Chacune est là parce que j’ai vu l’absence de cette vérification se transformer en ticket.

Tâche 1 : confirmez que vous avez démarré avec le noyau que vous pensez avoir installé

cr0x@server:~$ uname -a
Linux voidbox 6.6.15_1 #1 SMP PREEMPT_DYNAMIC Thu Jan 18 10:22:01 UTC 2024 x86_64 GNU/Linux

Ce que signifie la sortie : Version du noyau et architecture.
Décision : Si le noyau est plus ancien que prévu, vous avez probablement démarré l’entrée incorrecte ou n’avez pas installé le méta-paquet du noyau voulu.

Tâche 2 : vérifiez les UUID et labels des disques avant d’écrire /etc/fstab

cr0x@server:~$ blkid
/dev/sda1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="7C2A-1B3D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ESP" PARTUUID="e2b7c5a1-6d8d-4e5c-a2b3-7f3a0d4b9b0c"
/dev/sda2: UUID="f1b2c3d4-1111-2222-3333-abcdefabcdef" TYPE="crypto_LUKS" PARTUUID="7a9c8d6e-aaaa-bbbb-cccc-1234567890ab"
/dev/mapper/cryptroot: LABEL="void-root" UUID="5c1a1d6b-6a4f-4b2e-88fb-f0b4af56c0a3" BLOCK_SIZE="4096" TYPE="ext4"

Ce que signifie la sortie : Identifiants stables pour les montages et le mapping de chiffrement.
Décision : Utilisez les UUID dans /etc/fstab et (si chiffré) dans votre ligne de commande dracut/config de crypt ; évitez les /dev/sdaX bruts.

Tâche 3 : validez les options de montage et l’espace disponible

cr0x@server:~$ df -hT
Filesystem              Type   Size  Used Avail Use% Mounted on
/dev/mapper/cryptroot   ext4   468G  2.6G  441G   1% /
/dev/sda1               vfat   511M   12M  500M   3% /boot/efi
tmpfs                   tmpfs  3.1G     0  3.1G   0% /run

Ce que signifie la sortie : Types de systèmes de fichiers, tailles et points de montage.
Décision : Assurez-vous que /boot/efi n’est pas sur le système racine. Si c’est le cas, vos artefacts UEFI pourraient ne pas être persistants.

Tâche 4 : vérifiez que l’init est bien runit

cr0x@server:~$ ps -p 1 -o pid,comm,args
  PID COMMAND         COMMAND
    1 runit           runit

Ce que signifie la sortie : PID 1 est runit.
Décision : Si PID 1 n’est pas runit, vous n’êtes pas sur Void comme prévu, ou vous êtes dans un conteneur/chroot.

Tâche 5 : lister les services activés (ce qui démarrera au boot)

cr0x@server:~$ ls -l /var/service
total 0
lrwxrwxrwx 1 root root  16 Jan 20 09:10 dhcpcd -> /etc/sv/dhcpcd
lrwxrwxrwx 1 root root  14 Jan 20 09:10 sshd -> /etc/sv/sshd
lrwxrwxrwx 1 root root  15 Jan 20 09:10 socklog-unix -> /etc/sv/socklog-unix
lrwxrwxrwx 1 root root  13 Jan 20 09:10 nanoklogd -> /etc/sv/nanoklogd

Ce que signifie la sortie : Chaque lien symbolique est un service activé supervisé par runit.
Décision : Si quelque chose de critique manque (réseau, logs, ssh pour les machines distantes), activez-le maintenant plutôt que de le découvrir pendant une panne.

Tâche 6 : vérifiez le statut d’un service comme un adulte (pas au feeling)

cr0x@server:~$ sudo sv status sshd
run: sshd: (pid 842) 37s

Ce que signifie la sortie : Le service fonctionne, avec PID et durée d’activité.
Décision : Si ça affiche down ou fail, ouvrez le script run et les logs avant de modifier au hasard la config.

Tâche 7 : vérifiez que les logs existent et sont collectés

cr0x@server:~$ sudo sv status socklog-unix
run: socklog-unix: (pid 520) 5m12s
cr0x@server:~$ sudo ls -lah /var/log/socklog
total 16K
drwx------  4 root root 4.0K Jan 20 09:11 .
drwxr-xr-x 11 root root 4.0K Jan 20 09:11 ..
drwx------  2 root root 4.0K Jan 20 09:11 kernel
drwx------  2 root root 4.0K Jan 20 09:11 sshd

Ce que signifie la sortie : socklog tourne et écrit des logs par service.
Décision : Si les logs manquent, corrigez la journalisation avant de « tuner les performances ». Vous ne pouvez pas optimiser ce que vous n’observez pas.

Tâche 8 : vérifiez la configuration des dépôts et effectuez une synchronisation sûre

cr0x@server:~$ xbps-query -L
 997 https://repo-default.voidlinux.org/current (RSA signed)
cr0x@server:~$ sudo xbps-install -S
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
x86_64-repodata: 1824KB [avg rate: 410KB/s]

Ce que signifie la sortie : Les dépôts sont configurés et la mise à jour des métadonnées se fait proprement.
Décision : Si la vérification de signature échoue, arrêtez-vous. Corrigez la synchronisation horaire, les URLs de dépôt, ou l’état des clés avant d’installer autre chose.

Tâche 9 : auditez ce qui tient votre système de base ensemble

cr0x@server:~$ xbps-query -m | head
base-system-0.114_1
linux6.6-6.6.15_1
linux-firmware-20240115_1
runit-2.1.2_12
xbps-0.59.2_2

Ce que signifie la sortie : Les méta-paquets fournissent la base « ça ressemble à un système ».
Décision : Gardez base-system sauf si vous avez une raison bien documentée de vous en écarter.

Tâche 10 : vérifiez la résolution DNS (parce que « réseau up » n’est pas « utilisable »)

cr0x@server:~$ getent hosts repo-default.voidlinux.org
2a04:4e42:600::644  repo-default.voidlinux.org
2a04:4e42::644       repo-default.voidlinux.org

Ce que signifie la sortie : La résolution de noms fonctionne via NSS, renvoyant des adresses IP.
Décision : Si cela échoue mais que vous pouvez pinger une IP, le problème est la configuration DNS — généralement la propriété de /etc/resolv.conf ou le client DHCP.

Tâche 11 : confirmez la synchronisation horaire (TLS et signatures de paquets s’en soucient)

cr0x@server:~$ date -u
Sat Jan 20 09:18:44 UTC 2024

Ce que signifie la sortie : Heure UTC courante.
Décision : Si elle est incorrecte de plusieurs minutes/heures, corrigez NTP (ex. chrony) avant d’accuser le « SSL cassé » pour les téléchargements de paquets.

Tâche 12 : validez l’existence des entrées de démarrage (réalité UEFI)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001
Boot0001* UEFI: Built-in EFI Shell	RC
Boot0003* VoidLinux	HD(1,GPT,e2b7c5a1-6d8d-4e5c-a2b3-7f3a0d4b9b0c,0x800,0x100000)/File(\EFI\void\grubx64.efi)

Ce que signifie la sortie : Votre firmware voit une entrée VoidLinux pointant vers un binaire EFI sur l’ESP.
Décision : S’il n’y a pas d’entrée, vous démarrerez par hasard. Corrigez l’installation du chargeur avant de redémarrer dans la confusion.

Tâche 13 : inspectez la génération d’initramfs (surtout pour le chiffrement)

cr0x@server:~$ ls -lh /boot | head
total 88M
-rw-r--r-- 1 root root  32M Jan 20 09:05 initramfs-6.6.15_1.img
-rw-r--r-- 1 root root  12M Jan 20 09:05 vmlinuz-6.6.15_1
drwxr-xr-x 3 root root 4.0K Jan 20 09:05 grub

Ce que signifie la sortie : Noyau et initramfs existent et ont une taille plausible.
Décision : Si l’initramfs manque, le démarrage peut échouer après des mises à jour du noyau. Assurez-vous que les hooks dracut sont installés et configurés.

Tâche 14 : confirmez l’état TRIM sur le SSD (hygiène de stockage)

cr0x@server:~$ lsblk -D
NAME          DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                  0      512B       2G         0
├─sda1               0      512B       2G         0
└─sda2               0      512B       2G         0

Ce que signifie la sortie : Granularité de discard et taille max exposées.
Décision : Activez fstrim périodique (ou montez avec discard si vous acceptez les compromis). Si les valeurs sont zéro, l’appareil peut ne pas supporter TRIM.

Tâche 15 : vérifiez les bases de pression mémoire (ne déployez pas une machine qui meurt sur une compilation)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       1.1Gi       5.6Gi       120Mi       1.0Gi       6.3Gi
Swap:          2.0Gi          0B       2.0Gi

Ce que signifie la sortie : Vous avez du swap et une mémoire disponible raisonnable.
Décision : Si le swap manque sur un portable, ajoutez-en. Si le swap est énorme sur un petit SSD, reconsidérez — l’usure est réelle, mais la stabilité aussi.

runit : gestion des services qui ne vous fera pas douter de vous

r u n i t n’est pas une marque de style de vie. C’est un superviseur. Il exécute les services, les redémarre lorsqu’ils plantent,
et fournit une interface cohérente pour vérifier le statut et les gérer.
Le modèle mental est : « un service est un répertoire avec un script exécutable run. »

Activer et désactiver des services

L’activation est un lien symbolique vers /var/service. La désactivation supprime ce lien.
C’est si évident que ça semble suspectement devoir être plus compliqué. Ce n’est pas le cas.

cr0x@server:~$ sudo ln -s /etc/sv/sshd /var/service
cr0x@server:~$ sudo sv status sshd
run: sshd: (pid 1123) 4s

Ce que signifie la sortie : Une fois le lien présent, runit supervise immédiatement le service.
Décision : Si un service démarre de façon inattendue au moment de l’activation, ce n’est pas une surprise ; c’est le contrat. Planifiez les changements en conséquence.

Où vit la configuration

Les scripts run des services vivent sous /etc/sv/<service>/run. Beaucoup de services ont aussi /etc/sv/<service>/conf.
Si vous voulez changer la façon dont un service démarre, faites-le là, pas en espérant qu’un générateur d’unités détecte votre humeur.

La journalisation est une préoccupation première (si vous la choisissez)

Un schéma courant est un répertoire log séparé sous le service, géré par svlogd.
Cela vous donne des logs locaux prévisibles sans les hypothèses du journal systemd.
Si vous centralisez les logs (et vous devriez pour tout ce qui est important), conservez quand même des logs locaux.
Ils sont l’enregistreur de boîte noire quand le réseau est en feu.

Choix de stockage : ext4, XFS, btrfs, ZFS (et mon choix)

Le stockage est l’endroit où les distributions minimalistes brillent ou s’effondrent. Void vous donne des options sans vous imposer d’en utiliser une.
C’est bien. Mais cela signifie aussi que vous pouvez construire un flocon de neige fragile.

ext4 : le défaut dont vous n’avez pas à vous excuser

ext4 est ennuyeux dans le meilleur sens. Les outils de récupération sont mûrs, les performances sont cohérentes, et la plupart des modes de défaillance sont familiers.
Si votre objectif est « poste de travail qui démarre toujours » ou « serveur qui ne surprend jamais », ext4 est une excellente base.

XFS : rapide, stable, mais respectez les limites

XFS aime le I/O parallèle et les gros systèmes de fichiers. Il s’attend aussi à ce que vous soyez délibéré sur la croissance et les procédures de réparation.
Si vous avez l’habitude de redimensionner des partitions et systèmes de fichiers dans n’importe quel ordre, apprenez d’abord la séquence correcte.

btrfs : des fonctionnalités avec des obligations opérationnelles

Snapshots, subvolumes, send/receive — btrfs peut rendre le rollback et les sauvegardes plus propres.
Mais btrfs n’est pas une « fiabilité gratuite ». Ce sont des « outils puissants ». Il vous faut une surveillance, des horaires de scrub, et un plan sur ce que signifient les snapshots pour l’utilisation disque.

ZFS : excellent si vous le traitez comme un système de stockage, pas seulement un FS

ZFS est excellent pour l’intégrité des données (checksums) et les flux de réplication (send/receive).
C’est aussi un écosystème différent : modules noyau, attentes mémoire, et un modèle opérationnel qui récompense la discipline.
Si vous installez Void sur un portable, un root ZFS est possible, mais je ne le recommanderais que si vous savez déjà pourquoi vous le voulez.

Blague 2/2 : chaque fois que vous dites « j’utiliserai ZFS pour les snapshots », un vous futur se réserve une soirée de weekend supplémentaire.

Réseau : Wi‑Fi, DHCP, DNS et les parties ennuyeuses

Le réseau n’est pas difficile. Le réseau est juste allergique aux hypothèses.
Void ne cache pas le réseau derrière un gestionnaire monolithique à moins que vous n’en installiez un. Vous pouvez rester simple.

DHCP avec dhcpcd

dhcpcd est couramment utilisé sur Void. Activez-le, vérifiez qu’il tourne, et confirmez qu’il a bien configuré routes et DNS.

cr0x@server:~$ sudo sv status dhcpcd
run: dhcpcd: (pid 610) 8m44s
cr0x@server:~$ ip route
default via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.50 metric 100
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.50 metric 100

Ce que signifie la sortie : La route par défaut existe et pointe vers une passerelle sur l’interface attendue.
Décision : Si la route par défaut manque, vous n’avez pas un « problème DNS ». Vous n’avez pas de chemin vers Internet. Corrigez DHCP ou la configuration statique d’abord.

Wi‑Fi avec wpa_supplicant (pratique et explicite)

Si vous préférez NetworkManager, installez-le. Si vous préférez des configs transparentes, wpa_supplicant fait l’affaire.
L’exigence principale est : stockez les configurations avec les permissions correctes et assurez-vous que le service démarre au boot.

cr0x@server:~$ sudo install -d -m 0700 /etc/wpa_supplicant
cr0x@server:~$ sudo wpa_passphrase "CorpWiFi" "correct horse battery staple" | sudo tee /etc/wpa_supplicant/wpa_supplicant-wlp2s0.conf >/dev/null
cr0x@server:~$ sudo chmod 600 /etc/wpa_supplicant/wpa_supplicant-wlp2s0.conf
cr0x@server:~$ sudo ln -s /etc/sv/wpa_supplicant /var/service
cr0x@server:~$ sudo sv status wpa_supplicant
run: wpa_supplicant: (pid 1337) 2s

Ce que signifie la sortie : La config est créée, sécurisée, et le service tourne.
Décision : S’il tourne mais n’associe pas, vérifiez les noms d’interface et le domaine réglementaire ; ne blâmez pas immédiatement les « pilotes ».

DNS : guerres de propriété de resolv.conf

Les échecs DNS viennent souvent de resolv.conf qui est écrasé (ou pas) par différents composants.
Décidez qui en est responsable : dhcpcd, resolvconf, NetworkManager, ou votre fichier statique. Puis faites en sorte que ce soit vrai.

cr0x@server:~$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 46 Jan 20 09:12 /etc/resolv.conf
cr0x@server:~$ cat /etc/resolv.conf
nameserver 192.168.1.1
search lan

Ce que signifie la sortie : Un fichier simple avec un résolveur local et un domaine de recherche.
Décision : Si cela change sans cesse, identifiez l’écrivain et configurez-le correctement ou retirez-le.

Mises à jour et réflexion sur le rollback avec xbps

Void est une rolling release. C’est acceptable en production si vous traitez les mises à jour comme une activité contrôlée plutôt qu’un passe-temps.
Vous voulez : fenêtres de mise à jour prévisibles, journaux de ce qui a changé, et un plan de récupération après un mauvais démarrage.

Flux de mise à jour : synchroniser, simuler si besoin, puis appliquer

cr0x@server:~$ sudo xbps-install -S
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
x86_64-repodata: 1824KB [avg rate: 390KB/s]
cr0x@server:~$ sudo xbps-install -u
[*] Updating package `openssl-3.2.0_1' ...
[*] Updating package `curl-8.5.0_1' ...
[*] Updating package `linux6.6-6.6.16_1' ...

Ce que signifie la sortie : Les dépôts sont synchronisés ; les paquets sont mis à jour, noyau inclus.
Décision : Les mises à jour du noyau signifient que vous devriez vérifier les artefacts de démarrage et redémarrer selon votre calendrier, pas quand une application l’exige.

Interrogez ce qui a changé et pourquoi

cr0x@server:~$ xbps-query -R linux6.6 | head -n 10
pkgver: linux6.6-6.6.16_1
repository: https://repo-default.voidlinux.org/current
short_desc: Linux kernel and modules (6.6 series)
maintainer: Void Linux team
license: GPL-2.0-only
architecture: x86_64

Ce que signifie la sortie : Métadonnées du paquet et source du dépôt.
Décision : Si un paquet provient d’un dépôt inattendu, vous avez peut-être mélangé des dépôts. C’est comme ça qu’on construit un système qui se met à jour comme une maison hantée.

Conservez un noyau de secours amorçable

Sur tout système qui compte, conservez au moins un noyau connu-bon installé.
Ce n’est pas de la paranoïa ; c’est une police d’assurance bon marché.
Vérifiez que votre chargeur de démarrage le liste bien, et que l’initramfs existe pour celui-ci.

Playbook de diagnostic rapide

Quand Void « rame » ou « ne démarre pas » ou « le réseau est bizarre », vous n’avez pas besoin d’un séminaire philosophique.
Vous avez besoin d’un ordre d’opérations qui trouve rapidement le goulot et évite de tout chambouler.

Première étape : déterminer le domaine de la panne

• Domaine boot/firmware : impossible d’atteindre la connexion, bascule sur un shell d’urgence, ou boucle au chargeur d’amorçage.
• Domaine stockage : attentes I/O, système de fichiers en lecture seule, services qui expirent, gels étranges.
• Domaine réseau : on peut pinger la passerelle mais pas résoudre DNS, ou résoudre mais pas atteindre le distant.
• Domaine service : le système démarre mais l’application/service est arrêté, en clignotement, ou bloqué.

Deuxième étape : vérifiez les observables simples à haute valeur d’information

Ces vérifications sont rapides et ne requièrent pas de croire en quoi que ce soit.

Santé de la chaîne de démarrage

cr0x@server:~$ mount | grep -E ' /boot|/boot/efi '
/dev/sda1 on /boot/efi type vfat (rw,relatime)

Décision : Si l’ESP n’est pas montée, les mises à jour du noyau/initramfs peuvent ne pas mettre à jour le vrai média de démarrage.

Vue de la supervision des services

cr0x@server:~$ sudo sv status /var/service/*
run: dhcpcd: (pid 610) 12m33s
run: nanoklogd: (pid 505) 12m34s
run: socklog-unix: (pid 520) 12m34s
run: sshd: (pid 842) 12m32s

Décision : Si un service critique est down, c’est votre périmètre immédiat. Ne déboguez pas l’application tant que l’état du superviseur n’est pas stable.

Goulot CPU vs I/O

cr0x@server:~$ uptime
 09:34:10 up 25 min,  1 user,  load average: 3.12, 2.40, 1.80
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0      0 5852400 112340 812400    0    0    12    35  412  780 12  4 82  2  0
 2  1      0 5849800 112340 812900    0    0  2400   120  520  900  8  3 61 28  0

Ce que cela signifie : Si wa (I/O wait) est élevé, vous êtes lié au stockage. Si us/sy domine, vous êtes lié au CPU.
Décision : Ne « tunez sysctl » pas avant de savoir si vous attendez le disque.

Troisième étape : isolez le coupable avec des vérifications ciblées

Une fois que vous avez placé le problème dans un domaine, effectuez une étape d’approfondissement adaptée : santé du disque, erreurs du système de fichiers, logs du pilote, tables de routage, scripts run des services.
Évitez les changements larges. Faites une modification, observez, puis poursuivez.

Erreurs courantes : symptômes → cause → correction

1) Symptôme : le système démarre dans le firmware ou « aucun périphérique amorçable »

Cause : ESP non créée correctement, non flaggée, ou entrée de démarrage manquante ; parfois installé en mode legacy.

Correction : Démarrez l’ISO live en mode UEFI, montez l’ESP sur /boot/efi, réinstallez le chargeur, et confirmez avec efibootmgr -v.

2) Symptôme : après des mises à jour, le système tombe dans le shell initramfs (root chiffré introuvable)

Cause : l’initramfs manque les modules crypto ou la ligne de commande du noyau n’indique pas le device LUKS.

Correction : Assurez-vous que dracut inclut le support crypto, vérifiez l’UUID correct, reconstruisez l’initramfs, et validez la ligne de commande du chargeur de démarrage.

3) Symptôme : le réseau « fonctionne » mais xbps ne peut pas télécharger ou TLS échoue

Cause : heure système incorrecte ou résolution DNS défaillante.

Correction : corrigez NTP/chrony ; vérifiez que getent hosts fonctionne ; contrôlez la propriété de /etc/resolv.conf et le comportement du client DHCP.

4) Symptôme : un service redémarre toutes les quelques secondes

Cause : le script run se termine immédiatement (mauvaise config, binaire manquant, mauvaises permissions), le superviseur fait son travail et redémarre.

Correction : inspectez /etc/sv/<service>/run, vérifiez les chemins exécutables, et lisez les logs sous /var/log/socklog.

5) Symptôme : le disque se remplit de façon inattendue sur un système « minimal »

Cause : les logs croissent sans rotation, ou les snapshots/subvolumes (btrfs/ZFS) ne sont pas élagués.

Correction : implémentez la rotation des logs (ou la rétention svlogd), programmez le pruning, et surveillez df -h ainsi que la croissance par répertoire.

6) Symptôme : la mise en veille/réveil d’un portable est instable

Cause : bizarreries du firmware, paquets microcode/firmware manquants, ou paramètres de gestion d’alimentation.

Correction : installez le firmware/microcode approprié, vérifiez les paramètres du noyau, et évitez d’empiler plusieurs outils d’alimentation qui se combattent.

7) Symptôme : vous ne pouvez pas résoudre des noms après l’installation de NetworkManager

Cause : deux composants gèrent /etc/resolv.conf (par ex. dhcpcd + NetworkManager) et se chevauchent.

Correction : choisissez une pile réseau ; désactivez l’autre ; confirmez que /etc/resolv.conf est stable au redémarrage.

8) Symptôme : les mises à jour de paquets se plaignent de signatures ou de métadonnées

Cause : heure système incorrecte, cache corrompu, ou dépôts mélangés.

Correction : corrigez l’heure, videz le cache pertinent si nécessaire, vérifiez la liste des dépôts avec xbps-query -L, et retirez les entrées de dépôts inattendues.

Trois mini-histoires d’entreprise issues du terrain

Mini-histoire 1 : l’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne avait une petite flotte d’agents de compilation. Ils n’étaient pas « production », ce qui a tendance à faire baisser les standards rapidement.
Les agents étaient souvent réimagés, et quelqu’un a proposé Void parce qu’il démarre vite et reste discret.
Bon choix. Le déploiement a été rapide, et la première semaine a été calme.

Puis, un lundi, les builds ont commencé à échouer de façon intermittente. Pas tous. Pas constamment.
Les échecs avaient une saveur réseau : timeouts, téléchargements de paquets qui plantent, erreurs TLS aléatoires.
Le diagnostic initial a été le réflexe habituel : « l’équipe firewall a changé quelque chose ».
Des tickets ont été ouverts. Des réunions ont été planifiées. L’ingénieur d’astreinte a pris un an dans la tronche.

Le vrai problème était une mauvaise hypothèse : que l’heure système serait « suffisamment proche » sans service de synchronisation.
Certains agents démarraient avec un dérèglement d’horloge assez grand pour provoquer des échecs de validation TLS contre certains endpoints.
Ce n’était pas déterministe parce que les horloges firmware dérivaient à des rythmes différents et les images avaient été construites à des moments différents.

La correction a été terriblement simple : installer et activer un démon de synchronisation horaire et ajouter un contrôle préalable dans le script de démarrage de l’agent
qui refusait de démarrer le worker de build si l’heure était complètement décalée. Tout s’est stabilisé immédiatement.
Personne n’a dû changer le firewall. Les réunions ont quand même eu lieu, parce que les réunions sont un sous-système séparé.

Mini-histoire 2 : l’optimisation qui s’est retournée

Une autre organisation gérait un ensemble de postes de développeurs internes servant aussi de bancs d’essai. Quelqu’un a remarqué que le démarrage était « lent »
sur un modèle matériel particulier et a décidé d’optimiser. Le plan : élaguer agressivement les services et supprimer les paquets « inutiles »
de l’installation de base pour réduire le travail au démarrage.

L’optimisation a fonctionné — sur le papier. Le démarrage s’est accéléré de quelques secondes. Puis sont apparues des pannes subtiles.
Les développeurs ont signalé qu’après une mise à jour du noyau, les systèmes échouaient parfois à démarrer, et la récupération nécessitait une clé USB.
Les échecs se concentraient sur les machines les plus « optimisées ».

Le retour de bâton venait de la suppression de ce qui semblait être de l’outillage optionnel autour de la génération d’initramfs et du chargement du firmware.
Les machines démarraient encore sous le noyau courant, donc le changement semblait sans danger.
Mais quand le noyau suivant est arrivé, le système n’a pas reconstruit correctement l’initramfs, et le noyau mis à jour ne trouvait pas la racine chiffrée sur certaines unités.
Ce n’est pas un problème de performance ; c’est un problème de cycle de vie.

La remédiation n’a pas été « arrêter d’optimiser ». Ce fut « optimiser avec contraintes ».
Ils ont restauré l’outillage noyau et initramfs comme baseline protégée, documenté quels paquets étaient non négociables, et mesuré le temps de démarrage de nouveau.
Le démarrage était légèrement plus lent que la version « optimisée » et dramatiquement plus rapide que « démarrer depuis une clé USB pour réparer votre poste ».

Mini-histoire 3 : la pratique ennuyeuse mais correcte qui a sauvé la journée

Une équipe faisait tourner quelques services légers sur des VM Void dans un labo. Rien de glamour : API interne, passerelle métriques, quelques jobs planifiés.
Ils avaient une habitude presque comiquement conservatrice : avant toute fenêtre de mise à jour, ils prenaient un snapshot au niveau hyperviseur
et exportaient un rapport d’état système en texte (noyau, liste de paquets, services activés, configs clés).

Une mise à jour a introduit une régression réseau spécifique à la version du pilote NIC virtuel. Les VMs démarraient, mais l’interface ne remontait jamais.
Cela aurait pu tourner en incident majeur parce que les services dépendaient d’autres pipelines de test.
Au lieu de cela, l’ingénieur d’astreinte a suivi le runbook : confirmer l’état de dhcpcd, confirmer l’état du lien, comparer le rapport d’état, et rollback.

Le rollback n’a pas été un aveu d’échec ; c’était une réponse contrôlée.
Ils ont restauré le service en minutes, puis reproduit le problème dans une VM sacrificielle.
Avec le rapport de baseline, ils ont pu dire exactement ce qui avait changé. Cela a réduit l’espace de problème de « n’importe quoi sur Internet » à « une poignée de paquets ».

La correction finale a été d’épingler un paquet pour une courte période et de planifier la mise à jour une fois la régression résolue en amont.
La pratique ennuyeuse — snapshots + rapports d’état — a fait la différence entre un incident mineur et une journée de chaos.
Ce n’était pas ingénieux. C’était correct.

Checklists / plan d’action pas à pas

Plan d’installation (UEFI portable/poste, paramètres sensés)

1. Démarrez l’ISO live en mode UEFI ; confirmez avec ls /sys/firmware/efi.
2. Identifiez le disque cible avec lsblk ; débranchez les disques supplémentaires si possible.
3. Créez GPT, ESP (512 MiB), et partition root avec parted.
4. Formatez l’ESP en FAT32 ; créez LUKS2 sur root si chiffrement ; formatez ext4 à l’intérieur.
5. Montez root sur /mnt, ESP sur /mnt/boot/efi.
6. Lancez l’installateur ; définissez hostname, locale, timezone ; créez un utilisateur.
7. Au premier démarrage : vérifiez que /etc/fstab utilise des UUID ; vérifiez que les entrées de démarrage existent.
8. Activez la journalisation (socklog) et la synchronisation horaire ; vérifiez le réseau et le DNS.
9. Exécutez xbps-install -S puis xbps-install -u dans une fenêtre contrôlée.
10. Redémarrez après les mises à jour du noyau ; confirmez l’existence d’un noyau de secours.

Checklist de base opérationnelle (le paquet « moi futur »)

• Accès distant : sshd activé et confirmé en fonctionnement ; clés installées ; politique d’authentification par mot de passe déterminée.
• Logs : logs locaux présents et limités ; décision prise sur la centralisation.
• Temps : synchronisation horaire activée ; horloge correcte au démarrage.
• Mises à jour : cadence de mises à jour définie ; plan de reboot pour noyau existant.
• Sauvegardes : au moins une méthode d’image/snapshot système ; test de restauration effectué une fois.
• Hygiène stockage : fstrim périodique si SSD ; surveillance de la croissance d’utilisation disque.
• Propriété réseau : un seul outil gère DHCP/DNS ; pas de managers en conflit.

Étapes de durcissement qui valent l’effort (et celles à éviter)

À faire :
configuration SSH solide, paquets minimaux installés, mises à jour régulières, chiffrement disque sur appareils mobiles,
et règles basiques de firewall adaptées à votre rôle (poste de travail vs serveur).

À éviter sauf raison :
suites de sécurité élaborées, empiler trois gestionnaires d’alimentation, et collections exotiques de paramètres noyau copiées depuis des inconnus.
La sécurité consiste à réduire la surface d’attaque et maintenir l’hygiène des patches, pas à accumuler des boutons.

FAQ

Void Linux est-il adapté aux serveurs de production ?

Oui, si votre équipe est à l’aise avec une rolling release et que vous avez un processus de mise à jour.
Le modèle opérationnel (runit + xbps) est propre. Le risque n’est pas la distro ; ce sont les mises à jour non gérées et les changements non documentés.

Dois-je choisir musl pour un poste de travail ?

Généralement non. glibc vous évitera des maux de tête de compatibilité avec des binaires tiers et des outils de développement.
Choisissez musl quand vous savez exactement pourquoi vous en avez besoin (et que vous êtes prêt à déboguer les conséquences).

Comment activer un service sur Void ?

Créez un lien symbolique de /etc/sv/<service> vers /var/service/<service>.
Puis vérifiez le statut avec sv status <service>.

Où se trouvent les logs ?

Cela dépend de ce que vous installez et activez. Une configuration courante utilise socklog et stocke les logs sous /var/log/socklog.
Décidez tôt de la gestion des logs ; ne laissez pas cela ambigu.

Quel est le setup de bureau le plus simple ?

Si vous voulez un minimum de friction, utilisez un gestionnaire de fenêtres léger ou un environnement de bureau grand public que vous connaissez déjà.
Installez seulement ce dont vous avez besoin, et ne transformez pas « minimal » en sport de compétition.

Comment gérer les mises à jour du noyau en toute sécurité ?

Mettez à jour pendant une fenêtre, assurez-vous que l’initramfs existe pour le nouveau noyau, conservez au moins un noyau de secours,
et redémarrez selon votre planning. Vérifiez les entrées du chargeur avec efibootmgr -v.

Puis-je faire un chiffrement complet du disque avec une ESP non chiffrée ?

Oui. C’est l’approche UEFI standard : ESP non chiffrée, root chiffré (LUKS2).
Votre modèle de menace déterminera si vous avez aussi besoin de Secure Boot, d’intégration TPM, ou d’un déverrouillage à distance.

Pourquoi mon DNS change-t-il sans arrêt ?

Parce que plusieurs composants essaient de gérer /etc/resolv.conf.
Choisissez-en un : dhcpcd (+ resolvconf si vous l’utilisez), NetworkManager, ou une configuration statique. Puis désactivez les autres.

Void est-il plus difficile qu’Arch ?

Différemment difficile. Arch a des patterns communautaires étendus ; Void a moins de couches et moins de cérémonial.
Void peut paraître plus simple une fois que vous avez intégré runit et xbps, parce qu’il y a moins de « magie » à désapprendre.

Quel est le meilleur système de fichiers pour Void ?

ext4 si vous voulez de la prévisibilité. btrfs si vous voulez des snapshots et que vous allez les gérer.
ZFS si vous opérez intentionnellement un système de stockage et acceptez le modèle opérationnel.
Si vous ne pouvez pas articuler l’échange, choisissez ext4 et passez à autre chose.

Conclusion : prochaines étapes pour rester à l’écart des problèmes

Void Linux est minimal dans ce qui compte : moins d’abstractions entre vous et le comportement de la machine.
Cela en fait une excellente plateforme pour les personnes qui aiment comprendre leurs machines, pas négocier avec elles.
Mais le minimalisme n’excuse pas la paresse opérationnelle. Il rend juste la paresse plus visible.

Prochaines étapes que je ferais effectivement, dans l’ordre :

1. Activez la journalisation et la synchronisation horaire ; vérifiez qu’elles survivent au redémarrage.
2. Sécurisez SSH (ou supprimez-le si vous n’en avez pas besoin) et confirmez que vous pouvez récupérer l’accès.
3. Définissez votre cadence de mises à jour et testez une mise à jour du noyau + reboot hors pression.
4. Choisissez une posture de stockage : ext4 baseline, ou snapshots avec btrfs/ZFS — avec surveillance et élagage.
5. Rédigez un runbook local d’une page : disposition disque, UUIDs de chiffrement, services activés, et comment amorcer un noyau de secours.

L’objectif n’est pas de construire le système le plus minimal d’Internet. L’objectif est de construire un système que vous pouvez exploiter calmement quand il se comporte mal.
Void vous donne les outils. Utilisez-les comme si vous étiez celui qui recevra l’alerte à 3h du matin — parce que vous pourriez l’être.