Ubuntu 24.04 : mises à jour ont cassé les modules — reconstruire initramfs correctement (Cas n°88)

janvier 28, 2026 • février 3, 2026 • Lecture : 27 min • Views: 8

Cet article vous a aidé ?

Vous appliquez des correctifs sur Ubuntu, vous redémarrez comme un adulte responsable, et la machine vous récompense par une invite initramfs, des interfaces réseau manquantes ou un système racine qui “n’existe plus”.
Bienvenue au cas n°88 : la mise à jour n’a pas “cassé Linux”. Elle a rompu le contrat entre votre noyau, vos modules et l’initramfs censé les relier au démarrage.

La réparation est généralement ennuyeuse : reconstruire l’initramfs correctement, pour le noyau que vous utilisez réellement, avec les modules dont vous avez vraiment besoin, et sans vous mentir sur Secure Boot, DKMS ou ZFS.
L’astuce est de le faire avec suffisamment de rigueur pour que ce soit pérenne après la prochaine mise à jour.

Ce qui a réellement cassé : la chaîne de démarrage et le contrat des modules

Sur Ubuntu 24.04, l’histoire classique d’initramfs reste d’actualité : GRUB charge un noyau (vmlinuz) et une image initramfs (initrd.img).
L’initramfs est un petit système racine en RAM qui contient un early userspace, des scripts et un ensemble choisi de modules noyau nécessaires pour trouver et monter le véritable système racine.

Quand une mise à jour “casse les modules”, ce n’est rarement le noyau qui oublie son travail. C’est généralement l’un des cas suivants :

Vous démarrez un noyau différent de celui que vous croyez (par défaut GRUB modifié, ancien noyau supprimé ou entrée de secours sélectionnée).
Votre initramfs ne correspond pas à votre noyau (mauvaise version, image obsolète, régénération échouée).
Les modules existent sur le disque mais n’ont pas été inclus dans l’initramfs (hooks défectueux, configuration incorrecte, métadonnées de dépendance manquantes).
DKMS n’a pas construit (headers manquants, incompatibilité du compilateur, échec de signature sous Secure Boot).
Secure Boot bloque les modules non signés (NVIDIA, ZFS DKMS, pilotes tiers).
La pile de stockage a changé (nouvel initramfs sans LUKS, LVM, RAID, modules NVMe/HBA ou composants ZFS).

L’état d’esprit opérationnel est simple : le chemin de démarrage est une chaîne. Trouvez l’étape qui contient des artefacts obsolètes et reconstruisez cette étape.
Ne paniquez pas. Ne “réinstallez pas juste l’OS.” Ce n’est pas de l’ingénierie ; c’est une capitulation.

Faits et contexte intéressants (parce que l’histoire se répète à 3h du matin)

initramfs a remplacé initrd principalement parce qu’une archive cpio compressée est plus flexible qu’une image ramdisk de taille fixe.
Le tooling par défaut d’Ubuntu est initramfs-tools avec update-initramfs, tandis que d’autres distributions s’appuient sur dracut ; la mémoire musculaire peut vous trahir.
“Early userspace” est devenu courant quand le stockage est devenu compliqué : LVM sur LUKS sur MDRAID n’est pas quelque chose que vous voulez compiler en dur dans le noyau.
DKMS existe parce que les modules hors arbre sont une réalité : NICs fournisseurs, NVIDIA et systèmes de fichiers spécialisés apparaissent encore dans les parcs réels.
Secure Boot a politisé le chargement des modules : le noyau peut fonctionner, et refuser malgré tout votre module parce que l’histoire des signatures n’est pas réglée.
ZFS sur racine est agréable jusqu’à ce qu’il ne le soit plus : si votre initramfs ne contient pas les composants ZFS, vous ne montez pas la racine, peu importe l’état du pool.
GRUB peut démarrer “correctement” pendant que l’OS est cassé : la transmission réussit, puis l’initramfs ne trouve pas la racine ; les gens blâment GRUB quand même.
Les ruptures d’ABI du noyau sont intentionnelles : les paquets noyau d’Ubuntu changent uname -r, et tout module tiers doit correspondre exactement.

Une idée paraphrasée de W. Edwards Deming : La qualité vient de l’amélioration du processus, pas de l’inspection des échecs après coup.
Le travail sur la fiabilité consiste surtout à construire des processus qui n’engendrent pas d’images initramfs cassées dès le départ.

Mode opératoire de diagnostic rapide

Quand un redémarrage tourne mal après des mises à jour, le temps compte. Voici le chemin le plus court vers la vérité.
Vérifiez ces points dans l’ordre ; arrêtez-vous dès que vous trouvez la divergence.

