Ubuntu 24.04 : mises à jour ont cassé les modules noyau — reconstruire correctement l’initramfs (cas n°28)

Comment ce problème se manifeste (et pourquoi c’est déroutant)

« Les modules sont cassés » est un diagnostic paresseux, mais c’est généralement ce que la console vous dit.
Sur Ubuntu 24.04, les modes de défaillance se concentrent autour du démarrage précoce : le moment où le noyau tourne,
mais votre vrai système de fichiers racine n’est pas encore monté.

Schémas de symptômes courants

• Passage au shell initramfs (BusyBox) avec « ALERT! /dev/… does not exist ».
  Le noyau ne peut pas charger le pilote de stockage (NVMe, virtio, contrôleur RAID, dm-crypt, LVM, ZFS) depuis l’image initramfs.
• Démarre, mais le réseau est mort jusqu’à plus tard — ou pour toujours.
  Un module NIC ou un firmware manquant dans l’initramfs peut bloquer root sur le réseau ou iSCSI, ou casser les besoins réseau en phase précoce.
• Les modules NVIDIA / ZFS / WireGuard / fournisseurs ont arrêté de se charger.
  En général DKMS n’a pas compilé pour le nouveau noyau, ou Secure Boot refuse des modules non signés.
• « Unknown symbol » / « invalid module format » dans dmesg.
  C’est un décalage : module construit pour un autre noyau, ou vermagic incompatible.
• Les services systemd échouent après le démarrage parce que des modules « qui existaient avant » n’y sont plus.
  Si le système démarre depuis un noyau de secours mais que vos paquets de modules suivent « le dernier », le décalage persiste et apparaît comme erreurs à l’exécution.

La confusion vient du timing. Une fois dans l’environnement initramfs, vous avez une image de système de fichiers minimale
avec un ensemble restreint de binaires et de modules noyau. Si cette image est erronée, le noyau peut être sain et pourtant ne pas atteindre l’espace utilisateur.
La correction consiste typiquement à régénérer l’image pour que les bons modules et la bonne configuration soient inclus pour le noyau que vous voulez démarrer.

Blague n°1 : Un initramfs, c’est comme un parachute — la plupart du temps vous oubliez qu’il existe, et le jour où il compte vous voulez qu’il soit correctement empaqueté.

Faits intéressants et contexte (pour que le comportement ait du sens)

Quelques faits concrets vous aident à arrêter de deviner et à commencer à diagnostiquer. Ce ne sont pas des trivia ; ils expliquent pourquoi « ça marchait hier » est plausible.

1. initramfs a remplacé initrd comme mécanisme de démarrage précoce mainstream sous Linux.
   Le changement (il y a des années) compte parce qu’initramfs est une archive cpio décompressée dans un système de fichiers en RAM ; c’est flexible et scriptable.
2. Les outils par défaut d’Ubuntu sont toujours initramfs-tools.
   Certains écosystèmes préfèrent dracut, mais sur Ubuntu 24.04 vous dépannerez généralement avec update-initramfs et les hooks dans /etc/initramfs-tools.
3. La compatibilité des modules noyau est liée à la « vermagic ».
   Si la vermagic du module ne correspond pas au noyau en cours, vous obtenez « invalid module format » et il ne se charge pas.
4. DKMS est un système de build, pas de la colle magique.
   Il compile les modules hors-arbre contre les en-têtes du noyau installé. Si les en-têtes ne sont pas installés, ou si la compilation échoue, vous n’aurez pas de module pour le nouveau noyau.
5. Secure Boot peut transformer silencieusement le chargement de module en une décision de politique.
   Si Secure Boot est activé, des modules non signés peuvent être refusés. Vous pouvez reconstruire parfaitement l’initramfs et toujours échouer si les signatures ne correspondent pas à la politique.
6. Certaines piles de stockage sont nécessaires avant que la racine soit montée.
   LVM, dm-crypt, MD RAID, NVMe, virtio-blk/scsi et ZFS peuvent être requis dans l’initramfs. S’ils sont absents, vous n’atteignez pas le vrai système de fichiers.
7. Les mises à jour du microcode peuvent modifier le comportement de démarrage précoce.
   Le microcode CPU peut être inclus dans l’initramfs ; sa mise à jour peut modifier les timings et révéler des races ou dépendances firmware.
8. Ubuntu garde plusieurs noyaux installés par défaut.
   Ce filet de sécurité explique pourquoi vous pouvez souvent démarrer un noyau plus ancien et réparer l’initramfs du plus récent depuis un environnement stable.
9. Les formats compressés d’initramfs varient (gzip, zstd).
   Si vous copiez des images entre systèmes ou manipulez la compression, vous pouvez créer des problèmes « unpacking initramfs failed » qui ressemblent à des problèmes de module.

Une idée paraphrasée de John Allspaw (opérations/fiabilité) : La fiabilité vient du fait d’apprendre comment les systèmes tombent en panne, pas de prétendre qu’ils ne le feront pas.
C’est l’état d’esprit ici : arrêtez de traiter initramfs comme une boîte noire.

Feuille de route diagnostic rapide (premier/deuxième/troisième)

