GPT vs MBR : se tromper casse le démarrage — suivez cette règle

février 11, 2026 • février 11, 2026 • Lecture : 28 min • Views: 0

Cet article vous a aidé ?

Il y a peu de sensations en exploitation aussi pures que celle que vous ressentez quand une machine redémarre sur un écran noir parce que quelqu’un « a juste redimensionné une partition ». Les données sont intactes. Les disques sont intacts. Le système ne démarre pas parce que vous avez choisi le mauvais schéma de partition pour le firmware et le chemin de démarrage.

C’est le type de panne qui ressemble à un problème de stockage, donne l’impression d’un problème de chargeur de démarrage et qui est en réalité un problème de décision. La bonne nouvelle : vous pouvez arrêter de deviner. Il existe une règle simple pour choisir GPT vs MBR qui évite la plupart des désastres de démarrage — plus un ensemble de vérifications qui vous disent exactement à quoi vous avez affaire avant de toucher quoi que ce soit.

La règle : ne « choisissez » pas, alignez firmware et mode de démarrage

Règle empirique qui vous évite des ennuis :

Si la machine démarre en mode UEFI, utilisez GPT. Créez une partition EFI System (ESP) et installez le chargeur de démarrage là‑dedans.
Si la machine démarre en mode BIOS legacy, utilisez MBR. Ou utilisez GPT avec une partition BIOS boot si vous savez exactement pourquoi vous le faites (plus d’explications ci‑dessous).

Cette règle n’est pas idéologique. Il s’agit d’aligner le premier code exécutable que votre firmware s’attend à trouver avec la disposition sur le disque. Quand ces deux éléments ne correspondent pas, vous n’obtenez pas « un avertissement ». Vous obtenez « aucun périphérique amorçable », GRUB rescue, ou une invite de récupération Windows qui fait comme si elle n’avait jamais rencontré votre OS.

Il y a une contrainte supplémentaire qui compte encore plus que la préférence personnelle : si le disque fait plus de 2 To et que vous devez utiliser tout l’espace sur un seul disque, MBR est exclu. Vous pouvez toujours démarrer BIOS depuis un disque GPT, mais cela doit être fait intentionnellement.

Vérité sèchement drôle : les tables de partition sont comme des parachutes — vous ne les remarquez généralement que lorsqu’elles échouent.

Ce qui casse réellement quand vous vous trompez

Le « démarrage » n’est pas une chose unique. C’est une chaîne. Différents maillons cassent selon la combinaison de firmware, schéma de partition, OS et chargeur de démarrage.

MBR : ce qu’il attend

Le démarrage MBR attend typiquement :

Le LBA0 du disque contient un MBR valide avec du code d’amorçage exécutable et une table de partitions.
Une partition marquée « active/bootable » (pour les flux BIOS classiques).
Du code d’amorçage qui charge un second stade depuis un emplacement connu (par ex. fichiers de GRUB ou gestionnaire de démarrage Windows).

Si vous clonez un disque GPT sur un disque MBR (ou l’inverse) et oubliez le code d’amorçage, vous pouvez copier 100 % de vos fichiers parfaitement et avoir quand même une chaîne de démarrage morte.

GPT : ce qu’il attend

Le démarrage GPT dépend du firmware :

UEFI + GPT : le firmware lit le GPT, trouve l’ESP (FAT32), charge un exécutable EFI depuis un chemin enregistré dans la NVRAM ou via des chemins de secours.
BIOS + GPT : le BIOS ne peut pas lire les partitions GPT de la même manière ; GRUB utilise une petite partition BIOS boot pour y stocker des données d’image core.

Si vous vous trompez, vous n’obtenez pas un « léger dysfonctionnement ». Vous obtenez « le firmware ne trouve pas le chargeur », ce qui ressemble à une corruption de stockage pour quiconque ne suit pas la chaîne de démarrage attentivement.

Une citation pour rester lucide : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan. Ce n’est pas à l’origine une citation d’ops, mais elle est exacte en exploitation tous les jours.

Faits et histoire utiles pour prendre des décisions

Ce ne sont pas des anecdotes de quiz. Elles expliquent pourquoi les outils se comportent comme ils le font et pourquoi certaines partitions « bizarres » existent.