Première étape : Démarrez-vous le noyau que vous croyez utiliser ?

Si vous pouvez vous connecter : comparez uname -r à ce que vous pensez avoir installé.
Si vous ne le pouvez pas : utilisez les “Options avancées” de GRUB pour démarrer l’ancien noyau et obtenir un shell.

Deuxième étape : L’initramfs existe-t-il et correspond-il à ce noyau ?

Vérifiez que /boot/initrd.img-$(uname -r) existe et est récent.
Inspectez si les modules requis figurent dans l’image (stockage + crypto + pilotes plateforme).

Troisième étape : Les constructions de modules ont-elles échoué (DKMS / headers / Secure Boot) ?

Consultez dkms status et l’état des paquets.
Vérifiez journalctl -b -0 pour les échecs de signature ou de chargement de modules.

Quatrième étape : La découverte du périphérique racine échoue-t-elle ?

“Gave up waiting for root device” signifie pilotes manquants ou UUID erronés.
Vérifiez les UUID dans /etc/fstab, crypttab et la ligne de commande GRUB.

Blague #1 (courte, pertinente) : L’initramfs est comme une trousse de secours — vous ne remarquez que ce qui manque quand vous avez déjà froid et êtes agacé.

Tâches pratiques (commandes, sorties, décisions)

Ces tâches sont conçues pour les systèmes Ubuntu 24.04 utilisant initramfs-tools (par défaut).
Chaque tâche inclut : une commande, une sortie réaliste, ce que cela signifie et la décision à prendre.
Exécutez-les depuis un démarrage fonctionnel (peut-être un noyau plus ancien), un shell de secours ou un ISO live avec le système racine monté.

Tâche 1 — Confirmer le noyau en cours et si vous êtes en démarrage de secours

cr0x@server:~$ uname -r
6.8.0-41-generic

Sens : Votre noyau actif est 6.8.0-41-generic. Tout ce que vous déboguez doit correspondre à cette version.
Décision : Utilisez cette chaîne exacte pour vérifier les répertoires de modules et les images initramfs. Pas de supposition, pas de “presque”.

Tâche 2 — Lister les noyaux installés (et repérer les paquets à moitié retirés)

cr0x@server:~$ dpkg -l 'linux-image-*' | awk '/^ii|^rc/ {print $1, $2, $3}' | head -n 12
ii linux-image-6.8.0-40-generic 6.8.0-40.40
ii linux-image-6.8.0-41-generic 6.8.0-41.41
ii linux-image-generic-hwe-24.04 6.8.0-41.41
rc linux-image-6.8.0-39-generic 6.8.0-39.39

Sens : Vous avez plusieurs noyaux, et l’un est en “rc” (retiré, configuration restante).
Décision : Si vous manquez un noyau antérieur connu comme bon, réinstallez-le. Gardez au moins un noyau de secours tant que le système n’est pas stable.

Tâche 3 — Vérifier qu’une image initramfs existe pour le noyau en cours

cr0x@server:~$ ls -lh /boot/initrd.img-$(uname -r)
-rw-r--r-- 1 root root 114M Dec 31 09:12 /boot/initrd.img-6.8.0-41-generic

Sens : Le fichier initramfs existe et a une taille plausible.
Décision : S’il est absent, minuscule ou daté avant la mise à jour, reconstruisez-le. S’il semble correct, inspectez malgré tout son contenu.

Tâche 4 — Vérifier que le répertoire des modules existe pour ce noyau

cr0x@server:~$ ls -ld /lib/modules/$(uname -r)
drwxr-xr-x 7 root root 4096 Dec 31 09:10 /lib/modules/6.8.0-41-generic

Sens : Les modules pour le noyau en cours existent sur disque.
Décision : Si ce répertoire manque, l’installation du noyau est incomplète (ou vous avez démarré un noyau sans modules). Réparez les paquets d’abord.

Tâche 5 — Confirmer que les métadonnées de dépendance des modules sont présentes (état depmod)

cr0x@server:~$ ls -1 /lib/modules/$(uname -r)/modules.dep /lib/modules/$(uname -r)/modules.alias
/lib/modules/6.8.0-41-generic/modules.alias
/lib/modules/6.8.0-41-generic/modules.dep

Sens : depmod a produit des cartes de dépendances.
Décision : Si elles manquent ou sont vides, exécutez depmod -a et reconstruisez l’initramfs. initramfs-tools dépend de ces métadonnées pour inclure les pilotes.

Tâche 6 — Identifier le type du périphérique racine (NVMe/SATA/LVM/LUKS/ZFS)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE /
/dev/mapper/cryptroot / ext4