Quand un démarrage casse, votre objectif n’est pas « tout réparer ». Votre objectif est de trouver le goulot d’étranglement dans la chaîne de démarrage.
Pensez en couches : firmware → chargeur de démarrage → noyau → initramfs → vraie racine → services.
La casse des modules se situe généralement dans les couches 3–5.

Premier : déterminer quel noyau vous êtes réellement en train de lancer

• Si vous pouvez atteindre un shell, vérifiez uname -r.
• Si vous ne pouvez pas, vérifiez GRUB et démarrez un noyau plus ancien pour obtenir un environnement fonctionnel.
• Décision : si un noyau plus ancien démarre, vous avez une voie de réparation sans média de secours.

Deuxième : décider si c’est « initramfs ne peut pas monter la racine » ou « modules manquants après le démarrage »

• Si vous arrivez dans BusyBox initramfs avec le périphérique racine manquant, c’est un problème de démarrage précoce : contenu/config de l’initramfs ou module/firmware de stockage manquant.
• Si le système démarre mais que des modules spécifiques échouent, c’est généralement DKMS, politique de signature de module, ou en-têtes de noyau incorrects.
• Décision : les échecs de démarrage précoce nécessitent de reconstruire l’initramfs pour le noyau cible ; les échecs à l’exécution peuvent nécessiter de reconstruire les modules DKMS puis de régénérer l’initramfs si nécessaire.

Troisième : vérifier mismatch de module vs absence de module

• « Invalid module format » → mismatch (mauvaise compilation, mauvais noyau, mauvais en-têtes).
• « Module not found » → absence (non installé, pas construit, non inclus dans initramfs).
• Décision : le mismatch vous oriente vers la reconstruction DKMS/en-têtes ; l’absence vous oriente vers l’installation de paquets et les hooks d’initramfs.

Quatrième : vérifier l’état de Secure Boot avant de perdre du temps

• Secure Boot activé + modules tiers = les signatures comptent.
• Décision : soit inscrire une clé/signerez les modules, soit désactiver Secure Boot pour la politique opérationnelle de cet hôte.

La route la plus rapide est presque toujours : démarrer un noyau connu bon, réparer paquets/en-têtes/DKMS, régénérer l’initramfs pour le noyau que vous voulez lancer, mettre à jour GRUB, redémarrer une fois.
Ne faites pas des « redémarrer et espérer » répétés. Ce n’est pas de l’ingénierie ; c’est de la superstition avec des étapes en plus.

Un modèle mental pratique : noyau, modules, initramfs, DKMS

Voici le modèle qui vous évite de faire des suppositions coûteuses.

Noyau et modules

L’image du noyau (vmlinuz) est l’exécutable central. La plupart des supports matériels et fonctionnalités vivent dans des modules chargables sous
/lib/modules/<kernel-version>/. Ces modules sont étroitement couplés à la compilation du noyau.
Ce couplage est appliqué par la vermagic et les versions de symboles.

initramfs n’est pas votre système de fichiers racine

initramfs est une image de système de fichiers de démarrage précoce. Le noyau la décompresse en RAM, exécute /init,
et ce script monte le vrai système de fichiers racine (votre disque, RAID, LUKS, dataset ZFS, etc.).
Si vous ne pouvez pas charger le module qui parle à votre stockage, vous ne pouvez pas monter la vraie racine, et vous vous arrêtez là.

Pourquoi les mises à jour déclenchent cela

Une mise à jour du noyau installe typiquement :
linux-image-…, linux-modules-…, et peut-être linux-modules-extra-….
Elle déclenche aussi les hooks de régénération d’initramfs.
Si l’une de ces étapes échoue (disque plein, erreur de hook, échec DKMS, en-têtes manquants, mise à jour interrompue),
vous pouvez vous retrouver avec un noyau présent sur le disque mais un initramfs qui ne contient pas ce dont le démarrage a besoin.

DKMS est un suspect habituel

DKMS construit des modules comme ZFS, NVIDIA, VirtualBox, certains pilotes NIC/RAID fournisseurs, et divers modules spécialisés.
Après une mise à jour du noyau, DKMS devrait compiler les modules pour le nouveau noyau automatiquement.
Mais « devrait » est le mot le plus dangereux en opérations. Si la compilation échoue, vous pouvez toujours redémarrer dans le nouveau noyau et découvrir que rien ne se charge.

Pourquoi reconstruire l’initramfs fonctionne (lorsque c’est fait correctement)

Une reconstruction correcte fait trois choses :

• Assure que les métadonnées de dépendances des modules sont correctes (la sortie de depmod correspond aux modules du noyau).
• Assure que les modules et firmwares requis sont inclus dans l’image initramfs pour ce noyau.
• Assure que les entrées du chargeur de démarrage pointent vers une paire noyau+initramfs correspondante.

Si vous reconstruisez l’initramfs pour le mauvais noyau, ou si vous reconstruisez alors que DKMS est toujours cassé, vous produirez un bel artefact parfaitement erroné.
C’est comme ça que les gens se retrouvent dans des boucles de redémarrage.

Tâches pratiques : commandes, signification des sorties, décisions

Cette section est le cœur. Commandes réelles, ce que vous devriez voir, et quelle décision prendre selon chaque sortie.
Utilisez-la comme runbook de diagnostic. Exécutez les commandes en root quand c’est nécessaire.

