NixOS : installer avec une flake minimale sans disko

Le Lab 1 installe NixOS avec disko et une flake ensemble, tout est automatisé, du partitionnement à la configuration. Mais que fait la flake exactement ? Que fait disko ? Pour le comprendre, il faut les séparer. Ce lab installe NixOS dans une VM KVM en partitionnant manuellement avec fdisk et en utilisant une flake minimale qui ne contient qu'un seul input : nixpkgs. À la fin, vous obtenez le même résultat fonctionnel que le Lab 1, mais vous savez précisément ce que chaque pièce apporte.

Ce que vous allez apprendre

• Partitionner manuellement un disque en GPT avec fdisk (ESP + root)
• Générer la configuration matérielle avec nixos-generate-config
• Créer une flake minimale avec un seul input (nixpkgs), sans disko
• Installer NixOS avec nixos-install --flake et comprendre ce que la flake verrouille
• Comparer cette approche avec le Lab 1 pour choisir quand utiliser disko

Dans quel contexte ?

Ce lab répond à des situations concrètes :

• Vous avez suivi le Lab 1, mais vous ne savez pas ce que disko fait exactement par rapport à la flake
• Vous préférez contrôler le partitionnement vous-même, comme sur une installation Arch ou Debian
• Vous voulez comprendre le socle minimal d'une installation NixOS : un fichier flake.nix, un fichier configuration.nix, et c'est tout
• Vous envisagez de provisionner des machines où disko n'est pas souhaité (serveurs existants, partitionnement spécifique)

Différence avec le Lab 1

Le tableau ci-dessous isole ce que disko apportait au Lab 1. Concentrez-vous sur les deux premières lignes : tout le reste en découle. Dès que le partitionnement redevient manuel, hardware-configuration.nix reprend son rôle, et l'input disko disparaît de la flake. La reproductibilité de la configuration logicielle, elle, ne change pas d'un lab à l'autre : c'est la flake qui la porte, pas disko.

Aspect	Lab 1 (flake + disko)	Lab 2 (flake seule)
Partitionnement	Déclaratif (disko-config.nix)	Manuel (fdisk + mkfs)
Inputs de la flake	nixpkgs + disko	nixpkgs uniquement
Montage	Automatique (disko)	Manuel (mount)
hardware-configuration.nix	Non utilisé (disko gère tout)	Généré par nixos-generate-config
Reproductibilité du disque	Totale (relancer disko suffit)	Manuelle (refaire fdisk)
Complexité	Plus de fichiers, mais tout automatisé	Moins de fichiers, mais gestes manuels

Glissez pour voir

L'objectif n'est pas de dire qu'une méthode est meilleure que l'autre. C'est de comprendre le rôle de chacune avant de décider quoi automatiser.

Prérequis