Le MBR date de l’ère PC ancienne et utilise un adressage 32 bits pour le comptage de secteurs, d’où la limite classique autour de 2 To avec des secteurs de 512 octets.
Le GPT a été défini dans la spécification UEFI pour remplacer le MBR, pas seulement « l’étendre ». Il est destiné aux firmwares modernes et aux gros disques.
Le GPT conserve un en‑tête de secours et un tableau de partitions à la fin du disque. Ce n’est pas théorique. Quand l’en‑tête primaire est écrasé par un mauvais clone, on peut souvent récupérer depuis la sauvegarde.
Le GPT inclut des CRCs pour ses en‑têtes et entrées de partition. Les outils peuvent détecter la corruption au lieu de continuer silencieusement avec des données inconséquentes.
Le « protective MBR » existe sur les disques GPT pour que les utilitaires MBR‑only ne voient pas le disque comme « vide » et ne l’écrasent pas. C’est à la fois une mine et une sécurité de compatibilité.
UEFI ne « démarre pas une partition », il démarre un exécutable EFI. C’est pourquoi vous pouvez avoir plusieurs chargeurs d’OS sur une même ESP sans dépendre d’un drapeau « actif ».
Windows utilisait historiquement une petite partition « System Reserved » en BIOS/MBR pour stocker les fichiers de démarrage et les métadonnées BitLocker, ce qui embrouille le clonage et le dépannage « pourquoi C: ne démarre pas ? ».
Beaucoup de systèmes sont livrés avec le firmware UEFI configuré pour la compatibilité « Legacy/CSM ». La même machine peut démarrer en deux modes incompatibles selon un seul réglage du firmware.
La « BIOS boot partition » est un type de partition GPT utilisé principalement pour GRUB sur systèmes BIOS. Elle est minuscule (souvent 1–2 MiB) et semble inutile jusqu’à ce qu’il faille s’en servir.

Modèles de démarrage importants : BIOS+MBR, BIOS+GPT, UEFI+GPT, UEFI+MBR

UEFI + GPT (le choix moderne par défaut à privilégier)

Cette combinaison a le moins de problèmes quand elle est réalisée correctement.

Schéma de partition : GPT
Doit avoir : EFI System Partition (FAT32), typiquement 100–550 MiB selon les habitudes des distributions/vendeurs
Emplacement du chargeur : \EFI\…\*.efi sur l’ESP
État du firmware : mode UEFI (pas legacy)

Mode d’échec : vous avez cloné la partition OS mais pas l’ESP, ou vous avez recréé l’ESP sans restaurer les entrées NVRAM. Le disque « a l’air correct », mais le firmware ne sait pas quoi charger.

BIOS + MBR (toujours courant dans des appliances et des parcs anciens)

C’est la combinaison à choisir quand vous traitez du firmware ancien, certains hyperviseurs configurés pour le legacy boot, ou des images d’entreprise qui n’ont jamais évolué.

Schéma de partition : MBR
Doit avoir : code d’amorçage dans le MBR, une partition active dans beaucoup de configurations
Limitations : adressage d’un seul disque ≈ 2 To, 4 partitions primaires sauf utilisation de partitions étendues/logiques

Mode d’échec : quelqu’un convertit en GPT « pour modernité » et oublie que le BIOS ne peut pas démarrer sans l’approche BIOS boot partition de GRUB.

BIOS + GPT (fonctionne, mais il faut le vouloir)

Le BIOS ne comprend pas nativement le GPT comme l’UEFI. Mais des chargeurs comme GRUB peuvent le faire fonctionner avec une partition BIOS boot dédiée.

Schéma de partition : GPT
Doit avoir : une petite partition BIOS boot (type EF02 dans les termes de gdisk), généralement 1–2 MiB, non formatée
Cas d’usage : démarrer des systèmes BIOS depuis des disques >2 To, ou homogénéiser l’outillage GPT sur le parc

Mode d’échec : absence de partition BIOS boot, ou disque sans espace après le MBR pour que GRUB y intègre son core image.

UEFI + MBR (possible, mais souvent un piège)

Certains firmwares UEFI peuvent démarrer depuis MBR, mais le comportement varie selon les fabricants. Pour un comportement prévisible : ne le faites pas.

Schéma de partition : MBR
Doit avoir : une partition FAT de type ESP peut exister, mais ce n’est pas standard de la même façon
Meilleure pratique : si vous êtes en mode UEFI, engagez‑vous sur GPT

Deuxième plaisanterie courte, puis retour au travail : UEFI+MBR, c’est comme porter une cravate avec un short de sport — techniquement un vêtement, pratiquement un signal d’alerte.