Tâche 1 : Identifier le noyau en cours (et si vous êtes sur un fallback)

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

Signification : C’est le noyau en cours d’exécution. Si vous dépannez un échec de démarrage d’un noyau plus récent,
vous avez peut-être démarré un plus ancien via GRUB.
Décision : Conservez cette valeur. Vous reconstruirez l’initramfs pour le noyau que vous comptez démarrer, pas nécessairement celui sur lequel vous êtes.

Tâche 2 : Lister les noyaux installés (pour connaître vos cibles)

cr0x@server:~$ dpkg -l | awk '/^ii  linux-image-[0-9]/{print $2}' | sort -V
linux-image-6.8.0-49-generic
linux-image-6.8.0-50-generic

Signification : Ces images noyau sont installées. Votre démarrage cassé implique probablement la plus récente.
Décision : Choisissez la version du noyau que vous voulez corriger (généralement la dernière installée).

Tâche 3 : Confirmer que les images initramfs existent pour le noyau cible

cr0x@server:~$ ls -lh /boot/initrd.img-6.8.0-50-generic /boot/vmlinuz-6.8.0-50-generic
-rw-r--r-- 1 root root  98M Dec 30 10:12 /boot/initrd.img-6.8.0-50-generic
-rw------- 1 root root  14M Dec 30 10:11 /boot/vmlinuz-6.8.0-50-generic

Signification : Les artefacts noyau et initramfs existent. Si initrd est manquant ou minuscule, vous avez une défaillance de packaging/hook.
Décision : Si manquant ou suspect, reconstruisez l’initramfs et vérifiez les logs des hooks.

Tâche 4 : Vérifier si /boot est plein (le tueur silencieux classique)

cr0x@server:~$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       974M  942M     0 100% /boot

Signification : Pas d’espace libre. Les mises à jour du noyau peuvent « s’installer » mais échouer à écrire l’initramfs, ou écrire des images tronquées.
Décision : Libérez de l’espace avant de reconstruire : supprimez des noyaux anciens ou agrandissez /boot. Reconstruisez après disponibilité d’espace.

Tâche 5 : Trouver les dernières erreurs de génération d’initramfs dans les logs

cr0x@server:~$ journalctl -b -1 -u systemd-update-done.service --no-pager
Dec 30 09:58:12 server systemd[1]: Finished Wait for System Update to Complete.

cr0x@server:~$ grep -R "update-initramfs" -n /var/log/apt/term.log | tail -n 20
Log started: 2025-12-30  09:54:18
Setting up linux-image-6.8.0-50-generic (6.8.0-50.51) ...
update-initramfs: Generating /boot/initrd.img-6.8.0-50-generic
W: Possible missing firmware /lib/firmware/i915/skl_dmc_ver1_27.bin for module i915

Signification : Les logs APT montrent si initramfs a été généré et si des avertissements de firmware sont apparus.
Décision : Les avertissements ne sont pas toujours fatals, mais si vous voyez des erreurs (I/O errors, pas d’espace, échec de hook), corrigez-les d’abord.

Tâche 6 : Vérifier que le répertoire des modules existe pour le noyau

cr0x@server:~$ ls -ld /lib/modules/6.8.0-50-generic
drwxr-xr-x 6 root root 4096 Dec 30 10:10 /lib/modules/6.8.0-50-generic

Signification : Les modules pour ce noyau sont installés.
Décision : Si manquant, réinstallez les paquets linux-modules-* pour ce noyau.

Tâche 7 : Vérifier depmod pour des erreurs (métadonnées de dépendance)

cr0x@server:~$ sudo depmod -a 6.8.0-50-generic

Signification : Pas de sortie est bon signe. Des erreurs ici signifient que votre arbre de modules est incohérent.
Décision : Si depmod se plaint de fichiers manquants, réinstallez les paquets de modules du noyau avant de reconstruire l’initramfs.

Tâche 8 : Confirmer que le module dont vous avez besoin existe (exemple : pilote de stockage)

cr0x@server:~$ modinfo -k 6.8.0-50-generic nvme | sed -n '1,6p'
filename:       /lib/modules/6.8.0-50-generic/kernel/drivers/nvme/host/nvme.ko.zst
license:        GPL
description:    NVM Express block device driver
author:         Matthew Wilcox <willy@linux.intel.com>
alias:          pci:v0000106Bd00002001sv*sd*bc*sc*i*

Signification : Le module existe sur le disque pour ce noyau.
Décision : Si modinfo échoue, installez le paquet de modules manquant (souvent linux-modules-extra) ou corrigez la sélection du noyau.

Tâche 9 : Vérifier l’état de DKMS (modules hors-arbre)

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

Signification : Les modules DKMS peuvent ne pas être installés pour le nouveau noyau.
Décision : Corrigez les échecs DKMS avant de reconstruire l’initramfs si le démarrage précoce dépend de ces modules (par ex. ZFS root).

Tâche 10 : Confirmer l’état de Secure Boot (politique de signature des modules)

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

Signification : Secure Boot est activé. Les modules tiers non signés peuvent ne pas se charger.
Décision : Si votre module cassé est tiers (NVIDIA, modules fournisseur, ZFS DKMS dans certains setups), prévoyez de signer/enregistrer des clés ou de désactiver Secure Boot (décision de politique).