• Le Lab 1 terminé (vous savez créer une VM KVM et booter sur l'ISO NixOS)
• KVM/QEMU et libvirt opérationnels sur l'hôte
• L'ISO NixOS 25.11 minimale téléchargée
• Une clé SSH existante sur l'hôte
• Familiarité avec les flakes Nix (structure inputs/outputs)

Lab 2, Installer NixOS avec une flake minimale

Créer la VM

Réutilisez l'ISO du Lab 1, mais avec un disque neuf pour repartir d'un disque vierge. Deux options de cette commande conditionnent la suite du lab. Le bloc --boot loader=...OVMF_CODE_4M.fd démarre la VM en UEFI au lieu du BIOS hérité, ce qui est indispensable puisque vous installerez systemd-boot sur une partition ESP. Et bus=virtio fait apparaître le disque sous le nom /dev/vda, celui que le reste du guide utilise.

Chemin du micrologiciel OVMF

Le chemin /usr/share/OVMF/OVMF_CODE_4M.fd correspond au paquet ovmf sur Debian et Ubuntu. Sur la famille RHEL, le fichier fourni par edk2-ovmf se trouve dans /usr/share/edk2/ovmf/. Contrôlez le chemin réel avec ls /usr/share/OVMF/OVMF_CODE_4M.fd avant de lancer la commande.

# Créer le disque virtuel
qemu-img create -f qcow2 ~/lab-nixos/images/nixos-lab2.qcow2 20G

# Créer la VM
virt-install \
  --name nixos-lab2 \
  --ram 8192 \
  --vcpus 4 \
  --disk path=$HOME/lab-nixos/images/nixos-lab2.qcow2,format=qcow2,bus=virtio \
  --cdrom $HOME/lab-nixos/images/latest-nixos-minimal-x86_64-linux.iso \
  --os-variant nixos-unstable \
  --network network=default,model=virtio \
  --graphics vnc,listen=127.0.0.1 \
  --boot loader=/usr/share/OVMF/OVMF_CODE_4M.fd,loader.readonly=yes,loader.type=pflash,loader.secure=no \
  --noautoconsole

Préparer l'accès SSH à l'installateur

L'ISO NixOS 25.11 démarre avec un utilisateur nixos connecté automatiquement sur la console. SSH est actif, mais il faut définir un mot de passe pour se connecter :

# Attendre ~40 secondes que l'ISO boot, puis définir le mot de passe
# La commande passwd est destinée à l'utilisateur nixos (connecté sur la console)
virsh send-key nixos-lab2 KEY_P KEY_A KEY_S KEY_S KEY_W KEY_D KEY_ENTER
sleep 3
# Taper le mot de passe "nixos" (deux fois)
for key in KEY_N KEY_I KEY_X KEY_O KEY_S; do
  virsh send-key nixos-lab2 $key; sleep 0.3
done
virsh send-key nixos-lab2 KEY_ENTER
sleep 1
for key in KEY_N KEY_I KEY_X KEY_O KEY_S; do
  virsh send-key nixos-lab2 $key; sleep 0.3
done
virsh send-key nixos-lab2 KEY_ENTER

Récupérez l'IP et connectez-vous en tant que nixos, puis basculez en root :

virsh domifaddr nixos-lab2
sshpass -p 'nixos' ssh -o StrictHostKeyChecking=no nixos@192.168.122.x

Utilisateur par défaut de l'ISO 25.11

L'ISO NixOS 25.11 minimale connecte automatiquement l'utilisateur nixos (pas root) sur la console. Le mot de passe défini par passwd via virsh send-key s'applique donc à cet utilisateur. L'utilisateur nixos est dans le groupe wheel et peut utiliser sudo.

Une fois connecté, passez en root pour les opérations d'installation :

sudo -i

Partitionner manuellement avec fdisk

C'est la différence principale avec le Lab 1 : pas de disko-config.nix, tout se fait à la main.

Créez une table GPT avec deux partitions :

• Partition 1 : ESP (EFI System Partition) de 512 Mo
• Partition 2 : racine ext4 occupant le reste du disque

fdisk /dev/vda

Dans fdisk, tapez les commandes suivantes :

g        ← créer une nouvelle table GPT
n        ← nouvelle partition
1        ← numéro 1
[Entrée] ← secteur de début par défaut
+512M    ← taille 512 Mo
t        ← changer le type
1        ← type EFI System
n        ← nouvelle partition
2        ← numéro 2
[Entrée] ← secteur de début par défaut
[Entrée] ← tout l'espace restant
w        ← écrire et quitter

Vérification :

lsblk -o NAME,FSTYPE,SIZE /dev/vda
# NAME   FSTYPE  SIZE
# vda             20G
# ├─vda1          512M
# └─vda2         19.5G

Formater les partitions

Les deux partitions n'ont pas le même système de fichiers, et ce n'est pas un choix esthétique. Le micrologiciel UEFI ne sait lire que du FAT32, la partition ESP n'a donc pas d'alternative. La racine, elle, reçoit de l'ext4, qui accepte les liens symboliques et les permissions dont le store Nix a besoin.

mkfs.fat -F32 -n BOOT /dev/vda1
mkfs.ext4 -L nixos /dev/vda2

Le label -n BOOT et -L nixos facilitent l'identification, mais NixOS utilise les UUID (via hardware-configuration.nix) pour monter les partitions, ce qui est plus fiable.

Monter les partitions

L'ordre de ces trois commandes est imposé : /mnt/boot est un répertoire de la partition racine, il ne peut donc être créé qu'une fois cette racine montée. C'est aussi cette arborescence que nixos-generate-config inspectera à l'étape suivante pour déduire les entrées fileSystems. Un montage oublié se traduit par une configuration matérielle incomplète, et par un système qui ne trouve pas sa partition ESP au démarrage.

mount /dev/vda2 /mnt
mkdir -p /mnt/boot
mount /dev/vda1 /mnt/boot

Vérification :

lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT /dev/vda
# NAME   FSTYPE  SIZE MOUNTPOINT
# vda             20G
# ├─vda1 vfat    512M /mnt/boot
# └─vda2 ext4   19.5G /mnt

Générer la configuration matérielle

nixos-generate-config inspecte le matériel et crée deux fichiers :

nixos-generate-config --root /mnt

Résultat :

• /mnt/etc/nixos/hardware-configuration.nix, modules noyau, UUID des partitions, type de système de fichiers
• /mnt/etc/nixos/configuration.nix, squelette de configuration NixOS (commenté)

Pourquoi hardware-configuration.nix est important ici

Dans le Lab 1, disko gère le partitionnement et le montage de façon déclarative, hardware-configuration.nix n'est pas nécessaire. Ici, c'est lui qui contient les UUID de vos partitions et les modules noyau détectés (virtio, xhci, ahci). Sans ce fichier, NixOS ne saurait pas monter le disque au boot.

Vérifiez le contenu généré :

cat /mnt/etc/nixos/hardware-configuration.nix

Vous devez voir :

• imports = [ qemu-guest.nix ], charge les modules virtio
• fileSystems."/" avec l'UUID de votre partition ext4
• fileSystems."/boot" avec l'UUID de votre partition FAT32

Personnaliser configuration.nix

Remplacez le configuration.nix généré par une version fonctionnelle. La différence avec le Lab 1 : ce fichier importe hardware-configuration.nix au lieu d'un module disko.

/mnt/etc/nixos/configuration.nix

{ config, lib, pkgs, ... }:
{
  imports = [
    ./hardware-configuration.nix
  ];

  # Bootloader UEFI
  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;

  # Réseau
  networking.hostName = "nixos-lab2";
  networking.networkmanager.enable = true;

  # Locale et timezone
  time.timeZone = "Europe/Paris";
  i18n.defaultLocale = "fr_FR.UTF-8";
  console.keyMap = "fr";

  # SSH sécurisé
  services.openssh = {
    enable = true;
    settings = {
      PermitRootLogin = "prohibit-password";
      PasswordAuthentication = false;
    };
  };

  # Utilisateur lab avec accès SSH par clé
  users.users.lab = {
    isNormalUser = true;
    extraGroups = [ "wheel" ];
    openssh.authorizedKeys.keys = [
      "ssh-ed25519 AAAA... votre-cle-publique"
    ];
  };

  # Sudo sans mot de passe (VM de test)
  security.sudo.wheelNeedsPassword = false;

  # Paquets de base
  environment.systemPackages = with pkgs; [
    vim git htop curl tmux
  ];

  # Activer flakes et nix-command
  nix.settings.experimental-features = [ "nix-command" "flakes" ];

  # Garbage collection automatique
  nix.gc = {
    automatic = true;
    dates = "weekly";
    options = "--delete-older-than 30d";
  };

  system.stateVersion = "25.11";
}

Remplacez la clé SSH

Dans configuration.nix, remplacez "ssh-ed25519 AAAA... votre-cle-publique" par le contenu de votre fichier ~/.ssh/id_ed25519.pub (ou id_rsa.pub) sur l'hôte.

Créer la flake minimale

C'est le cœur de ce lab : une flake avec un seul input (nixpkgs), sans disko.

/mnt/etc/nixos/flake.nix

{
  description = "NixOS Lab 2 - Flake minimale sans disko";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-25.11";
  };

  outputs = { self, nixpkgs }: {
    nixosConfigurations.nixos-lab2 = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        ./configuration.nix
      ];
    };
  };
}

