Proxmox « Disque non amorçable » : ordre de démarrage BIOS/UEFI, indicateurs de disque et procédure de récupération rapide

Guide de diagnostic rapide

Voici l’ordre « arrêter l’hémorragie ». Ne faites pas de freestyle. Ne réinstallez pas Proxmox comme si c’était un ordinateur portable de 2009.

1) Confirmez le mode du firmware et l’ordre de démarrage (mélange BIOS/UEFI = perte de temps n°1)

• Si la machine est en mode UEFI, vous avez besoin d’une EFI System Partition (ESP), d’une entrée de démarrage EFI et de binaires EFI fonctionnels.
• Si la machine est en mode BIOS hérité, vous avez besoin de GRUB dans le MBR (ou d’une partition BIOS boot pour GPT), et le disque doit être marqué amorçable comme le firmware l’attend.

Décision : choisissez un mode et tenez-vous-y. Les configurations de démarrage en mode mixte « fonctionnaient avant » jusqu’au jour où elles ont cessé de fonctionner — généralement juste après une réinitialisation du firmware.

2) Confirmez que le disque est détecté et que le bon disque est en premier

L’ordre de démarrage du firmware n’est pas stable. Changez un câble SATA ou ajoutez un NVMe et soudain votre disque de démarrage devient « l’autre ».

Décision : si le disque est manquant au niveau matériel, arrêtez. Ce n’est pas un problème GRUB.

3) Depuis un média de secours, validez les partitions : ESP/BIOS boot, root, et ce que Proxmox a réellement installé

Ne devinez pas. Inspectez les tables de partition, les flags et les systèmes de fichiers. Si vous êtes sur ZFS, confirmez l’import du pool.

Décision : si l’ESP est manquante ou non montée, réparez/la restaurez. Si le pool ZFS ne s’importe pas, le travail sur le chargeur d’amorçage est hors sujet tant que le stockage n’est pas sain.

4) Réparez le chargeur d’amorçage et les entrées EFI (le changement minimal pour revenir en ligne)

• UEFI : montez l’ESP, réinstallez les composants EFI, recréez les entrées NVRAM avec efibootmgr si nécessaire.
• BIOS : réinstallez GRUB sur le bon disque et régénérez la configuration.

Décision : ne réinstallez pas Proxmox à moins que votre partition OS soit réellement perdue ou irrémédiablement corrompue.

5) Rendez le démarrage redondant (pour que cela ne devienne pas une réunion récurrente)

Les entrées UEFI et les ESP peuvent être des points de défaillance uniques même sur des miroirs ZFS. Corrigez cela après que le nœud ait démarré, pas avant.

Une idée paraphrasée souvent citée en SRE : « L’espoir n’est pas une stratégie ». Utilisez des checklists, pas l’intuition.

Ce que signifie réellement « disque non amorçable »

Le message est une plainte du firmware, pas de Proxmox. Il signifie que le firmware système a tenté ses cibles de démarrage configurées et n’a pas trouvé ce qu’il considère comme amorçable.

Où la chaîne échoue

1. Détection matérielle : le firmware voit-il le disque ?
2. Sélection de démarrage du firmware : tente-t-il le bon disque et le bon mode (UEFI vs hérité) ?
3. Emplacement du code de démarrage :
   • Legacy BIOS : MBR/secteur de boot → GRUB stage1 → image core de GRUB → /boot/grub
   • UEFI : entrée NVRAM → ESP FAT32 → binaire EFI (shim/grub/systemd-boot) → kernel/initramfs
4. Transfert au système : le noyau monte le filesystem root ; sur ZFS il peut importer le pool tôt.

La plupart des incidents Proxmox « non amorçable » sont l’un de ces cas :

• Le firmware s’est silencieusement réinitialisé aux valeurs par défaut (modifiant souvent le comportement UEFI/legacy).
• L’ordre de démarrage a changé après ajout/retrait de disques.
• L’ESP a été écrasée, non montée, ou créée sur un seul disque d’un miroir.
• GRUB installé sur le mauvais périphérique (commun après remplacement de disque).
• Entrées NVRAM UEFI effacées (mise à jour du firmware, réinitialisation CMOS, quelques outils de gestion à distance).