Tâches pratiques : 12+ commandes, sorties et décisions

Ce sont des vérifications réelles que vous pouvez exécuter sur des serveurs Linux et environnements de secours. Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision à prendre.

Task 1: Check whether you booted in UEFI mode (Linux)

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

Signification : Si vous voyez UEFI, le noyau a été démarré via UEFI. Si vous voyez BIOS, vous êtes en mode legacy.

Décision : En mode UEFI, visez GPT et assurez‑vous qu’un ESP existe et est monté sur /boot/efi (ou équivalent distro). En mode BIOS, n’assumez pas que GPT démarrera sauf si vous l’avez prévu pour BIOS+GPT.

Task 2: Identify the partition table type on a disk

cr0x@server:~$ sudo parted -s /dev/sda print | sed -n '1,12p'
Model: ATA Samsung SSD (scsi)
Disk /dev/sda: 1024GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Signification : Partition Table: gpt ou msdos (parted appelle MBR « msdos »).

Décision : Comparez cela avec le mode de démarrage. UEFI+msdos est suspect. BIOS+gpt exige de vérifier la partition BIOS boot et la méthode d’installation de GRUB.

Task 3: Inspect block devices and mountpoints at a glance

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,PARTTYPENAME,MOUNTPOINTS /dev/sda
NAME   SIZE TYPE FSTYPE FSVER PARTTYPENAME                  MOUNTPOINTS
sda    953G disk
├─sda1  512M part vfat   FAT32 EFI System                   /boot/efi
├─sda2    1G part ext4         Linux filesystem             /boot
└─sda3  952G part ext4         Linux filesystem             /

Signification : Vous voyez un ESP (vfat, “EFI System”), plus des partitions Linux normales.

Décision : Si UEFI est attendu et que vous ne voyez pas d’ESP monté, réparez cela avant de toucher à quoi que ce soit d’autre.

Task 4: Confirm the ESP is really FAT32 and has EFI files

cr0x@server:~$ sudo find /boot/efi/EFI -maxdepth 2 -type f -name '*.efi' | head
/boot/efi/EFI/ubuntu/grubx64.efi
/boot/efi/EFI/ubuntu/shimx64.efi

Signification : Des exécutables EFI existent. Si ce répertoire est vide ou manquant, vous avez probablement cloné uniquement le système racine, pas le chemin de démarrage.

Décision : Si manquant, reconstruisez le contenu de l’ESP (réinstallez le chargeur) plutôt que de réinstaller sans fin des noyaux.