Comparée au Lab 1, cette flake est plus simple :

• Un seul input : nixpkgs (pas de disko)
• Un seul module : ./configuration.nix (qui importe lui-même hardware-configuration.nix)
• Pas de disko.nixosModules.disko ni de ./disko-config.nix

Le rôle de la flake reste le même : verrouiller la version de nixpkgs dans flake.lock pour garantir la reproductibilité.

Initialiser Git et verrouiller les dépendances

Les flakes exigent un dépôt Git. Sans lui, nix flake lock échoue :

cd /mnt/etc/nixos
git init
git config user.email "lab@nixos-lab2"
git config user.name "lab"
git add .
git commit -m "initial nixos config with minimal flake"

Verrouillez les dépendances :

nix flake lock

Durée du premier flake lock

Le premier nix flake lock télécharge l'index complet de nixpkgs (~400 Mo). Attendez-vous à quelques minutes selon votre connexion. Les exécutions suivantes seront instantanées grâce au cache.

Committez le fichier de verrouillage :

git add flake.lock
git commit -m "add flake.lock"

Vérifiez la flake :

nix flake metadata

Vous devez voir un seul input (nixpkgs) avec un commit et un hash précis.

Installer NixOS

La syntaxe chemin#nom désigne l'attribut nixosConfigurations.nixos-lab2 de la flake. Le nom après le dièse doit correspondre exactement à celui déclaré dans flake.nix ; une faute de frappe ici produit une erreur d'attribut inexistant, pas un message sur l'installation. Comptez plusieurs minutes, la majeure partie du temps étant consacrée au téléchargement depuis le cache binaire.