Sens : La racine est sur un mapping dm-crypt nommé cryptroot.
Décision : L’initramfs doit inclure dm-crypt et le pilote de stockage en dessous (NVMe, AHCI, RAID, etc.). Si le démarrage échoue, suspectez des modules crypto/stockage manquants ou un crypttab obsolète.

Tâche 7 — Vérifier que crypttab et fstab ont des UUID cohérents

cr0x@server:~$ sudo grep -v '^\s*#' /etc/crypttab
cryptroot UUID=3b5a2d2c-9f1a-4c3b-bfb6-9f8c7e4a1f0e none luks,discard

cr0x@server:~$ sudo blkid | grep 3b5a2d2c-9f1a-4c3b-bfb6-9f8c7e4a1f0e
/dev/nvme0n1p3: UUID="3b5a2d2c-9f1a-4c3b-bfb6-9f8c7e4a1f0e" TYPE="crypto_LUKS" PARTUUID="b6a0..."

Sens : crypttab pointe vers un UUID de périphérique réel.
Décision : Si l’UUID ne correspond pas, l’initramfs attendra indéfiniment un périphérique qui ne viendra pas. Corrigez crypttab/fstab, puis reconstruisez l’initramfs.

Tâche 8 — Inspecter les modules requis à l’intérieur de l’image initramfs

cr0x@server:~$ lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'cryptsetup|dm-crypt|nvme|ahci|zfs' | head
usr/sbin/cryptsetup
lib/modules/6.8.0-41-generic/kernel/drivers/md/dm-crypt.ko.zst
lib/modules/6.8.0-41-generic/kernel/drivers/nvme/host/nvme.ko.zst

Sens : l’initramfs contient cryptsetup ainsi que les modules dm-crypt et NVMe.
Décision : Si votre module critique est absent, corrigez la configuration ou les hooks d’initramfs-tools, puis reconstruisez.

Tâche 9 — Vérifier si les régénérations d’initramfs échouent (consulter les logs)

cr0x@server:~$ sudo journalctl -u systemd-update-utmp -b -0 | tail -n 5
Dec 31 09:12:24 server systemd[1]: Starting Update UTMP about System Boot/Shutdown...
Dec 31 09:12:24 server systemd[1]: Finished Update UTMP about System Boot/Shutdown.

cr0x@server:~$ sudo grep -R "update-initramfs" -n /var/log/apt/term.log | tail -n 6
2025-12-31 09:11:57 update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
2025-12-31 09:12:03 cryptsetup: WARNING: Resume target cryptswap uses a key file

Sens : initramfs a été généré pendant la mise à niveau ; des avertissements existent mais aucune erreur critique affichée ici.
Décision : Si vous voyez “failed” ou “cannot find module”, traitez cela comme une erreur bloquante : corrigez la cause sous-jacente et régénérez à nouveau.

Tâche 10 — Vérifier le statut DKMS pour les modules hors arbre

cr0x@server:~$ dkms status
nvidia/550.90.07, 6.8.0-41-generic, x86_64: installed
zfs/2.2.2, 6.8.0-41-generic, x86_64: built

Sens : NVIDIA est installé pour ce noyau ; ZFS est compilé (pas nécessairement installé).
Décision : Tout ce qui n’est pas “installed” pour votre noyau est une cause probable d’échec de chargement. Reconstruisez les modules DKMS et relancez l’initramfs.

Tâche 11 — Confirmer l’état de Secure Boot (et anticiper les échecs de signature)

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Sens : Secure Boot est activé ; les modules tiers non signés peuvent échouer à se charger.
Décision : Si le chargement des modules échoue avec des erreurs de signature, soit inscrivez un MOK et signez les modules, soit désactivez Secure Boot. Choisissez et appliquez une stratégie ; ne faites pas semblant d’ignorer le problème.

Tâche 12 — Détecter les échecs de chargement de modules lors du démarrage courant

cr0x@server:~$ sudo journalctl -k -b -0 | grep -E "module verification failed|Unknown symbol|taint|Lockdown" | tail -n 8
Dec 31 09:13:01 server kernel: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
Dec 31 09:13:01 server kernel: nvidia: module verification failed: signature and/or required key missing - tainting kernel

Sens : Le noyau est en mode lockdown ; le chargement de modules non signés peut être bloqué ou marquer le noyau selon la politique.
Décision : Si le module est bloqué (et pas seulement marqué), votre correction consiste à signer/inscrire des clés ou à désactiver Secure Boot. Reconstruire l’initramfs seul ne suffira pas.