Task 5: Check UEFI NVRAM boot entries

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0001* UEFI: Built-in EFI Shell	...
Boot0002* UEFI: PXE IPv4 Intel(R)	...
Boot0003* ubuntu	HD(1,GPT,7b2c...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Signification : Le firmware sait où se trouve votre chargeur sur le disque. Si l’entrée OS est manquante, le firmware peut retomber sur PXE ou un shell.

Décision : Entrée manquante : réinstallez le chargeur ou créez une nouvelle entrée. Vérifiez aussi que le GUID de partition correspond à votre disque actuel (les clones changent cela).

Task 6: Detect “GPT header not at end of disk” after cloning to a larger disk

cr0x@server:~$ sudo sgdisk -v /dev/sda
Problem: The secondary header's self-pointer indicates that it doesn't reside at the end of the disk.
Problem: The secondary header is placed too early on the disk.
No problems found. 1000 free sectors (500.0 KiB) available in 1 segments, the largest of which is 1000 (500.0 KiB) in size.

Signification : Fréquent après un clonage disque→disque : l’en‑tête GPT de secours est toujours positionné à l’ancien bout du disque.

Décision : Corrigez les métadonnées GPT avant de redimensionner partitions/systèmes de fichiers. La correction habituelle est de déplacer l’en‑tête de secours avec sgdisk -e.

Task 7: Repair GPT backup header location

cr0x@server:~$ sudo sgdisk -e /dev/sda
The operation has completed successfully.

Signification : L’en‑tête secondaire GPT a été déplacé à la vraie fin du disque.

Décision : Relancez sgdisk -v pour vérifier l’état propre, puis poursuivez les opérations de redimensionnement.

Task 8: Check whether BIOS boot partition exists on BIOS+GPT

cr0x@server:~$ sudo parted -s /dev/sda print
Model: ATA ST4000NM000 (scsi)
Disk /dev/sda: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  3146kB  2097kB               grub  bios_grub
 2      3146kB  1077MB  1074MB  ext4               boot
 3      1077MB  4001GB  4000GB  ext4               root

Signification : Le drapeau bios_grub indique la partition BIOS boot dont GRUB a besoin pour BIOS-on-GPT.

Décision : Si vous démarrez en BIOS sur un disque GPT et que cette partition manque, créez‑la avant de réinstaller GRUB, sinon vous « installerez » dans le vide.

Task 9: Confirm which disk GRUB thinks it’s installed to (Linux)

cr0x@server:~$ sudo grub-probe -t device /boot
/dev/sda2

Signification : Cela montre quel périphérique bloc supporte /boot.

Décision : Si vous vouliez démarrer depuis /dev/nvme0n1 mais que ceci rapporte /dev/sda, vous avez probablement monté le mauvais root/boot en secours, ou le système a été cloné sans mise à jour.

Task 10: Reinstall GRUB for BIOS systems (carefully)

cr0x@server:~$ sudo grub-install --target=i386-pc /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

Signification : GRUB installé en mode BIOS/MBR sur le disque. Sur BIOS+GPT, cela utilise toujours la partition BIOS boot si elle est présente.

Décision : Ne faites cela qu’après avoir confirmé le mode de démarrage. Installer i386-pc sur un système UEFI ne produira pas une entrée UEFI fonctionnelle.

Task 11: Reinstall GRUB for UEFI systems

cr0x@server:~$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
Installing for x86_64-efi platform.
Installation finished. No error reported.

Signification : Les binaires GRUB EFI sont installés dans l’ESP et une entrée NVRAM est en général créée.

Décision : Si efibootmgr n’affiche toujours pas d’entrée après cela, le firmware peut bloquer les écritures (fréquent sur certaines plateformes virtuelles) ou la NVRAM est pleine ; utilisez la stratégie de chemin de secours ou nettoyez les anciennes entrées.

Task 12: Validate MBR 2 TB limitations on a large disk

cr0x@server:~$ sudo fdisk -l /dev/sdb | sed -n '1,12p'
Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM004
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x2a3b4c5d

Signification : Le disque fait ~3.64 TiB mais la table de partition est « dos » (MBR). Vous ne pouvez pas adresser tout le disque avec le partitionnement MBR classique.

Décision : Convertissez en GPT si vous avez besoin de tout le disque. Si c’est un disque de démarrage, assurez‑vous aussi que le firmware/mode de démarrage prend en charge la méthode visée.

Task 13: Check for the “active” boot flag in MBR setups

cr0x@server:~$ sudo fdisk -l /dev/sda | sed -n '1,25p'
Disklabel type: dos

Device     Boot Start       End   Sectors  Size Id Type
/dev/sda1  *     2048   1050623   1048576  512M 83 Linux
/dev/sda2     1050624 500118191 499067568  238G 83 Linux

Signification : Le * indique la partition active. Certains chemins de code BIOS l’attendent.

Décision : Si un système BIOS/MBR indique « no bootable device » après des modifications de partition, vérifiez que le drapeau de démarrage n’a pas été effacé.

Task 14: See what your initramfs/boot config references (UUID mismatches after cloning)

cr0x@server:~$ grep -E 'UUID=|PARTUUID=' /etc/fstab
UUID=9f2e8d1a-0e2b-4c3a-9c36-2d2a3d0c1f1b / ext4 defaults 0 1
UUID=1A2B-3C4D /boot/efi vfat umask=0077 0 1

Signification : Root et ESP sont montés par UUID. Après clonage, les UUID peuvent changer si les systèmes de fichiers ont été recréés, ou rester identiques si clonage au niveau bloc.

Décision : Si le démarrage tombe dans initramfs en indiquant qu’il ne trouve pas root, comparez ces UUID avec la sortie de blkid et corrigez /etc/fstab ou régénérez initramfs.

Task 15: Confirm filesystem UUIDs and partition identifiers

cr0x@server:~$ sudo blkid /dev/sda1 /dev/sda2 /dev/sda3
/dev/sda1: UUID="1A2B-3C4D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="7b2c..."
/dev/sda2: UUID="d0c1..." BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2f10..."
/dev/sda3: UUID="9f2e..." BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8aa1..."

Signification : Confirme ce que le système doit monter et ce que GRUB/noyau peuvent référencer.

Décision : Si /etc/fstab référence un ancien UUID, mettez‑le à jour. Si GRUB référence un mauvais UUID, régénérez la configuration et réinstallez.

Task 16: Spot “legacy vs UEFI” mismatch inside GRUB config

cr0x@server:~$ sudo file /boot/grub/i386-pc/core.img
/boot/grub/i386-pc/core.img: GRUB2 core image, i386-pc, ...

Signification : Cela indique la présence d’artefacts GRUB ciblant le BIOS. Sur une configuration purement UEFI, vous vous attendez à des binaires EFI sur l’ESP plutôt qu’à dépendre de i386-pc.

Décision : Si le firmware est UEFI mais que votre système a été installé en mode BIOS, décidez si vous convertissez le mode de démarrage (repartitionnement/ESP) ou si vous conservez le legacy. Les mélanges sont la cause des pages à 2 h du matin.

Playbook de diagnostic rapide : quoi vérifier d’abord/puis/ensuite

Quand un système ne démarre plus après un changement de disque, vous pouvez perdre des heures à trifouiller le système de fichiers. Ne le faites pas. Commencez par la chaîne de démarrage et remontez. L’objectif est d’identifier quelle couche échoue en moins de 10 minutes.

First: confirm boot mode and partition table alignment

Vérifier le mode de démarrage : /sys/firmware/efi existe ?
Vérifier la table de partition : GPT ou MBR ?
Vérifier la présence d’un ESP (UEFI) ou d’une partition active / partition BIOS boot (scénarios legacy).

Raison : Si l’UEFI est activé mais que le disque est MBR sans ESP, ou si le BIOS est activé mais que le disque est GPT sans partition BIOS boot, votre « réparation système de fichiers » est du théâtre.

Second: validate bootloader presence where firmware expects it

UEFI : l’ESP contient‑elle \EFI\...\*.efi ?
UEFI : efibootmgr -v montre‑t‑il une entrée pointant vers ce fichier ?
BIOS : GRUB est‑il installé sur le bon disque (pas seulement sur une partition) ? Le code du MBR est‑il présent ?

Third: validate OS handoff (kernel + root identification)

L’initramfs se plaint‑il de root manquant ? C’est un mismatch UUID/PARTUUID ou des pilotes manquants.
Tombez‑vous dans GRUB rescue ? C’est généralement du contenu /boot manquant, un mauvais disque, ou un embed cassé.
Le gestionnaire de démarrage Windows démarre mais l’OS ne démarre pas ? Ce sont des problèmes BCD/chemin de périphérique et parfois des changements du mode du contrôleur de stockage.

Quick bottleneck identification

Si vous devez résumer :

Aucun périphérique amorçable / écran firmware : le firmware ne trouve pas le chargeur (ESP/NVRAM/code de démarrage en désaccord).
Invite GRUB / rescue : le chargeur a démarré, ne trouve pas sa config ou ses modules (mauvais IDs de partition, /boot manquant).
Kernel panic / shell initramfs : l’OS a démarré, ne peut pas monter root (mismatch UUID, pilotes manquants, mappings RAID/LVM cassés).

Trois mini-récits d’entreprise (et leurs enseignements)

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

Une équipe a migré un petit service interne d’un ancien serveur RAID vers une nouvelle machine NVMe. Le build était automatisé, l’image OS cohérente, et tout le monde se sentait responsable. Puis ils ont fait un clonage « simple » du disque de l’ancien système vers le nouveau disque pour garder la configuration identique.

L’ancien hôte démarré en mode legacy BIOS, MBR. Le nouvel hôte était livré avec l’UEFI activé par défaut. Le clone a copié partitions et systèmes de fichiers parfaitement. Il a aussi copié une chaîne de démarrage qui supposait un MBR et une partition active, sur un système dont le firmware cherchait un ESP et un exécutable EFI.

Au redémarrage : direct dans le firmware. Pas d’entrée de démarrage. Pas d’erreur évidente. L’astreinte a commencé à vérifier la santé du RAID et SMART parce que « il ne voit pas le disque ». Le disque était sain. Le firmware ne savait pas quoi en faire.

La correction était embarrassante de simplicité : soit basculer le firmware en legacy/CSM (pas idéal), soit suivre la bonne voie UEFI+GPT — table de partition GPT, créer un ESP, réinstaller le chargeur, créer une entrée NVRAM. Ils ont choisi la seconde option et standardisé leur pipeline de build pour détecter le mode de démarrage et partitionner en conséquence.

Enseignement : Ne supposez jamais que le mode de démarrage se transmet entre générations de matériel. Vérifiez‑le explicitement et intégrez le choix dans l’automatisation.

Mini-récit 2 : l’optimisation qui s’est retournée contre eux

Un groupe plateforme voulait accélérer le provisioning. Ils ont décidé de préconstruire des images golden comme images brutes de disque et de les écrire directement sur les disques de démarrage des nouveaux serveurs. C’était rapide. Cela a aussi silencieusement embarqué une disposition de partitions et une configuration de démarrage qui ne fonctionnait que dans une configuration firmware spécifique.

L’optimisation était « nous utiliserons GPT partout parce que moderne ». Bonne instinct. Le problème était qu’une partie de leur parc — anciens racks et certaines appliances en périphérie — démarrait encore en mode BIOS, et tous n’avaient pas une histoire BIOS+GPT fiable. Certains nécessitaient une partition BIOS boot. Certains avaient des bizarreries firmware. Certains ne démarraient que quand le disque avait un MBR avec une disposition particulière.

Ils ont déployé le nouveau processus d’imagerie sur un parc matériel mixte. Les échecs n’étaient pas immédiats. Ils sont apparus pendant une fenêtre de redémarrage de maintenance. Quelques systèmes sont revenus. D’autres non. Ça avait l’air aléatoire parce que le matériel était aléatoire.

Ils ont « corrigé » en créant plusieurs images et en laissant les techniciens choisir la bonne. Cela a ralenti le processus et resté sujet aux erreurs. La vraie correction a été d’arrêter de traiter le mode de démarrage comme une pensée secondaire : interroger la plateforme (UEFI vs BIOS), sélectionner la recette de partitionnement/chargeur adéquate, et générer dynamiquement les dispositions de disque. L’image golden est devenue un artefact au niveau système de fichiers, pas un blob disque.

Enseignement : Les images disque sont rapides jusqu’à ce qu’elles ne le soient plus. Si votre parc n’est pas homogène, les blobs disque statiques sont une taxe de fiabilité.

Mini-récit 3 : la pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe liée aux finances avait une politique qui énervait tout le monde : avant toute migration ou redimensionnement de disque, ils capturaient un petit « bundle d’infos de démarrage » — mode de démarrage, type de table de partition, lsblk, et pour l’UEFI, efibootmgr -v. Ça prenait deux minutes et ressemblait à de la paperasserie.

Un trimestre, ils ont déplacé des workloads de SSD vieillissants vers de nouveaux disques. Un outil fournisseur a effectué le clone et redimensionné la dernière partition. La partition OS avait l’air correcte, mais après redémarrage le système est tombé dans GRUB rescue. La panique montait parce que la fenêtre de changement était courte et le système « assez critique ».

Le bundle pré‑changement montrait quelque chose de subtil : l’ancien disque avait un ESP monté sur /boot/efi avec un chemin fournisseur spécifique, et l’entrée de démarrage référençait un GUID de partition particulier. Après le clonage, l’ESP existait mais n’était pas monté ; l’outil de clonage avait modifié les GUID de partition. Le firmware suivait une entrée NVRAM obsolète et n’aboutissait nulle part.

Avec les preuves en main, la récupération a été propre : monter l’ESP, réinstaller le chargeur, recréer l’entrée NVRAM, et vérifier le chemin de secours. Pas de devinettes. Pas de raclage de système de fichiers. Le système est revenu dans la fenêtre.

Enseignement : La collecte d’éléments d’évidence ennuyeuse bat le débogage héroïque. À chaque fois.

Erreurs courantes : symptôme → cause racine → correctif

Cette section est celle que vous cherchez à 2 h du matin. C’est normal. Je l’ai écrite pour ce moment.

1) Symptom: “No bootable device” immediately after disk clone

