Problèmes de démarrage sur configurations NVMe-only : vérifier UEFI, initramfs et fstab

Problèmes de démarrage sur des configurations NVMe-only surviennent dans des environnements de production souvent après des mises à jour du noyau, des modifications de stockage ou des mises à jour du firmware. Ce runbook s’adresse aux administrateurs, aux ingénieurs système et aux opérateurs et décrit une séquence de vérification éprouvée : visibilité du matériel NVMe, UEFI/ESP, chargeur d’amorçage et ligne de commande du noyau, contenu de l’initramfs et /etc/fstab. Chaque mesure inclut les risques pertinents, des commandes pratiques et une stratégie de retour en arrière.

Pourquoi procéder de façon systématique ? L’interaction de la chaîne d’amorçage

La chaîne d’amorçage n’est pas un artefact unique, mais plusieurs couches qui collaborent : le firmware (UEFI) lit la partition système EFI (ESP) et démarre un chargeur EFI ; le chargeur d’amorçage (p. ex. GRUB2 ou systemd-boot) charge le noyau et l’initramfs et transmet la ligne de commande du noyau ; l’initramfs (un système de fichiers racine temporaire) initialise les pilotes et les outils (pilotes NVMe, LVM, mdadm, cryptsetup) et monte le système de fichiers racine ; ce n’est qu’ensuite que /etc/fstab prend en charge les montages complémentaires. Des erreurs dans une couche ressemblent souvent à des erreurs matérielles — d’où l’importance de la séquence de vérification.

Classer les symptômes et évaluer les conséquences

Avant d’effectuer des modifications, identifiez le symptôme. Cela économise du temps et évite des interventions inappropriées :

• Le firmware/UEFI affiche „No bootable device“ : se concentrer sur l’ESP, les entrées NVRAM et les types de partition.
• Le chargeur d’amorçage démarre le noyau, puis passage en shell initramfs : se concentrer sur la ligne de commande du noyau et le contenu de l’initramfs.
• Le root est monté, puis systemd bascule en mode d’urgence : /etc/fstab, montages manquants ou temporisations sont probables.

Avant l’intervention : mesures de sécurité

Minimiser les risques, limiter le temps d’indisponibilité :

• Prévoir une console distante (IPMI/iDRAC/iLO/console VM) pour voir et contrôler les messages de démarrage.
• Conserver les entrées de noyau plus anciennes ; ne supprimez rien que vous ne puissiez sauvegarder de manière reproductible.
• Faire une copie de l’ESP et de l’initramfs avant d’écrire.
• Réserver les modifications critiques aux fenêtres de maintenance et documenter les étapes.

Étape de vérification 1 : matériel NVMe et visibilité par le noyau

Objectif : vérifier si le système et le noyau voient les périphériques NVMe. Si les périphériques /dev/nvme* sont absents, aucune réparation du chargeur d’amorçage n’aidera.

# Geräte und Partitionen anzeigen
lsblk -e7 -o NAME,TYPE,SIZE,MODEL,SERIAL,FSTYPE,UUID,MOUNTPOINTS

# Dateisystem-UUIDs
blkid

# Kernel-Meldungen nach NVMe/PCIe-Fehlern durchsuchen
dmesg | grep -iE 'nvme|pcie|iommu|timeout|reset' | tail -n 200

Interprétation : si lsblk n’affiche pas de périphériques NVMe, vérifiez les paramètres BIOS/UEFI (mode PCIe, ACS/ASPM, hotplug), les mises à jour du firmware de la carte mère/du contrôleur NVMe ou les connexions physiques (Backplane). Parfois, le kernel de secours n’inclut pas le pilote NVMe adéquat.

Étape de vérification 2 : UEFI, ESP et entrées NVRAM

L’ESP (partition système EFI) doit être une partition valide de type EF00 (GPT) et formatée en FAT32. Si l’ESP est corrompue ou contient des chemins incorrects, l’UEFI ne trouvera pas de chargeur.

# ESP mounten und Inhalt prüfen
mkdir -p /mnt/esp
mount -t vfat /dev/nvme0n1p1 /mnt/esp
ls -la /mnt/esp

# NVRAM-Einträge anzeigen (Rescue muss im UEFI-Modus gebootet sein)
efibootmgr -v

Pièges :

• Lors du clonage d’une NVMe, la table de partitions peut changer ; les entrées NVRAM peuvent alors pointer vers des PARTUUIDs inexistantes.
• Secure Boot peut bloquer des chargeurs non signés ; vérifiez l’état des signatures et de MOK.