Blague n°1 : L’ordre de démarrage du firmware ressemble à la disposition des bureaux : vous pouvez être « la personne importante » jusqu’à ce que les Services déplacent une plante.

Faits intéressants et contexte historique (parce que le passé continue de briser votre présent)

• Le BIOS est antérieur à votre carrière : les conventions IBM PC BIOS datent du début des années 1980, et une bonne partie de la « magie de démarrage » est encore du ruban adhésif rétrocompatible.
• UEFI était conçu pour remplacer le BIOS : il a formalisé le démarrage comme le chargement de binaires EFI depuis un système de fichiers FAT, pas depuis des secteurs opaques.
• GPT vs MBR n’est pas qu’une question de nombre de partitions : GPT s’accorde naturellement avec UEFI, tandis que le démarrage BIOS depuis GPT nécessite une partition « BIOS boot » dédiée pour GRUB.
• L’ESP n’est qu’un FAT32 : votre « hôte de virtualisation haute disponibilité » démarre souvent depuis un système de fichiers conçu pour les appareils photo et les clés USB.
• Les entrées NVRAM sont fragiles : les mises à jour du firmware, réinitialisations CMOS, et parfois des coupures de courant peuvent les effacer, même si les disques sont parfaits.
• Secure Boot a changé les attentes : les machines activent de plus en plus Secure Boot par défaut ; les déploiements Proxmox désactivent souvent cette option sauf s’ils gèrent une chaîne de démarrage signée.
• Les chargeurs d’amorçage Linux ont évolué : LILO a cédé la place à GRUB, puis GRUB2 ; chacun a apporté plus de flexibilité tout en créant de nouvelles façons de mal configurer l’environnement de démarrage.
• Le démarrage ZFS est « supporté », pas « simplifié » : ZFS ajoute de la fiabilité pour les données, mais le démarrage dépend encore de petites pièces non-ZFS : ESPs, GRUB, modules initramfs.
• Le nommage des périphériques n’est pas stable : /dev/sda aujourd’hui peut devenir /dev/sdb demain après des changements de HBA ; la pratique moderne privilégie les chemins by-id pour de bonnes raisons.

Tâches pratiques : commandes, ce que signifie la sortie, et la décision à prendre

Ce sont des tâches de terrain à exécuter depuis un shell Proxmox, un live ISO Debian, ou l’installeur Proxmox en mode rescue (là où disponible). L’objectif est de passer de « ne démarre pas » à « je sais exactement quelle couche a échoué ».

Task 1: Confirm whether you booted the rescue environment in UEFI or BIOS mode

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Signification : Si ceci affiche UEFI, votre session de secours est en UEFI. Cela doit correspondre au mode dans lequel vous avez l’intention que le nœud démarre.

Décision : Si la machine démarrait auparavant en BIOS hérité et que vous êtes maintenant en UEFI (ou inversement), corrigez les réglages du firmware avant de toucher aux disques.

Task 2: See what disks the OS can see (hardware sanity check)

cr0x@server:~$ lsblk -e7 -o NAME,SIZE,MODEL,SERIAL,TYPE,FSTYPE,MOUNTPOINTS
NAME      SIZE MODEL            SERIAL           TYPE FSTYPE MOUNTPOINTS
sda     447.1G INTEL SSDSC2KB   BTWL1234567      disk
├─sda1    512M                  -                part vfat
├─sda2   1007K                  -                part
└─sda3  446.6G                  -                part zfs_member
sdb     447.1G INTEL SSDSC2KB   BTWL7654321      disk
├─sdb1    512M                  -                part vfat
├─sdb2   1007K                  -                part
└─sdb3  446.6G                  -                part zfs_member

Signification : Les disques sont visibles, des partitions existent, et vous pouvez déjà repérer une ESP (vfat) et des membres ZFS.

Décision : Si votre disque de démarrage n’apparaît pas du tout, arrêtez et corrigez le câblage/HBA/détection BIOS. Le travail sur le chargeur d’amorçage n’invoquera pas du matériel manquant.

Task 3: Identify how the disk is partitioned (GPT vs MBR) and whether an ESP exists

cr0x@server:~$ parted -l
Model: ATA INTEL SSDSC2KB (scsi)
Disk /dev/sda: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
 1      1049kB  538MB  537MB  fat32              boot, esp
 2      538MB   539MB  1049kB                   bios_grub
 3      539MB   480GB  479GB