Tâche 13 — Vérifier que vous n’avez pas changé accidentellement l’outil de génération d’initramfs

cr0x@server:~$ dpkg -l | awk '/initramfs-tools|dracut/ {print $1, $2, $3}'
ii initramfs-tools 0.142ubuntu25.2

Sens : Vous utilisez initramfs-tools. Bien : tenez-vous-en à un système sauf si vous avez une politique de migration.
Décision : Si dracut est installé et prend le relais, confirmez quel outil met à jour votre initrd et standardisez. Un mix d’outils est une panne lente programmée.

Tâche 14 — Valider les artefacts de démarrage et les liens symboliques dans /boot

cr0x@server:~$ ls -l /boot | grep -E 'vmlinuz|initrd|System.map' | head -n 10
lrwxrwxrwx 1 root root      27 Dec 31 09:12 initrd.img -> initrd.img-6.8.0-41-generic
-rw-r--r-- 1 root root 119458690 Dec 31 09:12 initrd.img-6.8.0-41-generic
lrwxrwxrwx 1 root root      24 Dec 31 09:12 vmlinuz -> vmlinuz-6.8.0-41-generic
-rw-r--r-- 1 root root  14901248 Dec 31 09:12 vmlinuz-6.8.0-41-generic

Sens : Les liens symboliques pointent vers le noyau le plus récent. C’est normal sur Ubuntu.
Décision : Si ceux-ci pointent vers un noyau sans modules ou avec un initramfs cassé, épinglez GRUB sur un noyau connu bon pendant que vous réparez le nouveau.

Reconstruire initramfs correctement (et prouver que cela fonctionne)

L’objectif n’est pas “lancer update-initramfs et espérer.” L’objectif est de créer un initramfs déterministe pour une version de noyau spécifique,
contenant les bons modules, avec des métadonnées de dépendances à jour, et avec les configurations du chargeur de démarrage mises à jour en conséquence.

Étape 0 — Choisir la version de noyau à réparer

Décidez explicitement de la version de noyau cible. Habituellement c’est le noyau le plus récent installé que vous souhaitez démarrer.
Pour le reste de cette section, supposons KVER=6.8.0-41-generic.

Tâche 15 — S’assurer que l’image du noyau et les headers sont installés

cr0x@server:~$ KVER=6.8.0-41-generic
cr0x@server:~$ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y linux-image-$KVER linux-headers-$KVER
Reading package lists... Done
Building dependency tree... Done
linux-image-6.8.0-41-generic is already the newest version (6.8.0-41.41).
linux-headers-6.8.0-41-generic is already the newest version (6.8.0-41.41).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Sens : Le noyau et les headers sont présents. DKMS a une chance de réussir.
Décision : Si les headers manquaient, installez-les avant de toucher à DKMS ou à l’initramfs. Sinon vous régénérez un initramfs qui ne pourra jamais contenir les modules requis.

Tâche 16 — Reconstruire les modules DKMS (si vous en utilisez)

cr0x@server:~$ sudo dkms autoinstall -k $KVER
Sign command: /usr/bin/kmodsign
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der
Building module:
Cleaning build area...
Building module(s)... done.
Installing /lib/modules/6.8.0-41-generic/updates/dkms/nvidia.ko.zst
depmod...

Sens : DKMS a reconstruit et installé un module pour ce noyau, puis a lancé depmod.
Décision : Si DKMS renvoie des erreurs, ne reconstruisez pas encore l’initramfs. Corrigez DKMS d’abord (headers, compilateur, signature Secure Boot), puis poursuivez.

Tâche 17 — Rafraîchir explicitement les métadonnées de dépendance des modules

cr0x@server:~$ sudo depmod -a $KVER

Sens : Les cartes de dépendances des modules sont régénérées pour le noyau cible.
Décision : Si depmod affiche des erreurs sur des fichiers manquants, votre arbre de modules est incohérent. Résolvez cela avant de générer un initramfs qui héritera de l’incohérence.

Tâche 18 — Reconstruire l’initramfs pour exactement un noyau (par défaut sensé)

cr0x@server:~$ sudo update-initramfs -u -k $KVER
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
W: Possible missing firmware /lib/firmware/i915/rlc.bin for module i915

Sens : L’initramfs a été reconstruit pour le noyau cible. Un avertissement de firmware peut ou non affecter votre chemin de démarrage.
Décision : S’il indique “failed” ou renvoie un code non nul, arrêtez-vous et corrigez. S’il se termine avec des avertissements, évaluez si ceux-ci impactent du matériel critique pour le démarrage.

Tâche 19 — Inspecter le contenu de l’initramfs pour confirmer la réparation