Tâche 11 : Inspecter le contenu de l’initramfs pour un module spécifique

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.8.0-50-generic | grep -E '/nvme\.ko|/zfs\.ko|/virtio_blk\.ko' | head
usr/lib/modules/6.8.0-50-generic/kernel/drivers/nvme/host/nvme.ko.zst

Signification : L’initramfs inclut le module. S’il ne l’inclut pas, le démarrage précoce peut ne pas voir le périphérique.
Décision : Si les modules requis sont absents, forcez leur inclusion (configuration initramfs-tools) et régénérez.

Tâche 12 : Valider le mapping du périphérique racine (UUID vs noms de périphériques)

cr0x@server:~$ findmnt -no SOURCE /
/dev/mapper/vg0-root

cr0x@server:~$ cat /etc/fstab | sed -n '1,8p'
# /etc/fstab: static file system information.
UUID=8b7f5f4a-2f15-4e5a-a6b3-7c9e0c03c7b0 / ext4 defaults 0 1

Signification : Vous utilisez des UUID (bien). Si /etc/fstab utilise des noms de périphériques bruts (comme /dev/sda3),
le démarrage peut casser lorsque l’énumération change.
Décision : Utilisez UUIDs/LABELs et assurez-vous que l’initramfs contient les modules nécessaires pour trouver ces périphériques.

Tâche 13 : Reconstruire l’initramfs pour un noyau spécifique (la correction principale)

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

Signification : L’image a été régénérée. Les avertissements concernant le firmware peuvent être acceptables, selon le matériel et si le pilote est nécessaire au démarrage.
Décision : Si vous voyez des erreurs (pas des avertissements), arrêtez et corrigez-les. Si vous dépendez de ce firmware (console GPU sur certains systèmes), installez les paquets de firmware.

Tâche 14 : Régénérer toutes les images initramfs (utile après des corrections systémiques)

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

Signification : Tous les noyaux installés ont obtenu des images initramfs rafraîchies.
Décision : Utilisez ceci après avoir réparé DKMS ou le firmware afin que le noyau « courant » et le noyau de secours soient cohérents.

Tâche 15 : Mettre à jour les entrées GRUB (éviter de démarrer des artefacts non appariés)

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

Signification : GRUB voit des paires noyau et initrd qui correspondent.
Décision : Si GRUB n’affiche pas votre initrd, vous démarrez sans la chose que vous essayez de corriger. Revenez à l’intégrité et au nommage de /boot.

Tâche 16 : Vérifier les erreurs de chargement de modules dans le journal du noyau

cr0x@server:~$ dmesg -T | egrep -i 'invalid module format|Unknown symbol|module verification failed|failed to load' | tail -n 20
[Mon Dec 30 10:22:41 2025] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[Mon Dec 30 10:22:41 2025] nvidia: loading out-of-tree module taints kernel.

Signification : Cela indique une politique de signature et un ensuquage. Si Secure Boot est en mode enforcement, il pourrait refuser au lieu d’ensuquer.
Décision : Décidez si vous signerez les modules (préférable pour des flottes avec Secure Boot) ou si vous changerez la politique Secure Boot pour cette classe d’hôtes.

Reconstruire l’initramfs correctement (par scénario)

Scénario A : Le système démarre un noyau plus ancien, mais le plus récent échoue

C’est le cas le plus favorable. Vous avez un userland stable pour réparer depuis.
Ne « corrigez » pas en supprimant le nouveau noyau sauf si vous êtes vraiment coincé ; vous ne ferez que reporter le problème à la prochaine fenêtre de mise à jour.

1. Libérez de l’espace dans /boot si nécessaire. C’est l’étape zéro, pas l’étape sept.
2. Assurez-vous que les en-têtes pour le noyau cible sont installés (surtout si DKMS est impliqué).
3. Réparez les modules DKMS pour le noyau cible.
4. Régénérez l’initramfs pour ce noyau.
5. Mettez à jour GRUB et redémarrez une fois.

cr0x@server:~$ sudo apt-get update
Hit:1 Ubuntu noble InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y linux-headers-6.8.0-50-generic
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  linux-headers-6.8.0-50-generic
Setting up linux-headers-6.8.0-50-generic (6.8.0-50.51) ...

Signification : Les en-têtes sont présents. Les builds DKMS ont une chance de réussir.
Décision : Si les en-têtes manquaient, attendez-vous à des échecs DKMS avant. Relancez la construction DKMS maintenant.

cr0x@server:~$ sudo dkms autoinstall -k 6.8.0-50-generic
Sign command: /usr/bin/kmodsign
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der
Installing module zfs/2.2.2 for kernel 6.8.0-50-generic

Signification : DKMS a construit/ installé les modules pour le noyau cible. Si le processus de signature est configuré, il les signe.
Décision : Si DKMS échoue, lisez le log de build et corrigez-le d’abord. Ne reconstruisez pas l’initramfs tant que DKMS est cassé si le démarrage en dépend.

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

cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-50-generic
Found initrd image: /boot/initrd.img-6.8.0-50-generic
done

Scénario B : Tombé dans BusyBox initramfs, impossible de monter la racine

