Problemi di avvio in configurazioni basate esclusivamente su NVMe: verificare UEFI, initramfs e fstab

Problemi di avvio in configurazioni esclusivamente NVMe si verificano in ambienti produttivi spesso dopo aggiornamenti del kernel, modifiche dello storage o aggiornamenti del firmware. Questo runbook è pensato per amministratori, ingegneri di sistema e operatori e descrive una sequenza di controllo verificata: visibilità dell’hardware NVMe, UEFI/ESP, bootloader e Kernel-Cmdline, contenuto dell’initramfs e /etc/fstab. Ogni intervento include i rischi rilevanti, comandi pratici e una strategia di rollback.

Perché procedere in modo sistematico? L’interazione della catena di avvio

La catena di avvio non è un singolo artefatto, ma più livelli che lavorano insieme: il firmware (UEFI) legge la EFI-Systempartition (ESP) e avvia un EFI-Loader; il bootloader (es. GRUB2 o systemd-boot) carica kernel e initramfs e passa la Kernel-Cmdline; l’initramfs (un filesystem root temporaneo) inizializza driver e strumenti (driver NVMe, LVM, mdadm, cryptsetup) e monta il filesystem root; solo successivamente /etc/fstab si occupa dei mount aggiuntivi. Errori in un livello spesso sembrano guasti hardware — per questo l’ordine di controllo è importante.

Classificare i sintomi e valutare le conseguenze

Prima di apportare modifiche, inquadrate il sintomo. Questo fa risparmiare tempo e previene interventi errati:

• Firmware/UEFI segnala “No bootable device”: focus su ESP, voci NVRAM e tipi di partizione.
• Il bootloader avvia il kernel, poi si entra in una shell dell’initramfs: focus su Kernel-Cmdline e contenuto dell’initramfs.
• Root montato, successivamente systemd entra in Emergency-Mode: /etc/fstab, mount mancanti o timeout sono probabili.

Prima dell’intervento: misure di sicurezza

Minimizzare i rischi, limitare i tempi di indisponibilità:

• Mettere a disposizione una console remota (IPMI/iDRAC/iLO/console VM) in modo da poter vedere e controllare i messaggi di boot.
• Mantenere voci kernel precedenti; non cancellare nulla che non sia possibile ripristinare in modo riproducibile.
• Creare copie di ESP e initramfs prima di scrivere.
• Limitare modifiche critiche a finestre di manutenzione e documentare i passi.

Prüfschritt 1: NVMe-Hardware und Kernel-Sichtbarkeit

Obiettivo: verificare se il sistema e il kernel vedono i dispositivi NVMe. Se mancano dispositivi /dev/nvme*, nessun ripristino del bootloader aiuta.

# 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

Interpretazione: se lsblk non mostra dispositivi NVMe, verificate le impostazioni del BIOS/UEFI (modalità PCIe, ACS/ASPM, hotplug), aggiornamenti firmware della scheda madre/controller NVMe o connessioni fisiche (backplane). A volte nel kernel di rescue manca il driver NVMe appropriato.

Prüfschritt 2: UEFI, ESP und NVRAM-Einträge

La ESP (EFI-Systempartition) deve essere una partizione valida con tipo EF00 (GPT) e formattata FAT32. Se la ESP è danneggiata o contiene percorsi errati, l’UEFI non trova un loader.

# 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

Insidie:

• Clonando una NVMe la tabella delle partizioni può cambiare; le voci NVRAM possono allora puntare a PARTUUID non esistenti.
• Secure Boot può bloccare loader non firmati; verificate lo stato delle firme e il MOK-Status.

Passo di verifica 3: Bootloader, riga di comando del kernel e root=

La riga di comando del kernel determina quale dispositivo è usato come root. Se root= è impostato in modo errato, il sistema entra immediatamente nella shell initramfs. Verifichi la configurazione del bootloader, non solo l’argomento kernel attualmente in esecuzione.

# Verificare la riga di comando del kernel corrente
cat /proc/cmdline

# Esaminare la configurazione di GRUB nel sistema montato
grep -R "Linux .*root=" -n /mnt/sysroot/boot/grub*/grub.cfg | head -n 50

# Leggere le voci di systemd-boot
find /mnt/esp/loader -maxdepth 2 -type f -name "*.conf" -exec sed -n '1,120p' {} ;

Suggerimento pratico: usi UUID= o PARTUUID= in root=; /dev/nvme0n1p2 può spostarsi con modifiche hardware. PARTUUID si riferisce alle voci della tabella delle partizioni e resta più stabile in caso di repartizionamento.

Passo di verifica 4: initramfs – verificare il contenuto, rigenerare e individuare le cause di errore