Model: ATA INTEL SSDSC2KB (scsi)
Disk /dev/sdb: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
 1      1049kB  538MB  537MB  fat32              boot, esp
 2      538MB   539MB  1049kB                   bios_grub
 3      539MB   480GB  479GB

Signification : Disques GPT avec esp et bios_grub sont courants dans les installations Proxmox cherchant la flexibilité. Le flag ESP est l’élément important pour le démarrage UEFI.

Décision : S’il n’y a pas d’ESP (boot, esp) mais que le serveur est en mode UEFI, vous avez trouvé la source du problème.

Task 4: Check the filesystem integrity of the ESP (it’s FAT; treat it like it’s 1998)

cr0x@server:~$ fsck.vfat -n /dev/sda1
fsck.fat 4.2 (2021-01-31)
/dev/sda1: 12 files, 1646/130560 clusters

Signification : Vérification en lecture seule passée ; pas de corruption FAT évidente.

Décision : Si vous voyez des erreurs FAT, prévoyez de réparer (-a) ou de recréer l’ESP et de réinstaller les fichiers EFI.

Task 5: Mount the ESP and verify EFI binaries exist

cr0x@server:~$ mkdir -p /mnt/esp && mount /dev/sda1 /mnt/esp && find /mnt/esp/EFI -maxdepth 2 -type f | sed -n '1,10p'
/mnt/esp/EFI/BOOT/BOOTX64.EFI
/mnt/esp/EFI/proxmox/grubx64.efi
/mnt/esp/EFI/debian/grubx64.efi

Signification : Les fichiers existent ; il y a un chemin de repli EFI/BOOT/BOOTX64.EFI et des chemins fournisseur.

Décision : Si /mnt/esp/EFI est vide ou manquant, réinstallez le chargeur d’amorçage et envisagez de créer le chemin de repli.

Task 6: Inspect UEFI NVRAM boot entries (the firmware “bookmark list”)

cr0x@server:~$ efibootmgr -v
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0002,0001,0000
Boot0000* UEFI: PXE IPv4 Intel(R) I350
Boot0001* UEFI: Built-in EFI Shell
Boot0002* proxmox	HD(1,GPT,2b0c3f1a-9b2f-4a7e-9d64-3f3c3a0e2f21,0x800,0x100000)/File(\EFI\proxmox\grubx64.efi)

Signification : Il existe une entrée Proxmox et elle est en première position. Parfait — sauf si elle pointe vers le mauvais disque/UUID de partition.

Décision : S’il n’y a pas d’entrée Proxmox, ou si elle pointe vers un disque mort, recréez-la avec efibootmgr après avoir vérifié l’ESP correct.

Task 7: Import ZFS pool from rescue and confirm it’s healthy enough to boot

cr0x@server:~$ zpool import
   pool: rpool
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

	rpool        ONLINE
	  mirror-0    ONLINE
	    sda3      ONLINE
	    sdb3      ONLINE

Signification : Le pool root existe et est importable.

Décision : Si le pool est DEGRADED, vous pouvez souvent toujours démarrer, mais traitez la réparation du boot comme une occasion de rétablir la redondance aussi.

Task 8: Mount the installed system and prepare for chroot repair

cr0x@server:~$ zpool import -R /mnt rpool
cr0x@server:~$ zfs mount -a
cr0x@server:~$ mount | grep -E '(/mnt|rpool)' | sed -n '1,8p'
rpool/ROOT/pve-1 on /mnt type zfs (rw,relatime,xattr,posixacl)
rpool/data on /mnt/rpool/data type zfs (rw,relatime,xattr,posixacl)

Signification : Votre dataset root est monté sur /mnt.

Décision : Si les montages échouent, ne procédez pas à la réinstallation de GRUB. Réparez d’abord l’import/montage ZFS.

Task 9: Bind-mount runtime filesystems and chroot

cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do mount --bind $i /mnt$i; done
cr0x@server:~$ chroot /mnt /bin/bash
root@server:/# cat /etc/os-release | head -2
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"

Signification : Vous êtes dans l’environnement OS installé ; les outils de chargeur d’amorçage se comporteront correctement.

Décision : Si chroot échoue à cause de binaires manquants, votre filesystem root n’est pas ce que vous pensez.