Si vous êtes déjà dans l’invite initramfs, vous êtes dans un environnement restreint. L’objectif est de collecter suffisamment d’informations pour décider :
« module/firmware manquant » vs « mauvais paramètre root= » vs « corruption du système de fichiers ».

Dans l’invite initramfs, vérifiez ce que le noyau voit et ce qu’il peut charger.

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.0-50-generic root=UUID=8b7f5f4a-2f15-4e5a-a6b3-7c9e0c03c7b0 ro quiet splash

Signification : La racine est spécifiée par UUID. Bien. Vérifiez maintenant que l’UUID apparaît dans les périphériques blocs.
Décision : Si la racine est spécifiée comme /dev/sdX et que la lettre a changé, corrigez GRUB/cmdline et fstab pour utiliser UUID.

cr0x@server:~$ ls /dev/disk/by-uuid | head
2c1f9b55-0a69-4b59-9c4d-2b0a7dc3c77a

Signification : Si votre UUID racine est absent ici, le noyau ne voit pas le disque ou la table de partition.
Décision : Cela pointe vers un pilote de stockage manquant, un firmware manquant, ou un problème matériel. Reconstruisez l’initramfs depuis un noyau fonctionnel ou un environnement de secours.

cr0x@server:~$ modprobe nvme
modprobe: module nvme not found in modules.dep

Signification : L’initramfs ne contient pas le module nvme ni les métadonnées de dépendance.
Décision : Vous devez démarrer un autre noyau (ou un média de secours), vous assurer que linux-modules est installé, et régénérer l’initramfs avec nvme inclus.

Dans ce scénario, ne tentez pas de réparations ingénieuses à l’intérieur de l’initramfs cassé à moins de savoir exactement ce que vous faites.
Il est généralement plus rapide de redémarrer sur un noyau plus ancien, ou d’utiliser le mode récupération, corriger, reconstruire, et redémarrer.

Scénario C : ZFS root ou « racine sur stockage exotique » échoue après mise à jour

ZFS est un cas fréquent car il dépend souvent de modules hors-arbre (via DKMS) et est requis avant le montage de la racine.
Si les modules ZFS ne sont pas présents dans l’initramfs, le démarrage s’arrête tôt.

Votre ordre de priorité :
État DKMS → présence du module → régénération initramfs → vérifier que l’initramfs contient ZFS → redémarrer.

cr0x@server:~$ dkms status | grep -i zfs
zfs/2.2.2, 6.8.0-50-generic, x86_64: installed

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.8.0-50-generic | grep -E '/zfs\.ko|/zcommon\.ko' | head
usr/lib/modules/6.8.0-50-generic/updates/dkms/zfs.ko
usr/lib/modules/6.8.0-50-generic/updates/dkms/zcommon.ko

Signification : Les modules ZFS sont embarqués. S’ils ne le sont pas, le démarrage échouera avant l’importation des pools.
Décision : Si absents, assurez-vous que les hooks initramfs-tools pour ZFS sont présents (état du paquet) et relancez update-initramfs.

Scénario D : NVIDIA ou autres modules tiers échouent à l’exécution

Pour les modules à l’exécution, l’initramfs peut encore être pertinent (si vous voulez KMS précoce, des invites chiffrées sur la console GPU, etc.),
mais la plupart du temps il s’agit d’un problème DKMS/signature.

cr0x@server:~$ dkms status | grep -i nvidia
nvidia/550.90.07, 6.8.0-50-generic, x86_64: installed

cr0x@server:~$ modprobe nvidia
modprobe: ERROR: could not insert 'nvidia': Key was rejected by service

Signification : Rejet par la politique de signature (courant avec Secure Boot). Le module existe mais n’est pas approuvé.
Décision : Soit signez le module avec une clé enregistrée, inscrivez MOK, soit désactivez Secure Boot pour cette machine.

Blague n°2 : Secure Boot est génial jusqu’à ce qu’il décide que votre module soigneusement construit est « non autorisé », comme un videur devant la boîte de nuit du noyau.

Trois mini-récits en entreprise depuis le terrain

1) L’incident causé par une mauvaise hypothèse : « l’initramfs se reconstruit toujours lors de l’upgrade »

Une entreprise de taille moyenne gérait une flotte de serveurs Ubuntu hébergeant des runners CI internes et des caches d’artefacts.
Rien d’exotique — jusqu’à ce que vous remarquiez que leur « image standard » avait une petite partition /boot héritée d’une mise en page de 2018.
Ça a fonctionné pendant des années parce que les noyaux étaient rares et que personne ne surveillait l’utilisation de /boot.

Un mardi, une mise à jour non surveillée a récupéré un nouveau noyau. L’installation du paquet a réussi, mais /boot est arrivé à 100% pendant la génération de l’initramfs.
Le processus d’installation a logué des erreurs, mais le pipeline de mise à jour ne l’a pas traité comme fatal. Les serveurs sont restés sur l’ancien noyau.
Tout semblait vert.

La fenêtre de redémarrage suivante est arrivée. Les machines ont redémarré vers un noyau dont l’initramfs était manquant ou tronqué.
La moitié de la flotte est tombée dans BusyBox initramfs avec des périphériques racine manquants. L’autre moitié a démarré seulement parce qu’elles ont accidentellement sélectionné l’ancien noyau dans les options GRUB par défaut.
Le chef d’incident a supposé « ce n’est pas l’initramfs ; l’upgrade l’aurait reconstruit ».