nixos-install --flake /mnt/etc/nixos#nixos-lab2 --no-root-passwd

L'installation :

1. Évalue la configuration NixOS à partir de la flake
2. Télécharge les paquets depuis le cache binaire (~2,5 Go)
3. Construit le système complet
4. Installe le bootloader systemd-boot sur la partition ESP

Le message "installation finished!" confirme le succès.

--no-root-passwd est utilisé car notre configuration n'autorise que l'accès SSH par clé.

Préparer le premier démarrage

Le disque contient désormais un système complet, mais la VM démarre encore sur le lecteur CD-ROM virtuel. Éjecter le média avant le redémarrage évite de relancer l'installateur, et évite surtout le cas plus déroutant où le micrologiciel tombe sur un lecteur vide et s'arrête dans un UEFI Shell.

Avant de redémarrer, retirez l'ISO :

# Sur l'hôte (pas dans la VM)
virsh change-media nixos-lab2 sda --eject
virsh reboot nixos-lab2

Si la VM affiche un UEFI Shell au lieu de NixOS

La VM tente de booter sur le CD-ROM éjecté. Corrigez l'ordre de boot :

virsh destroy nixos-lab2
EDITOR="sed -i '/<boot dev=\"cdrom\"\/>/d'" virsh edit nixos-lab2
virsh start nixos-lab2

Vérifier le système après installation

Attendez environ 40 secondes, puis connectez-vous par clé SSH :

# Supprimer l'ancienne clé hôte (a changé après installation)
ssh-keygen -R 192.168.122.x
ssh lab@192.168.122.x

1. Vérifier la version NixOS

   nixos-version
   # 25.11.20260413.7e495b7 (Xantusia)

2. Vérifier le hostname et le noyau

   hostname && uname -r
   # nixos-lab2
   # 6.12.81

3. Vérifier le partitionnement

   lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT /dev/vda
   # NAME   FSTYPE  SIZE MOUNTPOINT
   # vda             20G
   # ├─vda1 vfat    512M /boot
   # └─vda2 ext4   19.5G /

4. Vérifier SSH et la sécurité

   systemctl is-active sshd
   # active
   grep -E "^(PermitRootLogin|PasswordAuthentication)" /etc/ssh/sshd_config
   # PasswordAuthentication no
   # PermitRootLogin prohibit-password

5. Vérifier la configuration déclarative

   /nix/store/...-nixos-system-nixos-lab2-25.11.20260413.7e495b7

   readlink /run/current-system

6. Vérifier la locale

   echo $LANG
   # fr_FR.UTF-8

7. Vérifier que nixos-rebuild fonctionne

   cd /etc/nixos
   sudo nixos-rebuild switch --flake .#nixos-lab2

   Cette commande doit se terminer sans erreur. Elle confirme que la boucle de reconstruction fonctionne.

Comparaison avec le Lab 1

Maintenant que vous avez installé NixOS des deux façons, voici ce que chaque composant apporte :

Ce que la flake fait (dans les deux labs)

La flake n'installe rien et ne touche à aucun disque. Son rôle est d'ordre contractuel : elle fige les sources et la liste des modules, si bien qu'une même flake produit le même système sur n'importe quelle machine, aujourd'hui ou dans six mois. Le fichier qui porte cette garantie est flake.lock, pas flake.nix.

• Verrouille les versions : flake.lock fige le commit exact de nixpkgs
• Déclare les modules : liste les fichiers .nix qui composent la configuration
• Rend l'installation reproductible : deux personnes avec la même flake obtiennent le même système