cr0x@server:~$ lsinitramfs /boot/initrd.img-$KVER | grep -E 'dm-crypt.ko|nvme.ko|mlx|bnx2|zfs.ko' | head -n 20
lib/modules/6.8.0-41-generic/kernel/drivers/md/dm-crypt.ko.zst
lib/modules/6.8.0-41-generic/kernel/drivers/nvme/host/nvme.ko.zst

Sens : Les modules stockage/crypto critiques sont présents.
Décision : Si le module nécessaire n’est pas dans l’initramfs, ajoutez-le (voir étapes suivantes) plutôt que de régénérer à répétition comme à la loterie.

Tâche 20 — Forcer l’inclusion d’un module (quand l’autodétection échoue)

initramfs-tools fait généralement le bon travail. Parfois il ne le fait pas — surtout sur des contrôleurs de stockage inhabituels, du stockage en couches ou quand les hooks cassent.
Vous pouvez forcer des modules via /etc/initramfs-tools/modules.

cr0x@server:~$ echo -e "nvme\ndm-crypt\n" | sudo tee -a /etc/initramfs-tools/modules
nvme
dm-crypt

cr0x@server:~$ sudo update-initramfs -u -k $KVER
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic

Sens : Vous avez épinglé des modules requis dans la génération d’initramfs.
Décision : Utilisez ceci uniquement pour des éléments critiques au démarrage. Ne surchargez pas l’initramfs avec tous les pilotes “au cas où”. C’est comme ça qu’on transforme le démarrage en roman policier.

Tâche 21 — S’assurer que la configuration du chargeur de démarrage connaît le noyau

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
done

Sens : GRUB a détecté le couple noyau/initrd.
Décision : Si GRUB ne liste pas le noyau/initrd attendu, corrigez le montage de /boot, les installations de paquets ou les problèmes d’espace disque avant de redémarrer.

Tâche 22 — Confirmer que /boot n’est pas plein (les échecs silencieux d’initramfs adorent ça)

cr0x@server:~$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  975M  912M   11M  99% /boot

Sens : /boot est à 99%. C’est la zone dangereuse ; la régénération peut échouer ou tronquer.
Décision : Supprimez les anciens noyaux en toute sécurité (apt-get autoremove --purge) et gardez au moins un noyau de secours. Puis reconstruisez l’initramfs.

Tâche 23 — Supprimer les anciens noyaux en toute sécurité (récupération d’espace sans s’auto-saboter)

cr0x@server:~$ sudo apt-get autoremove --purge
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  linux-image-6.8.0-40-generic* linux-modules-6.8.0-40-generic*
After this operation, 412 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 214233 files and directories currently installed.)
Removing linux-image-6.8.0-40-generic (6.8.0-40.40) ...
Processing triggers for initramfs-tools (0.142ubuntu25.2) ...
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
Processing triggers for grub-pc (2.12-1ubuntu7) ...

Sens : Ancien noyau supprimé ; initramfs régénéré ; GRUB mis à jour.
Décision : Vérifiez que vous avez toujours au moins un noyau plus ancien comme secours. Puis procédez au test par redémarrage.

Tâche 24 — Redémarrer pour tester (et garder une console ouverte)

cr0x@server:~$ sudo reboot

Sens : Vous testez le chemin de démarrage réparé.
Décision : Si c’est distant, utilisez votre console hors-bande (IPMI/iDRAC/console virtuelle). Les redémarrages sans console sont la façon dont on se retrouve à écrire des emails d’excuses.

Blague #2 (courte, pertinente) : Secure Boot est génial jusqu’à ce que vous soyez celui qui essaie de charger un module à 2h du matin et qu’il demande “les papiers”.

Trois micro-récits d’entreprise depuis le terrain

Micro-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait des flottes Ubuntu sur du bare metal avec disques root chiffrés. Ils avaient un cadence de correctifs propre : staging, test, déploiement.
Un vendredi, le déploiement est passé quand même — parce que le cluster pré-prod “semblait correct”.

Lundi matin, une partie de la production ne revenait pas après un redémarrage routinier. Les systèmes atterrissaient dans initramfs avec “cannot find /dev/mapper/cryptroot”.
L’équipe on-call soupçonnait la baie de disques. Le stockage a été alerté. Tout le monde a regardé les chiffres d’iostat comme s’ils lisaient les feuilles de thé.

La vraie panne était banale : l’initramfs généré pendant la mise à jour n’incluait pas un module de contrôleur de stockage particulier nécessaire pour voir les périphériques NVMe.
La mauvaise hypothèse était que “cryptsetup échoue implique crypto.” Mais la couche crypto était innocente ; elle attendait un disque qui n’était pas encore visible.

