Ripristinare GRUB2 dopo il passaggio tra UEFI e BIOS e la perdita della configurazione del bootloader

La keyword principale GRUB2 wiederherstellen è centrale quando un sistema non si avvia dopo un cambio UEFI/BIOS o a seguito della perdita della configurazione del bootloader. In questo contributo gli amministratori, i system engineer e gli operatori trovano una guida pratica, passo per passo, per la diagnostica, la riparazione e la verifica — inclusi cause tipiche, rischi e strategie di fallback.

Perché si verifica la perdita del boot? Cause spiegate brevemente

Prima di entrare nella pratica: è utile conoscere le cause frequenti per mantenere l’intervento mirato. Le tre categorie principali sono cambi di firmware, problemi di partizionamento/ESP e errori di initramfs/decifratura.

1. Cambio di modalità UEFI/BIOS

UEFI (Unified Extensible Firmware Interface) è l’interfaccia firmware moderna; BIOS o Legacy indica il più vecchio procedimento di avvio basato su MBR. Un passaggio da UEFI a Legacy o viceversa può rendere invalide le voci di avvio nel firmware (NVRAM), perché i sistemi UEFI si basano su una EFI System Partition (ESP) con file .efi, mentre il Legacy GRUB si aspetta il MBR o una BIOS‑Boot‑Partition.

2. EFI System Partition (ESP) danneggiata o errata

L’ESP è una piccola partizione FAT32 con il tipo di codice EFI System (GPT ef00). Se è stata cancellata, sovrascritta con Windows o montata in modo errato, mancano i binari GRUB‑EFI (/EFI/<Vendor>/grubx64.efi) e il sistema non si avvia.

3. Initramfs, root cifrato o mismatch del kernel

GRUB carica il kernel e l’initramfs (Initial RAM Filesystem). Se l’initramfs non contiene i moduli corretti per LVM/LUKS o per i filesystem, il boot fallisce dopo GRUB. Analogamente, un aggiornamento del kernel senza rigenerazione dell’initramfs su volumi root cifrati porta a sistemi non decifrabili.

Preparazione: prerequisiti, rischi e strumenti necessari

Prima di intervenire, verificate: disponete di un ambiente di rescue (Live‑USB), accesso al setup del firmware, backup dell’ESP e eventualmente degli header LUKS? Strumenti: una distribuzione Live aggiornata con grub-install/grub‑efi, efibootmgr, lsblk, blkid, parted o gdisk, mount, chroot e, per ambienti RHEL/CentOS, dracut.

Rischi importanti:

• Ulteriore sovrascrittura dell’ESP che rende inutilizzabili altri sistemi operativi (Windows).
• Mancanza di backup degli header LUKS su root cifrato — in tal caso il ripristino è molto più complesso.
• Dispositivo di destinazione errato per grub-install (es. una partizione anziché l’intero disco) può danneggiare il dispositivo di avvio.

Diagnosi: verificare lo stato del sistema (Live‑USB)

Avviate da Live‑USB (preferibilmente la stessa architettura: x86_64). Montate i dischi in sola lettura per la prima analisi.

Comandi di controllo importanti e il loro significato

Panoramica di partizioni e dispositivi:

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT,LABEL

Tipi di partizione e codici GPT:

sudo parted -l

Marcatura ESP/EFI e UUID:

sudo blkid | grep -i efi
# oder gezielt
sudo lsblk -f /dev/nvme0n1p1

Voci EFI nel firmware (NVRAM):

sudo efibootmgr -v

Se efibootmgr fallisce: il firmware potrebbe essere avviato in modalità BIOS/Legacy o efivarfs non è montato. Verificate /sys/firmware/efi/exists — se questa directory esiste, l’ambiente Live sta già eseguendo in modalità UEFI.

[ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy/BIOS mode"

Scenari di ripristino: passo‑per‑passo

Distinguamo i tre casi pratici più comuni e eseguiamo i passaggi necessari per ciascuno: (A) UEFI: reinstallare GRUB‑EFI, (B) BIOS/Legacy: installare GRUB nel MBR, (C) cambio UEFI↔Legacy o NVRAM difettoso: fallback rimovibile.

A. UEFI: reinstallare GRUB2 (caso standard)

Obiettivo: scrivere i binari EFI sulla ESP, creare o correggere la voce NVRAM, generare grub.cfg.

1. Avviare l’ambiente live in modalità UEFI (importante per efibootmgr).
2. Montare root, /boot e la ESP. Sostituire /dev/sdXn con i dispositivi appropriati.

sudo mount /dev/sdX2 /mnt            # root-Partition
sudo mount /dev/sdX1 /mnt/boot/efi    # EFI System Partition, FAT32
# Falls /boot eine eigene Partition hat:
# sudo mount /dev/sdX3 /mnt/boot
# Bind-Mounts für chroot
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run

Usare chroot affinché grub-install venga eseguito nel contesto del sistema (importante per percorsi specifici della distribuzione).

sudo chroot /mnt /bin/bash
# innerhalb des chroots prüfen
mount | grep efi

Installare GRUB per UEFI:

# Beispiel für x86_64-UEFI auf Debian/Ubuntu/Fedora
grub-install --target=x86_64-efi --efi-directory=/boot/efi 
  --bootloader-id=GRUB --recheck --no-nvram
# --no-nvram verhindert Änderungen am NVRAM; nutzen Sie es nur bei Bedarf

Perché ciò funziona: grub-install crea il file binario .efi sulla ESP (es. /boot/efi/EFI/GRUB/grubx64.efi) e, opzionalmente, aggiunge una voce NVRAM. Può fallire se il pacchetto grub‑efi non è installato o l’architettura non corrisponde (i386 vs x86_64).

Generare la configurazione:

# Debian/Ubuntu
update-grub
# RedHat/CentOS
grub2-mkconfig -o /boot/grub2/grub.cfg

Se efibootmgr non può scrivere la voce di avvio, posizionare il file di emergenza come „removable“ (bootx64.efi):

cp /boot/efi/EFI/GRUB/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI
# BIOS/UEFI-Fallback für viele Firmware-Implementierungen

Uscire dal chroot e smontare in modo ordinato:

exit
sudo umount -l /mnt/dev /mnt/proc /mnt/sys /mnt/run
sudo umount /mnt/boot/efi
sudo umount /mnt

B. Legacy BIOS: GRUB in MBR installieren

Se il sistema deve avviarsi in modalità Legacy (ad es. hardware datato), è necessario scrivere GRUB classicamente nel MBR.

# Vorbereitungen wie oben: mount /mnt, chroot
# Install GRUB to MBR (example /dev/sda)
grub-install --target=i386-pc /dev/sda --recheck
grub-mkconfig -o /boot/grub/grub.cfg

Nota: le moderne tabelle di partizione GPT possono richiedere una piccola partizione BIOS‑Boot (tipo ef02 con gdisk) per GRUB‑Stage2. Senza questa partizione grub-install fallirà su dischi GPT se si intende avviare in modalità BIOS.

C. UEFI↔Legacy Wechsel, NVRAM defekt oder begrenztes Firmware‑Menü

Alcuni firmware non permettono più voci NVRAM (troppo numerose o difettose). In tali casi il percorso di avvio rimovibile è utile: il binario EFI installato sotto /EFI/BOOT/BOOTX64.EFI. È robusto, ma può sovrascrivere i bootloader di altri sistemi operativi.

# innerhalb des chroot
mkdir -p /boot/efi/EFI/BOOT
cp /boot/efi/EFI/GRUB/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

Casi speciali e risoluzione dei problemi

Ripristinare GRUB2 con root cifrato (LUKS)

Per root cifrato con LUKS (LUKS ist die Linux Unified Key Setup) è necessario, nel chroot, aprire il volume LUKS affinché /mnt contenga effettivamente il root corretto. Importante: avete salvato l’header LUKS? Senza header il ripristino è molto complesso.

# LUKS-Container öffnen (im Live-System, vor dem Mounten)
sudo cryptsetup luksOpen /dev/sdX2 cryptroot
sudo mount /dev/mapper/cryptroot /mnt

Dopo l’installazione di grub rigenerare l’initramfs (Initramfs è il primo filesystem in RAM che fornisce i moduli per LVM/LUKS):

# Debian/Ubuntu
update-initramfs -u -k all
# RedHat/CentOS
dracut -f

Se è installata la combinazione kernel‑initramfs sbagliata (per es. un kernel più vecchio), il boot dopo GRUB può fallire nella fase di initramfs.

Errore: grub-install segnala „cannot find EFI directory“ o „secure boot“

Cause e soluzioni:

• Partizione EFI non FAT32 o non montata: montarla su /boot/efi.
• Secure Boot attivo: disattivare temporaneamente Secure Boot oppure usare binari firmati (shim). Shim è un piccolo programma firmato che può caricare grubx64.efi non firmato se è sbloccato nel MOK‑Store (Machine Owner Key).
• Pacchetto mancante: su Debian/Ubuntu sono necessari grub‑efi‑amd64 ed efibootmgr; su sistemi RHEL‑based grub2‑efi‑x64.

efibootmgr non scrive in NVRAM o le voci scompaiono

Molte cause: bug firmware, protezione in scrittura del NVRAM o saturazione. Verificare se il firmware elimina le voci. In alternativa: usare il percorso removable oppure impostare manualmente l’ordine di boot nel setup UEFI del firmware.

Validazione: Come verificare se il ripristino ha avuto successo

Riavviare il sistema e utilizzare la selezione di boot del firmware per testare la nuova voce. Per la verifica nel sistema in esecuzione:

# prüft ob System im UEFI-Modus gebootet hat
[ -d /sys/firmware/efi ] && echo "UEFI boot" || echo "Legacy boot"
# efibootmgr zeigt aktive Eintraege
sudo efibootmgr -v
# prüft gültige grub.cfg
sudo test -f /boot/grub/grub.cfg && echo "grub.cfg vorhanden"

Durante il primo avvio monitorare i messaggi di sistema (journalctl -b) e pRESTare attenzione ai passaggi che falliscono durante la decrittazione del root o il montaggio dei volumi LVM.

Checklist pratica: Playbook di recovery rapido

1. Preparare una Live‑USB con l’architettura corretta (tenere conto della modalità UEFI/BIOS).
2. Backup importanti: snapshot dell’ESP, LUKS‑Header, configurazione di Grub.
3. Diagnosi: lsblk, parted, blkid, efibootmgr — verificare se l’ESP è presente e se è FAT32.
4. Montare, chroot e installazione di grub secondo la modalità target (UEFI/BIOS).
5. Rigenerare l’initramfs in caso di modifiche a LUKS/LVM/Kernel.
6. Se efibootmgr non funziona: scrivere la EFI rimovibile (BOOTX64.EFI).
7. Reboot e validazione: menu di boot del firmware, journalctl -b, controllare lo stato di LVM/LUKS.

Trappole tipiche e come evitarle

Errore 1: montare la partizione sbagliata (Windows ESP invece di Linux ESP). Evitare: usare UUID invece dei nomi dei dispositivi (blkid fornisce le UUID). Errore 2: architettura errata del file .efi (i386 vs x86_64). Evitare: usare l’immagine Live dell’architettura target. Errore 3: NVRAM piena o instabile. Evitare: tenere pronto il fallback removable.

Strategia di rollback e prevenzione

Eseguire un’azione di backup prima di ogni modifica:

# ESP als Image sichern
sudo dd if=/dev/sdX1 of=esp-backup-$(date +%F).img bs=4M status=progress
# LUKS-Header sichern
sudo cryptsetup luksHeaderBackup /dev/sdX2 --header-backup-file luks-header-$(date +%F).bin

Accesso di emergenza: Tenete a disposizione una console di rescue e un’opzione di avvio alternativa (p. es. network boot, PXE, o KVM fisica). Documentate le uscite originali di efibootmgr, in modo da poter ricostruire le voci se necessario.

Quando una reinstallazione del bootloader non è sufficiente

Ci sono casi in cui il solo ripristino di GRUB non basta: guasti hardware sul supporto di avvio, LUKS‑Header mancanti o filesystem root corrotti. In presenza di errori sul disco eseguite prima test SMART e controlli del filesystem; solo dopo aver verificato l’integrità fisica iniziate le riparazioni del bootloader.

# SMART-Test
sudo smartctl -a /dev/sda
# Dateisystemcheck ext4 (nur ungemountet)
sudo fsck.ext4 -f /dev/sdX2

Brevi note sulle differenze tra distribuzioni

Le distribuzioni usano percorsi diversi: Debian/Ubuntu utilizza /boot/grub, RedHat/CentOS /boot/grub2 e comandi diversi per generare la configurazione (update-grub vs grub2-mkconfig). Durante il lavoro in chroot prestate attenzione ai percorsi e ai pacchetti specifici della distro.

Ripristinare GRUB2: script di recovery automatizzato e audit

In ambienti di maggiori dimensioni è consigliabile uno script di recovery verificabile e idempotente che si limiti a diagnostica e preparazione dei mount — la vera installazione di grub dovrebbe essere eseguita manualmente o autorizzata tramite ticket. L’esempio seguente mostra un blocco di controllo sicuro che rileva l’ESP e la modalità e produce messaggi per il ticketing.

#!/bin/bash
set -euo pipefail
# Simple pre-checks before manual recovery actions
if [ -d /sys/firmware/efi ]; then
  echo "System already booted in UEFI mode"
else
  echo "Live-Umgebung ist Legacy/BIOS-mode"
fi
ESP=$(blkid -t PARTLABEL="EFI System" -o device || true)
if [ -z "$ESP" ]; then
  echo "Keine ESP gefunden: blkid output:"; blkid | sed -n '1,200p'
  exit 2
fi
UUID=$(blkid -s UUID -o value "$ESP")
echo "ESP device: $ESP UUID: $UUID"
# create a small audit file for ticketing
mkdir -p /var/log/grub-recovery-audit
echo "$(date -Iseconds) - ESP:$ESP UUID:$UUID UEFI:$( [ -d /sys/firmware/efi ] && echo yes || echo no)" 
  >> /var/log/grub-recovery-audit/recovery.log

Perché è utile: lo script non modifica il sistema, genera dati di diagnostica riproducibili e obbliga gli amministratori a rilasciare manualmente le fasi sensibili di installazione di grub.

Secure Boot, shim e workflow MOK

Se Secure Boot è attivo, grub‑efi può essere eseguito solo se i binari .efi sono firmati o se viene usato shim. Shim è un piccolo bootloader riconosciuto dal firmware che poi carica binari GRUB non firmati non appena una Machine Owner Key (MOK) è registrata nello store del firmware.

# MOK importieren (im installierten System oder chroot)
sudo mokutil --import /path/to/public_key.der
# reboot and enroll the key in the MOK manager during boot

Se dovete firmare i binari da soli, usate sbsign o sign-file (Kernel/GRUB). Attenzione: un workflow MOK errato può impedire totalmente l’avvio del sistema; testate sempre le modifiche prima in una VM.

Test e rollout in ambiente enterprise

Allestite linee di test: un ciclo di validazione automatizzato con qemu/kvm verifica se un ESP‑image appena creato e una grubx64.efi avviano nella simulazione del firmware. Questo riduce il rischio durante il rollout su più server.

# Beispiel: schnelles Boot-Test-Image mit qemu
qemu-system-x86_64 -m 1024 -bios /usr/share/ovmf/OVMF.fd -hda test-disk.img -boot d

Nelle grandi installazioni le modifiche di recovery dovrebbero transitare tramite gestione della configurazione e change control (p. es. Ansible Playbooks che eseguono solo controlli di validazione). Prevedete una finestra di rollback definita nel caso in cui differenze di firmware dopo l’aggiornamento producano effetti imprevisti.

Monitoraggio, alert e prevenzione

Automatizzate gli avvisi precoci: monitorate l’ultimo avvio riuscito con un agente, verificate dopo aggiornamenti del kernel se la rigenerazione dell’initramfs è avvenuta con successo e validate le voci di boot dopo aggiornamenti del firmware. Un repository con snapshot ESP facilita il ripristino rapido.

Conclusione: sistematico, sicuro, documentato

Il ripristino di GRUB2 riesce in modo affidabile se procedete in modo strutturato: prima la diagnosi, poi la riparazione mirata per UEFI o BIOS, la rigenerazione dell’initramfs per root cifrato e infine la validazione. Salvate prima di ogni intervento snapshot ESP e header LUKS. Per ambienti produttivi si raccomanda un Recovery‑Playbook definito, automazione dei test e verifiche periodiche della policy del firmware.

Se create documentazione interna: annotate UUID dei dispositivi in modo preciso, la versione del firmware e l’esatta sequenza dei passaggi eseguiti. Queste informazioni fanno risparmiare tempo nei casi ricorrenti e aiutano nell’analisi della causa principale.

Link interni di approfondimento (esempi): Collegate qui le linee guida per i backup di unità cifrate, le policy di aggiornamento del kernel o il Disaster‑Recovery‑Playbook della vostra organizzazione per garantire un flusso operativo completo.

Per questo tema sono importanti anche Uefi Bootloader Wiederherstellen e Grub-Install Anleitung. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nell’operatività quotidiana.