Ce que disko fait (Lab 1 uniquement)

disko couvre exactement la partie que vous venez de faire à la main dans ce lab : découper, formater, monter. C'est un module NixOS supplémentaire, pas une fonctionnalité du langage Nix ni des flakes, et c'est bien pour cela qu'on peut s'en passer. Le gain apparaît quand vous devez réinstaller : le partitionnement devient rejouable au lieu d'être une séquence de frappes dans fdisk.

• Remplace fdisk/mkfs/mount : le partitionnement est décrit dans disko-config.nix
• Automatise tout le disque : une seule commande crée les partitions, formate et monte
• Élimine hardware-configuration.nix : disko génère directement les entrées fileSystems

Quand utiliser l'une ou l'autre méthode

Le critère de décision tient en une question : qui décide de la géométrie du disque ? Si c'est vous, et que la machine est jetable, disko fait gagner du temps. Si le disque préexiste, avec un chiffrement LUKS ou des volumes LVM déjà en place, disko voudra le réécrire et la flake seule reste le seul choix raisonnable.

Situation	Méthode recommandée
VM de test ou lab	Flake + disko (Lab 1), plus rapide
Serveur avec partitionnement spécifique	Flake seule (Lab 2), plus de contrôle
Déploiement reproductible à grande échelle	Flake + disko + nixos-anywhere (Lab 4)
Apprentissage des fondamentaux	Flake seule (Lab 2), comprendre chaque étape
Machine avec LUKS/LVM existant	Flake seule, adapter hardware-configuration.nix

Glissez pour voir

Dépannage

Deux entrées du tableau piègent presque tout le monde. La première est le message « No space left on device » pendant nixos-install : il ne parle pas du disque mais du /tmp en mémoire de l'installateur, d'où la recommandation de 8 Go de RAM. La seconde est l'échec de nix flake lock faute de dépôt Git : les flakes ne voient que les fichiers suivis par Git, un fichier créé et non ajouté est simplement invisible pour l'évaluation.

Symptôme	Cause probable	Solution
fdisk ne voit pas /dev/vda	Driver virtio absent	Vérifier bus=virtio dans virt-install
nix flake lock échoue	Pas de dépôt Git	git init && git add . && git commit
nixos-install : « No space left on device »	RAM insuffisante	Passer la VM à 8 Go de RAM minimum
Boot : UEFI Shell au lieu de NixOS	Ordre de boot (CD avant HD)	virsh change-media ... --eject puis corriger le XML
SSH « Permission denied » sur l'ISO	Utilisateur nixos, pas root	Se connecter en tant que nixos, puis sudo -i
nixos-generate-config : partitions non détectées	Partitions non montées sous /mnt	mount /dev/vda2 /mnt && mount /dev/vda1 /mnt/boot
nix flake lock : « experimental feature disabled »	Flakes non activés sur l'ISO	Ajouter --extra-experimental-features 'nix-command flakes'

Glissez pour voir

À retenir

1. La flake verrouille les versions, disko gère le disque, ce sont deux responsabilités distinctes
2. Sans disko, le partitionnement est manuel (fdisk + mkfs + mount) et le hardware est décrit par nixos-generate-config
3. hardware-configuration.nix est généré automatiquement et contient les UUID des partitions et les modules noyau, ne le modifiez pas à la main
4. Une flake minimale ne contient qu'un seul input (nixpkgs) et un seul module (configuration.nix)
5. Git est obligatoire avant toute opération nix flake, les flakes ne fonctionnent qu'avec un dépôt initialisé
6. nixos-rebuild switch --flake .#hostname est la commande de reconstruction, elle fonctionne identiquement que l'installation utilise disko ou non
7. L'ISO NixOS 25.11 utilise l'utilisateur nixos (pas root) sur la console, adaptez votre méthode d'accès SSH en conséquence

Prochaines étapes

Lab 1, Installer NixOS avec flakes et disko Revoir l'installation automatisée pour comparer les deux approches

Comprendre les flakes Nix Approfondir le mécanisme inputs/outputs et le verrouillage

Store, profils et générations Comprendre le rollback et le modèle de données NixOS

Les bases du langage Nix Maîtriser la syntaxe des fichiers de configuration

×

📖 Voir la documentation →