La correction a consisté à forcer l’inclusion du module de contrôleur manquant dans /etc/initramfs-tools/modules, régénérer pour le noyau cible, et déployer cela comme baseline de configuration.
Ensuite, ils ont ajouté un test de validation du chemin de démarrage : “l’initramfs voit-il le périphérique bloc racine ?” Ce seul contrôle aurait détecté le problème avant lundi.

Micro-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre équipe voulait des redémarrages plus rapides pour une application de trading à faible latence. Ils ont grappillé des millisecondes partout.
Quelqu’un a proposé un “initramfs minimal” : retirer les modules “inutiles”, désactiver la plupart des recouvrements d’autodétection, et ne garder que ce que le serveur utilisait actuellement.

Ça a fonctionné — jusqu’à la prochaine mise à jour du noyau. Une révision du noyau a changé le module qui fournissait une fonctionnalité de stockage particulière.
La génération d’initramfs “a réussi”, mais elle manquait désormais le nom de module correct pour le nouveau packaging du noyau.

Le symptôme fut brutal : les machines démarraient sur initramfs au redémarrage, et le rollback a été retardé parce que leur processus avait supprimé les noyaux plus anciens pour garder /boot propre.
Ils avaient optimisé la seule chose qu’il ne faut pas optimiser agressivement : la capacité de récupération.

Ils ont révoqué la politique d’initramfs minimal, conservé un noyau de secours supplémentaire, et introduit une règle de changement : si vous ajustez le contenu d’initramfs, vous fournissez aussi une validation qui inspecte l’initrd pour les modules requis par motif, pas par noms de fichiers fragiles.

Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise avait une politique rébarbative : chaque ticket de mise à niveau du noyau exigeait la capture de trois artefacts avant le redémarrage :
uname -r, la liste des noyaux installés, et la sortie des vérifications lsinitramfs pour les modules de stockage et de crypto.
Personne n’aimait ça. Ça ressemblait à de la paperasserie.

Puis une mise à jour a introduit une défaillance de rebuild DKMS pour un pilote réseau tiers sur un sous-ensemble d’hôtes.
La mise à niveau s’est terminée, mais le module n’était pas disponible pour le nouveau noyau. Sans lui, la NIC ne remontait pas après le redémarrage.

Comme la politique imposait la collecte du statut DKMS et du contenu d’initramfs, ils ont détecté l’échec en staging avant la production.
Ils ont figé la version du paquet impacté, reconstruit DKMS avec les bons headers, et planifié une fenêtre de maintenance avec un noyau de rollback vérifié encore installé.

L’événement n’est pas devenu un incident. Il est devenu un élément de rapport hebdomadaire.
Les pratiques ennuyeuses ne remportent pas d’applaudissements, mais elles sauvent vos week-ends.

Erreurs courantes : symptôme → cause racine → correction

1) Passage à l’invite initramfs avec “Gave up waiting for root filesystem device”

Symptôme : Le démarrage tombe sur l’invite initramfs ; UUID de la racine introuvable.
Cause racine : Module pilote de stockage absent dans l’initramfs, ou UUID erroné dans fstab/crypttab.
Correction : Vérifiez les UUID avec blkid. Inspectez l’initrd avec lsinitramfs. Forcez l’inclusion du module dans /etc/initramfs-tools/modules. Reconstruisez avec update-initramfs -u -k KVER.

2) Le réseau disparaît après le redémarrage (pilote NIC manquant)

Symptôme : L’hôte démarre mais pas d’interfaces au-delà de loopback ; ip link n’affiche rien d’utile.
Cause racine : Pilote NIC hors arbre (DKMS) qui n’a pas été construit pour le nouveau noyau ; l’initramfs peut aussi manquer de firmware.
Correction : Vérifiez dkms status. Installez les headers. Exécutez dkms autoinstall -k KVER. Confirmez que le module se charge avec modprobe et vérifiez les logs noyau, puis reconstruisez l’initramfs.

3) Pilote NVIDIA “fonctionnait hier, écran noir aujourd’hui”

Symptôme : L’interface graphique échoue, le gestionnaire d’affichage boucle, les logs noyau montrent des erreurs du module nvidia.
Cause racine : Mismatch de module DKMS ou application de la politique de signature Secure Boot.
Correction : Vérifiez Secure Boot via mokutil --sb-state. Reconstruisez DKMS. Si Secure Boot est activé, inscrivez/signez correctement ou désactivez-le. Puis reconstruisez l’initramfs et redémarrez.

4) “Unknown symbol” lors de l’insertion d’un module