La correction a été peu glamour : agrandir /boot sur l’image de base, imposer une vérification que la génération d’initramfs a réussi, et garder au moins un noyau ancien comme fallback.
Ils ont aussi modifié leur automatisation de redémarrage : elle vérifie désormais que /boot/vmlinuz et /boot/initrd existent pour l’entrée par défaut avant de redémarrer.

La mauvaise hypothèse n’était pas ignorance technique. C’était de la paresse opérationnelle : confondre « les scripts de paquet se sont exécutés » avec « l’artefact produit est valide ».
En ops, vous ne marquez pas de points pour avoir eu l’intention de générer un initramfs.

2) L’optimisation qui s’est retournée contre eux : « réduire l’initramfs pour accélérer le boot »

Une autre organisation exécutait des workloads sensibles à la latence et avait pour habitude de tailler quelques millisecondes partout où c’était possible.
Quelqu’un a remarqué la taille de l’initramfs et décidé que c’était du « bloat ». Ils ont édité les configs initramfs-tools pour être agressifs :
moins de modules, moins de hooks, et la croyance que udev découvrirait tout plus tard.

Ça a marché sur leur matériel principal pendant un certain temps. Le temps de boot s’est amélioré légèrement. Le changement a été déployé sur la flotte sans grande fanfare.
Le piège, bien sûr, est que les flottes ne sont jamais uniformes, et la réalité adore les cas limites.

Un nouveau lot de serveurs est arrivé avec un contrôleur de stockage différent et nécessitait un module qui n’était pas intégré au noyau.
L’initramfs allégé ne l’incluait pas. Les machines n’ont pas monté la racine et n’ont jamais atteint la gestion de configuration.
Elles ne pouvaient pas s’auto-réparer, pas récupérer des correctifs, et pas même téléphoner à la maison correctement.

Le postmortem a été douloureux parce que l’« optimisation » était correcte sur l’ancien matériel et fausse sur le nouveau.
La leçon n’était pas « ne jamais optimiser ». C’était : si vous optimisez des artefacts de démarrage précoce, vous devez avoir des profils adaptés au matériel ou inclure des pilotes de stockage larges par défaut.
La correction du boot prime sur la vitesse du boot. À chaque fois.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « toujours garder une voie de démarrage connue bonne »

Une organisation financière exécutait des hôtes Ubuntu avec racine chiffrée et des interventions sur site coûteuses.
Leur règle était à l’ancienne : ne jamais supprimer le noyau précédent tant que le nouveau n’a pas démarré avec succès au moins une fois,
et tester l’accès console trimestriellement. Ennuyeux. Prévisible. Très peu sexy.

Lors d’un cycle de mise à jour, un module DKMS a échoué à se construire pour le noyau le plus récent à cause d’une incompatibilité d’outillage.
L’initramfs pour le nouveau noyau a été généré, mais il ne contenait pas le module requis pour leur pile racine.
Le redémarrage suivant aurait été un brique.

Mais ils n’ont pas redémarré à l’aveugle. Leur processus de changement incluait une vérification pré-redémarrage :
vérifier l’état DKMS pour le noyau cible, vérifier que l’initramfs contient les modules requis, vérifier l’espace /boot,
et vérifier que GRUB pointe vers une paire noyau+initrd correspondante. La pré-vérification a échoué, donc le redémarrage a été reporté.

Ils ont patché le problème de build DKMS, régénéré l’initramfs, puis redémarré dans une fenêtre contrôlée.
Aucun incident. Pas d’héros. Pas de war room. Le meilleur incident est celui qui n’a jamais lieu.

Erreurs courantes : symptôme → cause racine → correctif

1) Passage au shell initramfs : « ALERT! UUID=… does not exist »

Cause racine : Pilote de stockage manquant dans l’initramfs, ou initramfs construit pour un noyau différent de celui démarré.
Parfois c’est un firmware manquant pour le périphérique de stockage/NIC.

Correctif : Démarrez un noyau connu bon, assurez-vous que les paquets linux-modules corrects sont installés, puis update-initramfs -u -k <target> et update-grub.
Vérifiez avec lsinitramfs que le module requis est présent.

2) « Invalid module format » lors du chargement d’un module

Cause racine : Le module a été construit pour une autre version du noyau/options de build (mismatch vermagic) ou artefacts DKMS obsolètes.

Correctif : Installez les en-têtes correspondants, reconstruisez le module DKMS pour le noyau cible, lancez depmod -a <kernel>, puis reconstruisez l’initramfs.

3) « Key was rejected by service » pour les modules NVIDIA/ZFS/fournisseur

Cause racine : Secure Boot applique la politique de signature des modules ; le module est non signé ou signé avec une clé non approuvée.

Correctif : Choisissez : inscrire une Machine Owner Key et signer les modules (convivial pour les flottes), ou désactiver Secure Boot (plus simple mais dépendant de la politique).
Régénérez l’initramfs si le module est critique au démarrage.

4) Le noyau s’installe mais l’initrd est manquant ou minuscule

Cause racine : /boot plein, mise à niveau interrompue, erreurs de système de fichiers, ou scripts hook qui échouent.