Cause racine : Le mode de démarrage firmware a changé (UEFI vs BIOS) ou le schéma du disque ne correspond pas aux attentes du firmware (UEFI tentant de démarrer un disque MBR sans ESP/entrées NVRAM).

Correctif : Confirmez le mode de démarrage, puis alignez le disque :

UEFI : GPT + ESP + grub-install --target=x86_64-efi + entrée efibootmgr.
BIOS : MBR + partition active + grub-install --target=i386-pc /dev/sdX.

2) Symptom: GRUB rescue prompt, can’t find `normal.mod`

Cause racine : Le cœur GRUB a été chargé, mais il ne trouve pas ses modules/config — souvent parce que /boot a bougé, les IDs de partition ont changé, ou la partition BIOS boot manque sur BIOS+GPT.

Correctif : Démarrez sur média de secours, montez root et boot, réinstallez GRUB pour la cible correcte, régénérez la config (update-grub ou équivalent distro). Sur BIOS+GPT, assurez‑vous qu’une partition BIOS boot existe.

3) Symptom: Kernel starts, then initramfs shell: “cannot find UUID=…”

Cause racine : L’identifiant du système de fichiers root a changé (mismatch UUID/PARTUUID), ou le mode du contrôleur de stockage a changé (AHCI/RAID) et l’initramfs manque des modules pilotes.