Étape de vérification 3 : chargeur de démarrage, Kernel-Cmdline et root=

La Kernel-Cmdline détermine quel périphérique sert de root. Si root= est incorrect, le système tombe immédiatement dans le shell initramfs. Vérifiez la configuration du chargeur de démarrage, pas seulement l’argument du noyau en cours d’exécution.

# Vérifier la ligne de commande du noyau actuelle
cat /proc/cmdline

# Examiner la configuration GRUB dans le système monté
grep -R "Linux .*root=" -n /mnt/sysroot/boot/grub*/grub.cfg | head -n 50

# Lire les entrées systemd-boot
find /mnt/esp/loader -maxdepth 2 -type f -name "*.conf" -exec sed -n '1,120p' {} ;

Conseil pratique: Utilisez UUID= ou PARTUUID= dans root=; /dev/nvme0n1p2 peut changer d’ordre lors de modifications matérielles. PARTUUID fait référence aux entrées de la table de partitions et reste plus stable lors d’une repartition.

Étape de vérification 4 : initramfs – vérifier le contenu, régénérer et identifier les sources d’erreur

L’initramfs est un root temporaire contenant les pilotes et outils nécessaires pour préparer le périphérique root. Il existe deux outils répandus pour générer l’initramfs : update-initramfs (Debian/Ubuntu) et dracut (RHEL/Alma/Rocky). Si le pilote NVMe ou cryptsetup manque, le système ne peut pas déverrouiller ou monter.

# Exemple : vérifier le contenu de l'initramfs (Debian/Ubuntu)
lsinitramfs /mnt/sysroot/boot/initrd.img-$(ls /mnt/sysroot/lib/modules | sort -V | tail -n 1) | grep -iE 'nvme|lvm|crypt|mdadm|ext4|xfs|btrfs'

# Exemple : vérifier le contenu de l'initramfs (RHEL/Rocky/Alma)
lsinitrd /mnt/sysroot/boot/initramfs-*.img | grep -iE 'nvme|lvm|crypt|mdraid|ext4|xfs|btrfs'

Régénérez l’initramfs depuis le chroot du système cible et sauvegardez toujours l’ancien fichier:

# Dans le chroot (Debian/Ubuntu)
cp -a /boot/initrd.img-$(uname -r) /boot/initrd.img-$(uname -r).bak.$(date +%F)
update-initramfs -u -k all

# Dans le chroot (RHEL/Rocky/Alma)
KVER=$(ls /lib/modules | sort -V | tail -n 1)
cp -a /boot/initramfs-${KVER}.img /boot/initramfs-${KVER}.img.bak.$(date +%F)
dracut -f /boot/initramfs-${KVER}.img ${KVER}

Causes fréquentes d’erreurs lors de la régénération:

• /etc/crypttab est manquant ou incorrect : les paramètres cryptsetup ne sont pas inclus dans l’initramfs.
• Des filtres LVM-PVG dans /etc/lvm/lvm.conf empêchent la détection des groupes de volumes.
• Des modules dracut ont été désactivés par une dracut.conf personnalisée ; vérifiez /etc/dracut.conf.d.

Étape de vérification 5 : chroot propre et activation des dépendances

Travaillez de préférence dans le chroot du système cible. Cela évite que les chemins système de l’environnement de secours faussent la réparation. Montez /dev, /proc, /sys et /run.

mount /dev/nvme0n1p2 /mnt/sysroot
mount -t vfat /dev/nvme0n1p1 /mnt/sysroot/boot/efi
mount --bind /dev  /mnt/sysroot/dev
mount --bind /proc /mnt/sysroot/proc
mount --bind /sys  /mnt/sysroot/sys
mount --bind /run  /mnt/sysroot/run
chroot /mnt/sysroot /bin/bash

Si LUKS/LVM/RAID est utilisé, ouvrez/activez-les au préalable:

# Déverrouiller LUKS
cryptsetup luksOpen /dev/nvme0n1p3 cryptroot

# Activer LVM
pvscan
vgscan
vgchange -ay

# Assembler les RAID mdadm
mdadm --assemble --scan

Vérifier /etc/fstab : privilégier la stabilité aux fichiers de périphériques fragiles

/etc/fstab contrôle les montages persistants. Des entrées incorrectes ou bloquantes sont une cause fréquente de démarrages ultérieurs en Emergency-Mode, même si le root a été monté correctement.

# fstab und Geräteliste prüfen
cat /etc/fstab
lsblk -f
blkid

Recommandations :