Task 10 (UEFI): Ensure ESP is mounted at /boot/efi and reinstall GRUB EFI

root@server:/# mkdir -p /boot/efi
root@server:/# mount /dev/sda1 /boot/efi
root@server:/# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=proxmox
Installing for x86_64-efi platform.
Installation finished. No error reported.

Signification : Les binaires GRUB EFI ont été installés dans l’ESP sous le label proxmox.

Décision : Si l’opération renvoie une erreur du type « EFI variables not supported », vous avez probablement démarré l’environnement de secours en mode BIOS. Redémarrez le secours en UEFI.

Task 11 (UEFI): Regenerate GRUB menu and initramfs

root@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-2-pve
Found initrd image: /boot/initrd.img-6.8.12-2-pve
done
root@server:/# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-2-pve

Signification : Le menu de GRUB pointe vers de vrais noyaux ; initramfs est reconstruit.

Décision : Si les noyaux ne sont pas trouvés, vous êtes peut-être chrooté dans le mauvais dataset root ou /boot n’est pas monté correctement.

Task 12 (UEFI): Recreate a missing NVRAM entry

root@server:/# efibootmgr -c -d /dev/sda -p 1 -L "proxmox" -l '\EFI\proxmox\grubx64.efi'
BootCurrent: 0002
BootOrder: 0002,0001,0000,0003
Boot0003* proxmox	HD(1,GPT,2b0c3f1a-9b2f-4a7e-9d64-3f3c3a0e2f21,0x800,0x100000)/File(\EFI\proxmox\grubx64.efi)

Signification : Vous avez créé une nouvelle entrée. Elle n’est peut‑être pas encore en première position.

Décision : Définissez BootOrder pour que proxmox soit premier, ou tenez-vous au chargeur de repli comme sécurité supplémentaire.

Task 13 (BIOS): Reinstall GRUB to the disk MBR (or BIOS boot area)

root@server:/# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
root@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.12-2-pve
Found initrd image: /boot/initrd.img-6.8.12-2-pve
done

Signification : GRUB hérité installé sur /dev/sda.

Décision : Si vous êtes sur un miroir, installez GRUB sur chaque disque membre susceptible d’être démarré.

Task 14: Verify GRUB sees the right root and doesn’t reference /dev/sdX names

root@server:/# grep -R "root=" /boot/grub/grub.cfg | sed -n '1,5p'
linux	/boot/vmlinuz-6.8.12-2-pve root=ZFS=rpool/ROOT/pve-1 ro quiet

Signification : Le root est référencé via un dataset ZFS, pas par des chemins de périphériques instables.

Décision : Si vous voyez root=/dev/sda3 sur des systèmes où les noms peuvent changer, corrigez /etc/default/grub et régénérez.

Task 15: Build a fallback EFI path (because NVRAM isn’t to be trusted)

root@server:/# mkdir -p /boot/efi/EFI/BOOT
root@server:/# cp -f /boot/efi/EFI/proxmox/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI
root@server:/# ls -l /boot/efi/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 1536000 Dec 26 11:11 /boot/efi/EFI/BOOT/BOOTX64.EFI

Signification : Même si le firmware oublie les entrées NVRAM, il peut souvent démarrer le chemin par défaut.

Décision : Faites cela sur chaque ESP dont vous attendez qu’elle puisse démarrer.

Task 16: After reboot, confirm the system actually booted via the intended mode

cr0x@server:~$ dmesg | grep -i "efi\|UEFI" | sed -n '1,6p'
[    0.000000] efi: EFI v2.70 by American Megatrends
[    0.000000] efi: ACPI=0x9bfe6000 ACPI 2.0=0x9bfe6014 SMBIOS=0x9c01c000

Signification : Le noyau voit EFI ; vous êtes en démarrage UEFI.

Décision : Si vous vouliez un démarrage hérité et que vous voyez EFI, vous êtes revenu au « mode mixte » ; corrigez cela avant la prochaine fenêtre de maintenance qui vous surprendra à nouveau.

UEFI vs BIOS : choisir la bonne voie de récupération

La règle la plus simple

Si la machine est capable d’UEFI (la plupart le sont), préférez UEFI pour les nouvelles installations. Mais ne « convertissez » pas en plein incident sauf si vous aimez les temps d’arrêt surprises. Récupérez dans le mode où le système a été installé, puis planifiez une migration contrôlée si nécessaire.