L’initramfs è una root temporanea che contiene i driver e gli strumenti necessari per predisporre il dispositivo root. Esistono due strumenti diffusi per generare l’initramfs: update-initramfs (Debian/Ubuntu) e dracut (RHEL/Alma/Rocky). Se manca, per esempio, il driver NVMe o cryptsetup, il sistema non può sbloccare o montare il disco.

# Esempio: verificare il contenuto dell'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'

# Esempio: verificare il contenuto dell'initramfs (RHEL/Rocky/Alma)
lsinitrd /mnt/sysroot/boot/initramfs-*.img | grep -iE 'nvme|lvm|crypt|mdraid|ext4|xfs|btrfs'

Rigeneri l’initramfs dal chroot del sistema di destinazione e salvi sempre il file precedente:

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

# Nel 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}

Cause di errore frequenti durante la rigenerazione:

• /etc/crypttab mancante o errato: i parametri di cryptsetup non vengono inclusi nell’initramfs.
• I filtri LVM-PVG in /etc/lvm/lvm.conf impediscono il riconoscimento dei volume group.
• Moduli dracut disabilitati tramite una dracut.conf personalizzata; verifichi /etc/dracut.conf.d.

Passo di verifica 5: Effettuare un chroot pulito e attivare le dipendenze

Lavori, se possibile, nel chroot del sistema di destinazione. Questo evita che i percorsi di sistema dell’ambiente di rescue falsino la riparazione. Monti /dev, /proc, /sys e /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

Se sono usati LUKS/LVM/RAID, apra/attivi questi prima:

# Aprire LUKS
cryptsetup luksOpen /dev/nvme0n1p3 cryptroot

# Attivare LVM
pvscan
vgscan
vgchange -ay

# Assemblare i RAID mdadm
mdadm --assemble --scan

Controllare /etc/fstab: stabilità invece di file dispositivo fragili

/etc/fstab gestisce i mount persistenti. Voci errate o bloccanti sono una causa frequente di avvii successivi in modalità di emergenza, anche se la root è stata montata correttamente.

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

Raccomandazioni:

• Usi UUID= o PARTUUID= invece di /dev/nvme0n1pX, perché i nomi dei dispositivi in /dev possono spostarsi in caso di modifiche nell’enumerazione.
• Per mount non critici impostare temporaneamente nofail, in modo che il boot non si blocchi a ogni mount fallito.
• Per mount di rete o volumi con rischio di spindown usare x-systemd.automount.
• Controllare le voci di resume e swap: device di resume errati causano timeout prolungati.

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

Problemi di timing e inizializzazione

Alcuni controller NVMe o backplane richiedono più tempo per l’inizializzazione. L’initramfs prova per un periodo di tempo predefinito a trovare i dispositivi. In caso di inizializzazione lenta si può impostare temporaneamente rootdelay=30 o parametri di retry specifici, fino a quando non vengono implementate soluzioni a livello di firmware/BIOS. Misure permanenti includono aggiornamenti firmware, impostazioni BIOS (es. disabilitare Fast Boot) o modifiche fisiche all’hardware.

Casi speciali: Secure Boot, kernel/loader firmati e MOK

Secure Boot verifica le firme di EFI loader e kernel. Se si utilizzano kernel personalizzati o loader non firmati, il boot fallisce senza che il sistema entri nella shell dell’initramfs. Controllare:

• Se il loader nella ESP è firmato.
• Se il kernel ha una firma valida (quando si usa Shim/MOK).
• Se il MOK (Machine Owner Key) è stato caricato e accettato.

Se necessario è possibile disabilitare temporaneamente il Secure Boot per eseguire la riparazione — rispettare le policy di sicurezza e registrare l’operazione.

Riparazione del bootloader: GRUB vs. systemd-boot

La procedura di riparazione varia in base al bootloader. Esempi:

# 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

Importante: documentare efibootmgr -v prima delle modifiche e creare backup della ESP. Un grub-install sbagliato può sovrascrivere voci NVRAM.

Docker host: warum NVMe-Bootprobleme besonders kritisch sind

Gli host container sono spesso minimalisti e usano molti volumi statici. I fallimenti di boot non riguardano solo singoli servizi, ma anche l’orchestrazione dei container, la disponibilità dei volumi e il logging. Aspetti aggiuntivi:

• Docker (o containerd) usa il filesystem root dell’host per il container storage (es. /var/lib/docker). Problemi nel mount della root portano a volumi in sola lettura o mancanti.
• Overlay2 e device-mapper sono vulnerabili in caso di stati incoerenti del filesystem; un initramfs danneggiato che monta la root in ritardo può causare colli di bottiglia all’avvio dei container.
• Negli ambienti clusterizzati gli orchestratori sincronizzano lo stato e dovrebbero disporre di health check per attivare il failover.

Controlli pratici su un host Docker (dopo un chroot riuscito):

