In questo articolo descrivo un caso reale di malfunzionamento EFI su un nodo Proxmox, dove il sistema avviava dalla partizione sbagliata invece che dalla ESP corretta. Questo causava avvii incoerenti, kernel non aggiornati e potenziali rischi di boot failure.
## Sintomi del problema
Il comando `efibootmgr -v` mostrava:
- BootCurrent: 0003 → avvio da fallback `BOOTX64.EFI`
- BootOrder: `0003,0004,0002,0000`
- Due ESP presenti:
- **CE60** (GUID `0c569779-e73f-4c73-b97f-e8594cb4868d`)
- **11A4** (GUID `40e24607-4ca2-4f4a-926c-7792a0f3dc72`)
La ESP corretta (CE60) conteneva:
- `Boot0002` → systemd‑boot (entry primaria)
- `Boot0004` → fallback `BOOTX64.EFI`
La ESP secondaria (11A4) conteneva:
- `Boot0000` → systemd‑boot
- `Boot0003` → fallback `BOOTX64.EFI`
Il problema era chiaro: il BIOS avviava dalla entry `0003`, cioè dalla fallback della ESP sbagliata.
## Analisi tecnica
Proxmox utilizza **systemd‑boot** e sincronizza i kernel nella ESP montata in `/boot/efi`.
La partizione corretta era **CE60**, ma il BootOrder dava priorità alla fallback `0003`, portando il sistema a caricare `BOOTX64.EFI` invece dei kernel aggiornati.
## Soluzione
La soluzione è stata correggere l’ordine di boot, impostando:
1. `Boot0002` → CE60 systemd‑boot (primaria)
2. `Boot0004` → CE60 fallback
3. `Boot0003` → 11A4 fallback
4. `Boot0000` → 11A4 systemd‑boot
Comando utilizzato:
```bash
efibootmgr -o 0002,0004,0003,0000
Verifica dopo il riavvio
Dopo il reboot:
BootCurrent: 0002→ avvio corretto dalla ESP CE60BootOrder: 0002,0004,0003,0000→ ordine sicuro e coerente
Il nodo ora avvia correttamente dalla ESP principale, con fallback attivi e una catena di sicurezza completa.
Conclusione
Il problema era causato da un BootOrder errato che privilegiava una fallback EFI invece della ESP principale. Correggendo l’ordine con efibootmgr, Proxmox torna a utilizzare i kernel aggiornati e garantisce un avvio stabile e sicuro. Questa procedura è utile in tutti i casi in cui Proxmox presenta avvii incoerenti o fallback EFI attivi come primaria.