Comment Proxmox organise typiquement les choses

Proxmox VE repose sur Debian. L’installateur créera des partitions pour :

• ESP (généralement 512 Mo FAT32) lors de l’utilisation d’UEFI.
• bios_grub petite partition (environ 1 Mo) en cas de démarrage BIOS depuis GPT, pour que GRUB puisse s’y intégrer.
• Filesystem root sur ext4, LVM ou ZFS (commun dans les déploiements Proxmox modernes).

Modes de panne UEFI qui ressemblent à « disque non amorçable »

• ESP existe mais n’est pas utilisé : l’ordre de démarrage pointe sur PXE ou un placeholder « UEFI: USB » au-dessus de votre disque.
• Entrée NVRAM manquante : le firmware a oublié votre entrée Proxmox. Le disque est intact ; la mémoire du firmware ne l’est pas.
• Mauvais chemin disque dans la NVRAM : vous avez remplacé un disque miroir et l’entrée de démarrage pointe toujours vers l’ancien GUID de partition.
• ESP uniquement sur un disque : un miroir ZFS protège vos données, mais vous n’avez qu’une seule ESP. Perdez ce disque, vous perdez le démarrage.

Modes de panne BIOS qui ressemblent à « disque non amorçable »

• GRUB installé sur le mauvais disque : le système démarre depuis le premier disque dans l’ordre BIOS, mais GRUB est sur le second.
• MBR écrasé : une opération de clonage, un installateur, ou un outil « utile » du fournisseur a écrasé le secteur de démarrage.
• GPT sans bios_grub : GRUB hérité ne peut pas intégrer correctement son image core.

Blague n°2 : Le BIOS ne vous déteste pas. Il montre juste son affection en ignorant vos trois derniers changements de configuration.

Proxmox + ZFS : où la redondance de démarrage aide, et où elle ne suffit pas

ZFS rend le stockage root robuste. Il ne rend pas automatiquement le démarrage robuste. Votre miroir ZFS peut continuer à fournir des blocs parfaits tandis que votre firmware regarde une liste NVRAM vide comme s’il ne connaissait pas votre serveur.

Ce que ZFS protège

• Datasets root, disques de VM stockés sur le pool, cohérence des métadonnées, et détection de la corruption silencieuse.
• Récupération opérationnelle : remplacer un disque défaillant, resilver, continuer à fonctionner.

Ce que ZFS ne protège pas

• L’ESP, sauf si vous avez créé des ESP sur plusieurs disques et les avez maintenues synchronisées.
• Les entrées NVRAM UEFI, car elles vivent dans le firmware, pas sur disque.
• L’ordre de démarrage du firmware, car c’est un réglage firmware qui se réinitialisera au pire moment.

Ce que vous devriez faire sur des disques de démarrage en miroir

Si vous avez deux disques et que vous souhaitez survivre à la perte de l’un ou l’autre, vous avez besoin de deux chemins amorçables :

• Deux ESP (une par disque) et un plan pour les garder cohérentes.
• Entrées UEFI pour les deux, ou un chargeur de repli robuste dans EFI/BOOT/BOOTX64.EFI sur les deux.
• Si vous démarrez en BIOS hérité : GRUB installé sur les deux disques.

Dans les environnements Proxmox, l’approche pragmatique est : ESP par disque + chargeur de repli + vérification périodique des dérives. Le reste est optionnel.

Erreurs courantes (symptôme → cause → correctif)

1) Symptom: “No bootable device” after a firmware update

Cause : Les entrées NVRAM UEFI ont été effacées ou réordonnées ; PXE ou « UEFI Shell » est passé devant.

Correctif : Utilisez les paramètres firmware pour sélectionner l’entrée UEFI correcte. Si elle manque, recréez-la avec efibootmgr depuis un rescue et copiez BOOTX64.EFI en repli.

2) Symptom: Boots only when a specific disk is present (mirror exists, but one disk is “special”)

Cause : Un seul disque a une ESP ou seul un disque a GRUB installé.

Correctif : Créez une ESP sur l’autre disque, montez-la, installez GRUB EFI dessus (ou GRUB BIOS sur le disque), puis ajoutez le chemin de repli.