Correctif : Comparez /etc/fstab et les arguments noyau du chargeur avec blkid. Mettez à jour les identifiants, reconstruisez initramfs. Si le mode du contrôleur a changé, revenez en arrière ou reconstruisez initramfs avec les bons modules.

4) Symptom: Disk is GPT but tools complain about corrupted headers after resizing

Cause racine : L’en‑tête GPT de secours n’a pas été déplacé à la fin après un clonage ; ou la table de partitions a été modifiée par des outils MBR‑only.

Correctif : Utilisez sgdisk -v pour valider ; réparez avec sgdisk -e ; évitez les outils legacy qui réécrivent mal le protective MBR.

5) Symptom: UEFI system boots only after you pick the disk manually in firmware menu

Cause racine : Ordre/entrées NVRAM incorrectes ou manquantes ; parfois l’entrée de démarrage pointe vers un GUID de partition désormais modifié.

Correctif : Auditez avec efibootmgr -v. Réinstallez le chargeur ou recréez l’entrée. Envisagez de placer une copie sur le chemin de secours (\EFI\BOOT\BOOTX64.EFI) si la politique le permet.

6) Symptom: After “convert to GPT,” Windows won’t boot

Cause racine : Conversion de la table de partition sans conversion du mode de démarrage/boot manager ; ESP manquant ; BCD pointe encore vers un chemin BIOS.