Symptôme : L’insertion du module échoue ; dmesg affiche des symboles inconnus.
Cause racine : Module compilé contre des headers différents du noyau en cours (incompatibilité ABI).
Correction : Assurez-vous que linux-headers-KVER correspond. Reconstruisez DKMS pour ce noyau uniquement, exécutez depmod -a KVER, régénérez l’initramfs.

5) Reconstruction d’initramfs “réussie”, mais le démarrage échoue toujours

Symptôme : Vous avez lancé update-initramfs ; rien n’a changé ; échec au démarrage toujours présent.
Cause racine : Vous avez reconstruit la mauvaise version du noyau, ou GRUB démarre une entrée différente.
Correction : Confirmez uname -r pour le noyau que vous avez démarré avec succès, inspectez les liens dans /boot, exécutez update-grub et définissez le défaut GRUB sur le noyau connu bon pendant la réparation du nouveau.

6) “Pas assez d’espace sur /boot” entraîne un initrd partiellement écrit

Symptôme : initrd existe mais est inhabituellement petit ; les logs de régénération montrent des problèmes d’espace.
Cause racine : Partition /boot presque pleine ; anciens noyaux non nettoyés.
Correction : Supprimez les anciens noyaux via apt-get autoremove --purge (gardez un fallback). Reconstruisez l’initramfs et mettez à jour GRUB.

7) ZFS root n’importe pas au démarrage

Symptôme : Le démarrage tombe dans initramfs ; pool introuvable / import échoue.
Cause racine : Module ZFS absent de l’initramfs, build DKMS non installé, ou mismatch entre noyau et module ZFS.
Correction : Confirmez l’état DKMS de ZFS, assurez-vous que le module ZFS figure dans l’initrd (lsinitramfs), reconstruisez DKMS et l’initramfs pour le noyau cible.

Listes de contrôle / plan pas à pas

Checklist A — Si le système démarre encore (meilleur cas)

Confirmer le noyau en cours : uname -r.
Confirmer les noyaux installés et repérer les états de paquets cassés : dpkg -l 'linux-image-*'.
Vérifier l’espace /boot : df -h /boot. Si >90%, nettoyer d’abord.
Vérifier que le noyau cible a ses modules : ls /lib/modules/KVER.
Vérifier DKMS : dkms status. Corriger tout ce qui n’est pas “installed”.
Exécuter depmod -a KVER.
Reconstruire initramfs : update-initramfs -u -k KVER.
Vérifier la présence des modules dans l’initrd : lsinitramfs grep pour vos pilotes.
Mettre à jour GRUB : update-grub.
Redémarrer avec accès console et vérifier les logs après démarrage.

Checklist B — Si le système ne démarre pas (mode incident réel)

Utiliser “Options avancées” de GRUB pour démarrer un noyau plus ancien (si présent).
Si aucun ne démarre : utiliser un ISO live, monter les partitions root et boot, puis chroot.
Dans le chroot : s’assurer que /boot est monté et inscriptible.
Réinstaller l’image noyau + headers pour la version cible.
Corriger les échecs DKMS, en particulier pour les modules stockage/réseau et ZFS.
Reconstruire l’initramfs pour le noyau cible.
Exécuter update-grub et confirmer qu’il voit le noyau/initrd.
Redémarrer et valider.

Tâche 25 — Workflow de récupération chroot (quand il faut réparer depuis un ISO live)

cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot
cr0x@server:~$ sudo mount /dev/mapper/cryptroot /mnt
cr0x@server:~$ for d in /dev /proc /sys /run; do sudo mount --bind $d /mnt$d; done
cr0x@server:~$ sudo chroot /mnt /bin/bash

cr0x@server:/# update-initramfs -u -k 6.8.0-41-generic
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic

cr0x@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
done

Sens : Vous avez reconstruit les artefacts de démarrage dans le contexte de l’OS installé, pas de l’environnement live.
Décision : Si update-grub ne trouve pas votre noyau, /boot peut ne pas être monté correctement ou des paquets sont manquants. Corrigez cela avant de redémarrer.

FAQ

1) Dois-je utiliser `update-initramfs` ou `mkinitramfs` ?

Utilisez update-initramfs pour les opérations courantes. Il gère les chemins standard et fonctionne avec les triggers de packaging.
Employez mkinitramfs quand vous voulez générer un fichier spécifique manuellement pour des tests, mais n’en faites pas votre habitude.

2) J’ai reconstruit l’initramfs mais il démarre toujours l’ancien noyau. Pourquoi ?