3) Symptom: “EFI variables are not supported” during repair

Cause : Vous avez démarré le média de secours en mode BIOS, donc efivars n’est pas disponible.

Correctif : Redémarrez l’ISO live/installeur en mode UEFI et répétez l’installation GRUB EFI.

4) Symptom: GRUB loads, then drops to “grub rescue>”

Cause : GRUB ne trouve pas ses modules ou sa configuration à cause de partitions déplacées, UUID modifiés, ou /boot ailleurs que prévu.

Correctif : Depuis le rescue, chrooter et relancer grub-install + update-grub. Vérifiez /etc/fstab et que l’ESP est montée correctement.

5) Symptom: “Not a bootable disk” right after adding a new disk

Cause : L’ordre de démarrage a changé ; le firmware essaye maintenant le nouveau disque en premier. Certains HBA réordonnent aussi les disques.

Correctif : Réordonnez les cibles de démarrage ; désactivez le démarrage depuis les disques non-OS si le firmware le permet.

6) Symptom: Works after manual boot selection, fails on the next reboot

Cause : Le firmware a appliqué une option de démarrage ponctuelle mais pas l’ordre permanent ; ou vos réglages ne se sauvegardent pas à cause d’une pile CMOS faible.

Correctif : Définissez un ordre de démarrage persistant ; vérifiez les logs BIOS ; remplacez la pile CMOS si les réglages se dérèglent.

7) Symptom: After disk replacement, system won’t boot but ZFS pool looks fine

Cause : Le nouveau disque n’a pas d’ESP/bootloader, ou l’entrée NVRAM pointe vers l’ancien GUID de partition.

Correctif : Partitionnez le nouveau disque correctement, créez une ESP, installez GRUB, mettez à jour les entrées efiboot et ajoutez le chargeur de repli.

8) Symptom: Secure Boot complaints or “invalid signature”

Cause : Secure Boot activé mais votre chaîne de démarrage n’est pas signée de manière acceptée par le firmware.

Correctif : Désactivez Secure Boot pour les déploiements Proxmox typiques sauf si vous avez une chaîne de démarrage signée et gérée.

Listes de contrôle / plan étape par étape

Checklist A: What to collect before you start changing things

1. Le nœud a-t-il été installé en mode UEFI ou BIOS ?
2. Quelque chose a-t-il changé ? Mise à jour du firmware, remplacement de disque, nouveau HBA, déplacement de câbles, coupure de courant, intervention distante ?
3. Avez-vous un accès console (iKVM/IDRAC/iLO) ou seulement SSH (probablement pas) ?
4. Quel est le layout de stockage : miroir ZFS, RAIDZ ZFS, ext4, LVM-thin ?
5. Quel disque doit être amorçable ? Identifiez-le par numéro de série, pas par /dev/sdX.

Checklist B: Minimal recovery (UEFI)

1. Démarrez le média de secours en mode UEFI.
2. Confirmez la visibilité des disques avec lsblk.
3. Vérifiez que l’ESP existe et est en FAT32 avec parted -l.
4. Importez le pool ZFS (si applicable) et montez root sur /mnt.
5. Bind-montez /dev, /proc, /sys, /run et chroot.
6. Montez l’ESP sur /boot/efi.
7. Lancez grub-install --target=x86_64-efi et update-grub.
8. Créez/vérifiez l’entrée NVRAM avec efibootmgr.
9. Copiez le chargeur de repli dans EFI/BOOT/BOOTX64.EFI.
10. Redémarrez et vérifiez le mode de démarrage via dmesg.

Checklist C: Minimal recovery (legacy BIOS)

1. Démarrez le média de secours (le mode importe moins, mais soyez cohérent).
2. Confirmez la présence des disques et le partitionnement ; si GPT, assurez-vous que bios_grub existe.
3. Montez le filesystem root (ou importez ZFS) et chrootez.
4. Exécutez grub-install /dev/sdX sur le disque correct.
5. Exécutez update-grub.
6. Si miroir, répétez grub-install sur l’autre(s) disque(s).
7. Réglez l’ordre de démarrage BIOS sur un disque qui a réellement GRUB.

Checklist D: Post-recovery hardening (do this while you still remember the pain)