• Utilisez UUID= ou PARTUUID= au lieu de /dev/nvme0n1pX, car les noms de périphériques /dev peuvent changer lors de modifications de l’énumération.
• Pour les montages non critiques, ajouter temporairement nofail afin que le démarrage ne s’arrête pas à chaque échec de montage.
• Pour les montages réseau ou les volumes susceptibles de se mettre en veille (spindown), utiliser x-systemd.automount.
• Vérifier les entrées resume et swap : des devices de resume incorrects entraînent de longs délais d’attente.

# Beispiel fstab-Eintrag mit UUID und nofail
UUID=1111-2222  /data   ext4  defaults,nofail,x-systemd.device-timeout=10  0 2

Problèmes de timing et d’initialisation

Certains contrôleurs NVMe ou backplanes nécessitent plus de temps pour s’initialiser. L’initramfs tente par défaut pendant une durée déterminée de trouver les périphériques. En cas d’initialisation lente, vous pouvez temporairement définir rootdelay=30 ou des paramètres de retry spécifiques, jusqu’à ce que des solutions firmware/BIOS soient mises en place. Des mesures pérennes incluent des mises à jour de firmware, des réglages BIOS (p. ex. désactiver Fast Boot) ou des modifications matérielles.

Cas particuliers : Secure Boot, noyaux/chargeurs signés et MOK

Secure Boot vérifie les signatures des chargeurs EFI et des noyaux. Si vous utilisez des noyaux personnalisés ou des chargeurs non signés, le démarrage échoue sans que le système tombe dans le shell initramfs. Vérifiez :

• Si le chargeur est signé dans l’ESP.
• Si le noyau possède une signature valide (lors de l’utilisation de Shim/MOK).
• Si le MOK (Machine Owner Key) a été chargé et accepté.

Si nécessaire, vous pouvez désactiver temporairement Secure Boot pour effectuer une réparation — respectez les politiques de sécurité et consignez la mesure.

Réparation du chargeur de démarrage : GRUB vs. systemd-boot

Selon le chargeur, la procédure de réparation diffère. Exemples :

# GRUB UEFI neu installieren (im chroot, ESP gemountet)
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
update-grub

# systemd-boot installieren
bootctl --path=/boot/efi install

Important : documentez efibootmgr -v avant toute modification et créez des sauvegardes de l’ESP. Un grub-install incorrect peut écraser les entrées NVRAM.

Hôtes Docker : pourquoi les problèmes de démarrage NVMe sont particulièrement critiques

Les hôtes de conteneurs sont souvent minimalistes et utilisent de nombreux volumes statiques. Un échec de démarrage affecte non seulement des services individuels, mais aussi l’orchestration des conteneurs, la disponibilité des volumes et la journalisation. Aspects supplémentaires :

• Docker (ou containerd) utilise le système de fichiers racine de l’hôte pour le stockage des conteneurs (p. ex. /var/lib/docker). Des problèmes lors du montage du root entraînent des volumes en lecture seule ou manquants.
• Overlay2 et device-mapper sont sensibles aux états incohérents du système de fichiers ; un initramfs corrompu qui monte le root avec retard peut provoquer des blocages de conteneurs au démarrage.
• Dans les configurations en cluster, les orchestrateurs synchronisent l’état et doivent disposer de checks de santé pour déclencher un basculement.

Vérifications pratiques sur un hôte Docker (après chroot réussi) :

# Docker-Status prüfen
systemctl status docker
docker info | sed -n '1,120p'

# Storage-Pfade überprüfen
ls -la /var/lib/docker
df -h /var/lib/docker

Bonnes pratiques avant modifications du noyau/du démarrage :

• Sauvegardez les volumes des conteneurs (snapshots, rsync, push dans un registre pour les images).
• Testez les modifications de démarrage d’abord sur un réplicat ou sur des canaries.
• Traitez les artefacts de démarrage comme des objets de configuration : versionnement, revue et enregistrement des changements.

Stratégie de restauration et de repli

Si la cause reste incertaine, agissez de manière minimale et réversible :

1. Essayez de démarrer avec un noyau plus ancien plutôt que de reconstruire.
2. Mettez les entrées fstab critiques sur nofail au lieu de les supprimer.
3. Sauvegardez l’ESP et l’initramfs, exportez la sortie d’efibootmgr.
4. Procédez par étapes : d’abord la visibilité du NVMe, ensuite le chargeur de démarrage/la cmdline du noyau, puis l’initramfs et la fstab.
5. En cas d’urgence : déployer un réplicat depuis la sauvegarde/l’image et planifier la migration des IP/services.

Checklist pratique (référence rapide)