# 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

Best practice prima di modifiche al kernel/boot:

• Eseguire il backup dei volumi dei container (snapshot, rsync, push su registry per le immagini).

Strategia di ripristino e rollback

Se la causa rimane incerta, intervenite in modo minimale e reversibile:

1. Provate ad avviare con un kernel più vecchio invece di ricostruirne uno nuovo.
2. Impostate le voci critiche di /etc/fstab su nofail anziché eliminarle.
3. Eseguite il backup di ESP e initramfs, esportate l’output di efibootmgr.
4. Procedete per gradi: prima la visibilità della NVMe, poi Bootloader/Cmdline, poi initramfs e fstab.
5. In caso di emergenza: predisporre una replica da backup/imaging e pianificare la migrazione di IP/servizi.

Checklist pratica (riferimento rapido)

1. Determinare la classe di sintomo: UEFI / initramfs / fstab.
2. NVMe visibile? (lsblk, dmesg)
3. Preparare il chroot e attivare LUKS/LVM/RAID.
4. Montare l’ESP, salvare l’output di efibootmgr -v.
5. Verificare la Kernel-Cmdline: root=UUID/PARTUUID.
6. Controllare il contenuto di initramfs e rigenerarlo dal chroot (backup).
7. Confrontare /etc/fstab con blkid, usare nofail.
8. Reinstallare il bootloader se necessario (grub-install / bootctl).
9. Eseguire un boot di test, verificare i log, redigere postmortem e registro delle modifiche.

Conclusione

Per problemi di avvio in setup esclusivamente NVMe la diagnosi efficace è una combinazione di approccio metodico, conoscenza della catena di boot e azioni conservative. NVMe è raramente l’unico responsabile; di solito intervengono insieme UEFI/NVRAM, Kernel-Cmdline, moduli initramfs mancanti o voci errate in fstab. Lavorate in chroot, eseguite il backup degli artefatti di boot, rigenerate initramfs con cautela e pianificate misure di rollback. Per gli host Docker valgono inoltre requisiti stringenti riguardo ai volumi e alla resilienza dell’orchestrator — testate le modifiche prima su repliche o istanze canary.

Con l’ordine di verifica descritto e i comandi concreti ridurrete i tempi di inattività ed eviterete reinstallazioni non necessarie. La documentazione e il controllo delle modifiche sono tanto importanti quanto la riparazione tecnica.

Problemi di avvio in setup esclusivamente NVMe: Esercizio, monitoraggio e automazione

Oltre alla riparazione classica, è fondamentale strutturare l’operatività in modo che gli errori di boot vengano rilevati precocemente, possano essere testati in modo riproducibile e ripristinati in sicurezza. Tre ambiti si rivelano praticamente sempre utili: backup degli artefatti (ESP, NVRAM, GPT), telemetria di boot osservabile e validazione automatizzata nella pipeline CI/CD.

Backup degli artefatti e salvataggio dei metadati

Prima di apportare modifiche eseguite sempre il backup della partizione EFI, delle voci NVRAM e della tabella GPT. Questi metadati sono spesso la via più rapida per ripristinare uno stato funzionante.

# 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

Osservabilità: logging precoce e accesso remoto

• Attivate una console seriale o Netconsole per i messaggi kernel precoci. In questo modo verificate se i controller NVMe vengono inizializzati.
• Configure systemd‑journal in modalità persistente, in modo che i log vengano conservati tra i vari boot.
• Per i volumi root cifrati prevedete una procedura di sblocco remoto (es. SSH‑Dropbear nell’initramfs o una custodia centrale delle chiavi (key-escrow)) e disciplinate strettamente accesso e audit.

CI/CD e strategia Canary per Kernel/initramfs

Costruite initramfs e artefatti del bootloader in modo riproducibile nella vostra pipeline e verificate automaticamente che i moduli necessari (nvme, nvme_core, lvm, dm‑crypt ecc.) siano inclusi. Distribuite inizialmente gli aggiornamenti di kernel e firmware a Canary‑Hosts monitorando il tempo di avvio, gli errori di dmesg e la Container‑Health (per host Docker).

Sonderelement: LUKS‑Header und Schlüsselmanagement

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

Senza backup dell’header, i volumi LUKS spesso non sono più recuperabili dopo operazioni di scrittura sfortunate. Documentate i processi e conservate chiavi/backup in un vault protetto con controllo degli accessi.

Queste misure operative riducono significativamente il rischio di interruzioni: salvare i metadati, attivare la telemetria precoce, costruire artefatti riproducibili e distribuire gradualmente risultano spesso più efficaci rispetto a riparazioni ad‑hoc in emergenza.

Per questo tema sono inoltre importanti l’avvio UEFI e la rigenerazione dell’initramfs. Il contributo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.