1. Rendez les ESP redondantes sur les disques de démarrage en miroir.
2. Notez le mode de démarrage firmware et les réglages BIOS requis dans des runbooks.
3. Désactivez le démarrage depuis les disques de données et les médias amovibles aléatoires dans le firmware.
4. Après tout remplacement de disque, réinstallez le chargeur d’amorçage sur le nouveau disque comme étape standard.
5. Ajoutez une tâche périodique « audit de la chaîne de démarrage » (contenu des ESP + sortie efibootmgr + statut grub-install).

Trois mini-récits d’entreprise depuis les tranchées des pannes de démarrage

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils avaient un cluster Proxmox où chaque nœud était « identique ». « Identique » est un mot dangereux en production parce qu’il encourage à ne plus observer. Un nœud a refusé de démarrer après une panne planifiée : « not a bootable disk ». L’intervention a supposé une défaillance disque et un ticket a été ouvert pour un remplacement. Raisonnable, sauf que les disques allaient bien.

La vraie cause était une réinitialisation du firmware pendant la maintenance. Le serveur est passé du BIOS hérité à UEFI-first, et le système installé était en legacy. Les disques étaient en GPT avec une partition BIOS boot, et GRUB était correctement installé pour i386-pc. Mais le firmware ne regardait que les binaires UEFI sur une ESP inexistante.

La récupération a été presque insultante par sa simplicité : remettre le firmware en legacy, redémarrer, et le nœud revient. L’« incident » n’était pas une corruption de stockage ou une mise à jour OS. C’était un décalage de réglages créé par l’hypothèse que « UEFI est partout ».

Ce qui a changé ensuite, c’est le processus, pas la technologie. Ils ont ajouté un profil matériel d’une page par nœud : mode de démarrage, état Secure Boot, mode RAID/HBA, et le numéro de série du disque de démarrage attendu. Ce n’était pas glamour. Ça a aussi empêché une répétition.

Mini-récit 2 : L’optimisation qui a se retournée contre eux

Une autre équipe voulait des temps de démarrage plus rapides après les mises à jour du noyau. Ils ont réduit ce qu’ils considéraient comme des artefacts « en trop » au démarrage. L’ESP a été réduite à quelque chose de minuscule, et ils ont supprimé les fichiers EFI de repli parce que « nous avons déjà une entrée NVRAM correcte ». Ils ont aussi standardisé sur une ESP unique sur le premier disque d’un miroir ZFS, parce que maintenir deux leur semblait « gaspillage ».

Puis un disque est tombé en panne. ZFS a fait son travail ; le pool est resté en ligne. Ils ont remplacé le disque, resilvered, et planifié un redémarrage pour valider. Au redémarrage, le firmware a essayé de démarrer depuis le disque restant (maintenant premier aux yeux du firmware) et n’a pas trouvé de chemin EFI valide. La seule ESP était sur le disque retiré. Le chemin de repli avait été supprimé lors de l’optimisation.

Le temps d’indisponibilité n’a pas été catastrophique, mais il était inutile. La majeure partie du temps a été dépensée à obtenir un accès console distant et à monter des médias, pas à réparer le logiciel. La solution a été une stratégie ESP miroir correcte et la réintégration du binaire EFI de repli par défaut.

La leçon n’était pas « ne jamais optimiser ». C’était que la résilience du démarrage est une propriété système, pas une propriété disque. La redondance ZFS ne couvre pas l’amnésie du firmware ni l’absence d’artefacts de démarrage sur le périphérique survivant.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une entreprise avait une habitude qui paraissait excessive : après tout remplacement de disque sur un hôte Proxmox, la procédure incluait la réinstallation des chargeurs d’amorçage et la vérification des deux chemins de démarrage. À chaque fois. Sans exception. C’était le genre d’étape qui fait lever les yeux au ciel — jusqu’à ce que ça paie.

Un weekend, un nœud a perdu l’alimentation, puis a refusé de démarrer. La console montrait le firmware qui scannait les disques puis abandonnait. L’astreinte a suivi le playbook : vérifier le mode UEFI, inspecter les ESP sur les deux disques, et contrôler efibootmgr. Les entrées NVRAM avaient disparu, probablement effacées par un bug firmware durant la reprise d’alimentation.