Correctif : Libérez de l’espace, exécutez des vérifications filesystem si nécessaire, relancez update-initramfs. Confirmez la taille et les timestamps de l’artefact.

5) Le boot ne fonctionne qu’avec un noyau plus ancien après mise à jour

Cause racine : DKMS non construit pour le nouveau noyau, ou paquet linux-modules-extra manquant pour le nouveau noyau.

Correctif : Réparez l’état DKMS, installez les paquets manquants, régénérez l’initramfs, et mettez à jour GRUB.

6) « unpacking initramfs failed » ou panic noyau précoce

Cause racine : Image initramfs corrompue (écriture tronquée à cause du disque plein, stockage défaillant, ou modifications manuelles), ou outillage de compression incompatible.

Correctif : Recréez l’initramfs depuis zéro avec update-initramfs -c -k <kernel>, et vérifiez la santé du système de fichiers /boot et l’espace libre.

7) La racine est montée, mais des périphériques disparaissent ensuite

Cause racine : Mismatch de paquets de modules ou paquet firmware manquant ; l’initramfs n’a pas été régénéré après des changements de firmware/module.

Correctif : Installez les paquets firmware nécessaires, exécutez update-initramfs -u -k all, redémarrez.

Checklists / plan étape par étape

Checklist 1 : Règles « ne pas empirer »

• Ne supprimez pas le seul noyau fonctionnel. Gardez au moins une entrée connue bonne jusqu’à ce que le nouveau démarre.
• Ne reconstruisez pas l’initramfs si /boot est plein.
• Ne supposez pas que DKMS a réussi parce que APT est sorti 0. Vérifiez l’état DKMS.
• Ne changez pas la politique Secure Boot en plein incident sans documenter la décision et le chemin de rollback.
• Ne déboguez pas des problèmes de module sans confirmer quel noyau vous démarrez.

Checklist 2 : Récupération étape par étape quand vous pouvez démarrer un noyau plus ancien

1. Confirmez le noyau actuel:

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

   Décision : Si vous êtes déjà sur le noyau le plus récent, votre problème est probablement d’exécution/DKMS/signature, pas un initramfs pour un noyau différent.

2. Identifiez le noyau cible que vous voulez démarrer:

   cr0x@server:~$ dpkg -l | awk '/^ii  linux-image-[0-9]/{print $2}' | sort -V | tail -n 2
   linux-image-6.8.0-49-generic
   linux-image-6.8.0-50-generic
   

   Décision : La cible est généralement la dernière installée.

3. Vérifiez l’espace /boot:

   cr0x@server:~$ df -h /boot
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/sda2       974M  620M  305M  68% /boot
   

   Décision : Si >90% utilisé, nettoyez les anciens noyaux avant de régénérer.

4. Assurez-vous que l’arbre des modules existe:

   cr0x@server:~$ test -d /lib/modules/6.8.0-50-generic && echo ok
   ok
   

   Décision : Si pas ok, réinstallez les paquets de modules du noyau.

5. Assurez-vous que les en-têtes existent si DKMS est en jeu:

   cr0x@server:~$ dpkg -l | awk '/^ii  linux-headers-6.8.0-50-generic/{print $2, $3}'
   linux-headers-6.8.0-50-generic 6.8.0-50.51
   

   Décision : Si manquants, installez les en-têtes et relancez DKMS.

6. Réparez DKMS et vérifiez l’état:

   cr0x@server:~$ sudo dkms autoinstall -k 6.8.0-50-generic
   Installing module zfs/2.2.2 for kernel 6.8.0-50-generic
   

   Décision : Si des échecs apparaissent, ouvrez le log de build DKMS et corrigez la compilation/signature avant de continuer.

7. Régénérez l’initramfs pour le noyau cible:

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

   Décision : Si vous voyez des erreurs, ne redémarrez pas. Corrigez l’erreur. Les avertissements demandent du jugement.

8. Vérifiez que les modules requis sont dans l’initramfs:

   cr0x@server:~$ lsinitramfs /boot/initrd.img-6.8.0-50-generic | grep -E '/(nvme|virtio_blk|dm_crypt|zfs)\.ko' | head
   usr/lib/modules/6.8.0-50-generic/kernel/drivers/nvme/host/nvme.ko.zst
   

   Décision : Si le module requis pour la racine n’est pas présent, vous devez modifier la configuration initramfs-tools ou installer des paquets manquants.

9. Mettez à jour la config du chargeur:

   cr0x@server:~$ sudo update-grub
   Found linux image: /boot/vmlinuz-6.8.0-50-generic
   Found initrd image: /boot/initrd.img-6.8.0-50-generic
   done
   

   Décision : Si GRUB ne voit pas l’initrd, corrigez le nommage dans /boot et régénérez à nouveau.

10. Redémarrez une fois, puis validez:

    cr0x@server:~$ sudo reboot
    ...connection closed...
    

    Décision : Après le démarrage, vérifiez uname -r et contrôlez les logs pour les erreurs de chargement de modules.

Checklist 3 : Si vous devez reconstruire l’initramfs depuis un environnement de secours

Utilisez ceci lorsque vous ne pouvez démarrer aucun noyau installé. Les étapes générales sont cohérentes :
montez la racine, montez /boot, bind mount /dev /proc /sys, chroot, puis reconstruisez.
Les détails varient selon votre pile de stockage, mais la discipline est la même.