1. Déterminer la classe de symptôme : UEFI / initramfs / fstab.
2. NVMe visible ? (lsblk, dmesg)
3. Préparer le chroot et activer LUKS/LVM/RAID.
4. Monter l’ESP, sauvegarder efibootmgr -v.
5. Vérifier la cmdline du noyau : root=UUID/PARTUUID.
6. Vérifier le contenu de l’initramfs et le régénérer depuis le chroot (sauvegarde).
7. Confronter /etc/fstab et blkid, utiliser nofail.
8. Réinstaller le chargeur de démarrage si nécessaire (grub-install / bootctl).
9. Test de démarrage, vérifier les journaux, rédiger un post-mortem et un enregistrement des changements.

Conclusion

Pour les problèmes de démarrage sur des configurations exclusivement NVMe, un diagnostic réussi combine une démarche méthodique, la connaissance de la chaîne de démarrage et une action conservatrice. NVMe est rarement le seul responsable ; le plus souvent interviennent conjointement UEFI/NVRAM, la cmdline du noyau, des modules initramfs manquants ou des entrées fstab erronées. Travaillez depuis un chroot, sauvegardez les artefacts de démarrage, régénérez l’initramfs avec prudence et planifiez des mesures de repli. Pour les hôtes Docker, des exigences supplémentaires s’appliquent aux volumes et à la résilience de l’orchestrateur — testez d’abord les modifications sur des réplicats ou des hôtes canary.

Avec l’ordre de vérification et les commandes concrètes décrites ici, vous réduirez les temps d’arrêt et éviterez des réinstallations inutiles. La documentation et le contrôle des changements sont aussi importants que la réparation technique.

Problèmes de démarrage sur configurations exclusivement NVMe : exploitation, monitoring et automatisation

Outre la réparation classique, il est essentiel d’organiser l’exploitation de façon à détecter tôt les erreurs de démarrage, à les tester de manière reproductible et à pouvoir les revenir en arrière en toute sécurité. Trois axes sont pratiquement toujours payants : sauvegarde des artefacts (ESP, NVRAM, GPT), télémétrie de démarrage observable et validation automatisée dans la pipeline CI/CD.

Sauvegarde des artefacts et sécurisation des métadonnées

Sauvegardez systématiquement avant toute modification la partition EFI, les entrées NVRAM et la table GPT. Ces métadonnées sont souvent le moyen le plus rapide de restaurer un état fonctionnel.

# GPT-Backup
sgdisk --backup=gpt-backup-$(date +%F).bin /dev/nvme0n1

# NVRAM/efibootmgr sichern
efibootmgr -v > /root/efibootmgr-$(date +%F).txt

# ESP snapshot
mount /dev/nvme0n1p1 /mnt/esp
tar -c -C /mnt/esp . | gzip -c > /root/esp-backup-$(date +%F).tar.gz

Observabilité : journalisation précoce et accès à distance

• Activez une console série ou Netconsole pour les messages noyau précoces. Ainsi vous verrez si les contrôleurs NVMe sont initialisés.
• Configurez le journal systemd en mode persistant afin de conserver les logs entre les démarrages.
• Pour les volumes root chiffrés, prévoyez une procédure de déverrouillage à distance (p. ex. SSH‑Dropbear dans l’initramfs ou un key‑escrow central) et régulez strictement les accès et l’audit.

CI/CD et stratégie Canary pour le kernel/initramfs

Générez initramfs et les artefacts du bootloader de manière reproductible dans votre pipeline et vérifiez automatiquement que les modules nécessaires (nvme, nvme_core, lvm, dm-crypt etc.) sont inclus. Déployez d’abord les mises à jour du kernel et du firmware sur des hôtes Canary, en surveillant le temps de démarrage, les erreurs dmesg et la santé des conteneurs (sur les hôtes Docker).

Élément spécifique : en-tête LUKS et gestion des clés

# LUKS-Header sichern
cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file /root/luks-header-$(date +%F).bin

Sans sauvegarde de l’en-tête, les volumes LUKS ne sont souvent plus récupérables après des écritures incorrectes. Documentez les processus et stockez clés et sauvegardes dans un coffre sécurisé avec contrôle d’accès.

Ces mesures opérationnelles réduisent sensiblement le risque d’indisponibilité : sauvegarder les métadonnées, activer une télémétrie précoce, produire des artefacts reproductibles et les déployer progressivement sont souvent plus efficaces que des réparations ad hoc en cas d’urgence.

Pour ce sujet, le démarrage UEFI et la régénération de l’initramfs sont également importants. Cet article place ces aspects dans leur contexte et précise ce qui compte au quotidien.