Normalement, cela aurait impliqué de reconstruire manuellement les entrées. Mais leur pratique ennuyeuse incluait la copie d’un chargeur de repli dans EFI/BOOT/BOOTX64.EFI sur les deux ESP. Le firmware, ayant tout oublié, connaissait toujours le chemin par défaut. Il a démarré sans que personne touche à la NVRAM.

Ils ont restauré ensuite les entrées correctes, mais le point clé est que la récupération s’est produite rapidement, sans accès spécial et sans hypothèses. Ce n’était pas de l’héroïsme. C’était une discipline routinière qui a rendu le système moins dramatique.

FAQ

1) Est-ce que « disque non amorçable » est généralement un disque mort ?

Non. Les disques morts existent, mais la réalité courante est un ordre de démarrage firmware ou un mauvais mode. Confirmez d’abord la détection du disque, puis le mode de démarrage.

2) Puis-je résoudre cela en réinstallant Proxmox ?

Vous pouvez, mais vous ne devriez pas. Réinstaller est un instrument brut qui risque d’effacer le stockage ou de rompre les attentes du cluster. Réparez d’abord le démarrage ; c’est plus rapide et plus sûr si c’est fait correctement.

3) Comment savoir si Proxmox a été installé en mode UEFI ?

Si le système installé a /sys/firmware/efi lorsqu’il fonctionne, il a démarré en UEFI. Sur disque, cherchez une ESP (FAT32, flag esp).

4) Pourquoi remplacer un disque dans un miroir ZFS casse-t-il le démarrage ?

ZFS réplique vos partitions de données, pas automatiquement votre ESP ni les entrées de firmware. Si l’ESP ou le chargeur d’amorçage était uniquement sur le disque retiré, le disque restant ne démarrera pas seul.

5) Ai-je besoin à la fois d’une ESP et d’une partition bios_grub ?

Pas toujours. UEFI a besoin d’une ESP. Le démarrage BIOS depuis GPT bénéficie d’une partition bios_grub. Certains installateurs créent les deux pour la flexibilité. L’essentiel : le mode de démarrage actif doit disposer des éléments requis.

6) Quel est le moyen le plus rapide pour « juste démarrer quelque chose » si les entrées NVRAM sont cassées ?

Créez le chemin de repli EFI/BOOT/BOOTX64.EFI sur l’ESP. De nombreuses implémentations firmware le démarreront même avec une NVRAM vide.

7) Dois-je activer Secure Boot sur Proxmox ?

Si vous n’avez pas une chaîne de démarrage signée planifiée et testée, Secure Boot tend à créer des échecs de démarrage lors des mises à jour ou des réparations. Beaucoup de déploiements Proxmox le désactivent délibérément.

8) Pourquoi grub-install indique-t-il « EFI variables are not supported » ?

Parce que vous n’êtes pas démarré en mode UEFI (ou efivars n’est pas disponible). Démarrez le média de secours en mode UEFI pour que /sys/firmware/efi existe et réessayez.

9) Dois-je réinstaller GRUB après chaque mise à jour du noyau ?

Généralement non. Les mises à jour du noyau régénèrent automatiquement la configuration GRUB et initramfs. Réinstallez GRUB lorsque les disques changent, que les ESP sont reconstruites, ou que des fichiers du chargeur ont disparu.

10) Puis-je garder les entrées de démarrage stables malgré des changements matériels ?

Une certaine stabilité vient de l’utilisation des GUID de partition corrects et du maintien des ESP cohérentes, mais le comportement firmware varie. C’est pourquoi les chargeurs de repli et les ESP redondantes sont pratiques.

Conclusion : étapes pratiques suivantes

Si vous regardez « not a bootable disk », traitez-le comme un incident à la frontière firmware/boot, pas comme une invitation à réinstaller l’OS. Commencez par le mode et l’ordre. Inspectez ensuite les partitions et le contenu des ESP. Ce n’est qu’après que vous devriez réinstaller GRUB ou recréer des entrées EFI. Cette séquence évite les deux pièges classiques : réparer la mauvaise couche, et « réparer » un système en le basculant dans un mode de démarrage différent sans le vouloir.

Une fois remis en ligne, faites le durcissement ennuyeux : rendez les ESP redondantes sur les disques en miroir, copiez un chargeur EFI de repli, et documentez les réglages firmware attendus pour chaque nœud. Le prochain redémarrage devrait être ennuyeux. La production aime l’ennui.