cr0x@server:~$ sudo mount /dev/mapper/vg0-root /mnt
cr0x@server:~$ sudo mount /dev/sda2 /mnt/boot
cr0x@server:~$ for i in dev proc sys run; do sudo mount --bind /$i /mnt/$i; done
cr0x@server:~$ sudo chroot /mnt /bin/bash

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

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

Décision : Si update-initramfs échoue dans le chroot, corrigez l’état des paquets (en-têtes, modules, DKMS) dans le chroot, pas dans l’OS de secours.

FAQ

1) Dois-je utiliser update-initramfs -u -k all ou cibler un noyau ?

Ciblez un noyau lorsque vous êtes en mode incident et que vous voulez réduire les variables.
Utilisez -k all après avoir corrigé des problèmes systémiques (DKMS, firmware) et vouloir la cohérence entre noyaux de secours.

2) Quelle est la différence entre -u et -c pour update-initramfs ?

-u met à jour une image initramfs existante ; -c en crée une nouvelle depuis zéro.
Si vous soupçonnez une corruption ou un mauvais résultat incrémental, utilisez -c pour le noyau cible.

3) J’ai reconstruit l’initramfs, mais il ne trouve toujours pas la racine. Et maintenant ?

Vérifiez que le module est présent dans l’initramfs (lsinitramfs | grep), vérifiez que l’UUID racine existe dans /dev/disk/by-uuid dans l’invite initramfs,
et vérifiez la ligne de commande du noyau (/proc/cmdline). Si l’UUID n’existe pas, il vous manque un pilote de stockage/firmware ou il y a un vrai problème matériel.

4) DKMS affiche « built » mais pas « installed ». Est-ce important ?

Oui. « Built » signifie que ça a compilé ; « installed » signifie que le module a été placé là où le noyau le chargera et que l’intégration depmod a été effectuée.
Pour des modules critiques au démarrage (ZFS root), vous voulez « installed » pour le noyau cible.

5) Comment savoir si j’ai besoin de linux-modules-extra ?

Si un module attendu (système de fichiers, pilote de stockage, NIC peu courant) est absent de /lib/modules/<kernel>,
il peut se trouver dans le paquet « extra » selon le packaging Ubuntu.
Vérifiez avec modinfo -k <kernel> <module> ; si cela échoue, installez le paquet linux-modules-extra pour ce noyau.

6) Les avertissements de firmware pendant la génération d’initramfs sont-ils fatals ?

Pas automatiquement. Ils deviennent fatals si le firmware est nécessaire pour initialiser le matériel requis au démarrage (certains périphériques de stockage/NIC).
Si le système échoue tôt et que l’avertissement mentionne votre stockage ou NIC critique, considérez-le comme probablement pertinent.

7) J’utilise LUKS + LVM. Que dois-je vérifier dans l’initramfs ?

Assurez-vous que dm-crypt et les outils LVM sont présents et que l’initramfs inclut les hooks pertinents.
Concrètement : vérifiez que les modules et binaires existent dans l’initramfs et que votre /etc/crypttab est correct.
Puis régénérez l’initramfs pour le noyau cible.

8) Puis-je corriger ça en bloquant l’ancien noyau et en ignorant le nouveau ?

Temporairement, oui, comme mesure de confinement. Opérationnellement, c’est une bombe à retardement.
Vous devez toujours réparer la chaîne de build (DKMS, en-têtes, espace /boot, signature) ou vous répéterez l’incident plus tard dans de pires conditions.

9) Que faire si GRUB démarre le mauvais noyau même après mise à jour ?

Confirmez ce que GRUB considère comme défaut, régénérez la config avec update-grub, et vérifiez que l’initrd référencé existe.
Vérifiez aussi les éditions manuelles dans /etc/default/grub qui pourraient épingler un noyau plus ancien.

10) Pourquoi cela se produit-il « aléatoirement » après des mises à jour ?

Ce n’est pas aléatoire. C’est généralement l’un des éléments suivants : capacité /boot, mises à jour interrompues, échecs de build DKMS, politique Secure Boot, en-têtes manquants,
ou un hook initramfs qui a échoué. Ce sont des problèmes déterministes avec des symptômes bruyants.

Prochaines étapes que vous devriez réellement faire

Si vous êtes ici parce que la production vient de planter, appliquez la correction disciplinée :
démarrez un noyau connu bon, confirmez que /boot a de l’espace, vérifiez les en-têtes et l’état DKMS pour le noyau cible,
reconstruisez l’initramfs pour ce noyau, vérifiez que les modules requis sont embarqués, mettez à jour GRUB, redémarrez une fois.
Ni plus, ni moins.

Puis prévenez la récidive. Ajoutez des vérifications à vos workflows de mise à jour et de redémarrage :
alertez sur l’utilisation de /boot, traitez les erreurs de génération d’initramfs comme des échecs, vérifiez l’état DKMS par noyau,
et conservez au moins un noyau de secours jusqu’à ce que le nouveau soit validé. Les pratiques ennuyeuses ne sont pas glamour,
mais elles coûtent moins cher que les temps d’arrêt et sont moins excitantes qu’une session console à 2h du matin.