Correctif : Sous Windows, utilisez les outils de conversion appropriés puis activez le boot UEFI. Assurez‑vous que l’ESP existe et est peuplé. Si mode mixte, choisissez une voie et reconstruisez le gestionnaire de démarrage en conséquence.

7) Symptom: You can’t create more than four partitions on MBR

Cause racine : MBR supporte seulement quatre partitions primaires sauf si vous utilisez une partition étendue avec partitions logiques.

Correctif : Si vous avez besoin de nombreuses partitions et d’un boot moderne, passez à GPT. Si vous devez rester en MBR, concevez avec une partition étendue et acceptez la complexité legacy.

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

Checklist A: Picking GPT vs MBR (the decision path)

Déterminez la cible de mode de démarrage : UEFI ou BIOS ? (Ne devinez pas ; vérifiez dans les specs du firmware ou l’OS actuel.)
Si UEFI : choisissez GPT.
Si BIOS : choisissez MBR sauf si vous avez une raison précise d’utiliser GPT (disque >2 To, standardisation du parc) et que vous êtes prêt à utiliser une partition BIOS boot.
Vérifiez les besoins de taille du disque : si vous avez besoin de >2 To sur un seul disque, GPT est requis quelle que soit la nostalgie.
Décidez de la stratégie de chargeur (GRUB, systemd-boot, Windows boot manager) et assurez‑vous que les partitions requises existent.

Checklist B: Safe migration or clone plan (Linux servers)

Capturez les « boot facts » avant le changement : mode de démarrage, table de partition, lsblk, et si UEFI, efibootmgr -v.
Si vous utilisez GPT : validez les en‑têtes GPT avec sgdisk -v après le clone ; corrigez avec sgdisk -e si nécessaire.
Assurez‑vous que l’ESP (UEFI) est cloné ou recréé et monté au point de montage attendu.
Vérifiez que les UUID de /etc/fstab correspondent à blkid.
Réinstallez le chargeur correspondant au mode de démarrage réel (cible UEFI vs target BIOS).
Redémarrez une fois tant que vous avez encore un accès console et une fenêtre de rollback.