Parce que GRUB démarre ce pour quoi il est configuré. Exécutez update-grub, vérifiez les liens dans /boot, et confirmez l’entrée par défaut du menu.
Confirmez aussi que vous n’avez pas reconstruit l’initramfs pour un noyau que vous ne sélectionnez pas.

3) Comment savoir quels modules doivent être dans l’initramfs ?

Vous avez besoin de tout ce qui est requis pour découvrir et monter la racine : contrôleur de stockage (NVMe/AHCI/HBA), RAID/LVM/dm-crypt, pilote de système de fichiers, et tout ce qui est nécessaire pour le chemin vers le périphérique racine.
Vous pouvez le prouver en inspectant l’initrd avec lsinitramfs et en cherchant ces modules.

4) Est-il sûr de forcer des modules dans `/etc/initramfs-tools/modules` ?

Oui, lorsque c’est fait délibérément pour des pilotes critiques au démarrage. Gardez la liste restreinte.
Si vous en faites une décharge générale, vous gonflerez l’initramfs et rendrez le débogage du démarrage plus difficile, pas plus simple.

5) Pourquoi Secure Boot a-t-il de l’importance si le module est dans l’initramfs ?

Être présent dans l’initramfs ne garantit pas que le module pourra être chargé. Les politiques Secure Boot peuvent refuser les modules non signés au démarrage.
Si vous voyez des messages de signature/lockdown dans les logs noyau, traitez la signature/l’inscription ou désactivez Secure Boot.

6) DKMS dit “built” mais pas “installed”. Quelle est la différence ?

“Built” signifie que la compilation a réussi. “Installed” signifie que le module a été copié dans l’arbre de modules du noyau (typiquement sous /lib/modules/KVER/updates) et que depmod a été exécuté.
Vous avez besoin de l’état “installed” pour qu’il se charge de façon fiable et soit inclus dans l’initramfs quand c’est pertinent.

7) Mon /boot est petit. Dois-je simplement l’agrandir ?

Si vous le pouvez, oui — les noyaux modernes et les images initramfs ne sont pas minces. Mais dans beaucoup d’environnements, redimensionner des partitions est une douleur de gestion du changement.
Opérationnellement, gardez un noyau de secours, purgez régulièrement les anciens, et alertez sur l’usage de /boot.

8) Puis-je reconstruire l’initramfs pour tous les noyaux à la fois ?

Vous pouvez : update-initramfs -u -k all. C’est utile après des changements larges (comme l’ajout d’un module requis).
Mais durant la réponse à un incident, ciblez d’abord un noyau pour pouvoir raisonner sur ce qui a changé.

9) L’invite initramfs apparaît et je veux déboguer en direct. Que faire ?

À l’invite initramfs, vérifiez quels périphériques bloc existent, confirmez que l’UUID racine est visible, et tentez de charger des modules avec modprobe.
Si le chargement du pilote manquant fait apparaître le périphérique racine, vous avez prouvé la cause racine : module manquant dans l’initramfs.

10) Réinstaller le paquet noyau corrige-t-il la plupart des problèmes ?

Souvent, oui — car cela restaure l’arbre de modules et déclenche la régénération de l’initramfs.
Mais si le vrai problème est DKMS + Secure Boot, réinstaller le noyau ne fait que vous donner une nouvelle étape susceptible d’échouer.

Prochaines étapes à réellement accomplir

Si vous êtes en plein incident : démarrez un noyau connu bon, vérifiez l’alignement noyau/initramfs/version des modules, réglez DKMS et la réalité Secure Boot, puis reconstruisez l’initramfs pour le noyau ciblé.
Prouvez la correction en inspectant le contenu de l’initramfs et en confirmant que GRUB voit le bon couple.

Ensuite, faites le travail peu glamoureux de suivi :

Gardez au moins un noyau de secours installé tant que le nouveau survit à des redémarrages réels.
Surveillez l’utilisation de /boot et nettoyez les anciens noyaux selon un planning, pas quand c’est à 99%.
En staging, validez le chemin de démarrage en vérifiant que l’initramfs contient vos modules critiques (stockage/crypto/ZFS/NIC selon le cas).
Si vous utilisez des modules DKMS, considérez “DKMS installé pour KVER” comme une étape critique de validation de release, pas un aimable bonus.
Choisissez une stratégie Secure Boot et documentez-la. “On s’en occupera plus tard” n’est pas une stratégie ; c’est un incident futur.

La plupart des cas “les mises à jour système ont cassé les modules” ne sont que des artefacts déphasés. Une fois que vous commencez à traiter l’initramfs comme un produit de build que vous pouvez inspecter et valider, les drames diminuent fortement.
Linux n’est pas fragile. Ce sont nos hypothèses qui le sont.