Checklist C: Converting BIOS/MBR to UEFI/GPT (high-level steps)

Confirmez que le matériel/VM supporte le boot UEFI et que vous pouvez le basculer.
Créez de l’espace pour un ESP si nécessaire (réduisez les partitions avec précaution).
Convertissez la table de partition (outillage spécifique à la plateforme ; ne « wing it » pas avec des utilitaires aléatoires).
Créez l’ESP (FAT32) et montez‑le.
Installez le chargeur EFI, créez l’entrée NVRAM, vérifiez avec efibootmgr -v.
Basculez le firmware en mode UEFI et testez le démarrage.

FAQ

1) Is GPT always better than MBR?

Meilleur pour les systèmes modernes, oui : disques plus grands, plus de partitions, redondance, checksums. Mais « meilleur » ne fera pas démarrer votre appliance antique qui ne connaît que le BIOS. Alignez sur le mode de démarrage.

2) Can BIOS boot from GPT?

Oui, souvent via GRUB avec une partition BIOS boot. C’est courant dans les fermes Linux qui veulent GPT partout. Mais ce n’est pas magique : il faut créer la petite partition BIOS boot et installer GRUB correctement.

3) Why does my GPT disk show an MBR in some tools?

C’est le protective MBR. Il existe pour que les outils MBR‑only ne traitent pas le disque comme vide. Si un outil le réécrit « gentiment », il peut embrouiller d’autres outils.

4) What ESP size should I use?

Pour les serveurs Linux, 512 MiB est une valeur par défaut raisonnable qui évite des douleurs futures (multiples noyaux, plusieurs chargeurs, mises à jour fournisseurs). Plus petit peut fonctionner, jusqu’au jour où ça ne marche plus.

5) Do I need an active/boot flag on GPT?

Non pour l’UEFI. L’UEFI ne se soucie pas de l’« active » au sens MBR. Pour BIOS+MBR, le drapeau de démarrage peut importer selon le chargeur et la chaîne.

6) I cloned a disk and now UEFI entries point to the wrong thing. Why?

Les entrées de démarrage UEFI peuvent référencer une partition par GUID et un chemin de fichier. Le clonage ou la recréation de partitions peut changer les GUID. Corrigez en réinstallant le chargeur ou en recréant l’entrée de démarrage.

7) Can I keep MBR and just create an ESP?

Pas comme stratégie portable standard. Certains firmwares peuvent le démarrer, d’autres non. Si vous voulez la fiabilité UEFI, utilisez GPT avec un ESP approprié.

8) What’s the difference between an ESP and a BIOS boot partition?

L’ESP est un système de fichiers FAT32 qui stocke des exécutables EFI pour le firmware UEFI. Une partition BIOS boot est un petit espace non formaté que GRUB utilise sur les disques GPT lorsqu’on démarre via BIOS.

9) Why do some systems boot fine until the next reboot after resizing partitions?

Parce que vous n’avez pas cassé le système en cours d’exécution — vous avez cassé la chaîne de démarrage du prochain démarrage. Le redimensionnement peut déplacer ou recréer des partitions, changer des identifiants, ou effacer la zone d’embed post‑MBR sur laquelle GRUB comptait.

10) What should I standardize on in a mixed fleet?

Standardisez le processus de décision, pas une seule réponse. Détectez le mode de démarrage et les contraintes matérielles, puis générez la disposition correcte (UEFI+GPT par défaut ; cas BIOS traités délibérément).

Prochaines étapes à réaliser aujourd’hui

Si vous gérez des systèmes en production, considérez le démarrage comme un contrat API entre le firmware et la disposition du disque. Les contrats se moquent de vos intentions.

Auditez un échantillon de votre parc : vérifiez mode de démarrage et type de table de partition. Trouvez les discordances avant qu’elles ne vous appellent la nuit.
Mettez à jour vos scripts de provisioning pour sélectionner explicitement UEFI vs BIOS puis imposer GPT vs MBR en conséquence.
Ajoutez une étape « capture des boot facts » avant changement dans vos runbooks pour travaux sur disque. Deux minutes au départ vous épargne des heures ensuite.
Pour tout workflow de clonage ou migration : vérifiez que l’ESP/les partitions BIOS boot existent et sont peuplées avant de redémarrer.

La règle est simple. La discipline ne l’est pas. Mais la discipline coûte moins cher que l’indisponibilité.