Convertir MBR en GPT sans réinstallation (avec outils intégrés)

Le vrai problème : table de partitions vs mode de démarrage

MBR vs GPT concerne la table de partitions. BIOS vs UEFI concerne le mode de démarrage du firmware. Les gens confondent parce qu’ils vont souvent ensemble :

• Le BIOS Legacy démarre typiquement depuis MBR.
• UEFI démarre généralement depuis GPT via une EFI System Partition (ESP).

Mais des cas de discordance existent en production. C’est là que les conversions dérapent. Convertir la table de partitions ne suffit pas ; le système doit aussi disposer d’un chargeur de démarrage compatible avec le mode de firmware que vous utiliserez après la conversion.

Le modèle mental simple et sûr :

• Windows : Si vous convertissez le disque système de MBR en GPT, vous devez démarrer Windows en UEFI. L’outil intégré de Microsoft (mbr2gpt) gère la partition et les fichiers de démarrage, mais vous devez toujours modifier les paramètres du firmware.
• Linux : Vous pouvez convertir en GPT et conserver le démarrage Legacy en utilisant une partition BIOS boot (image core de GRUB) ou passer à UEFI avec une ESP. Ce qui est « intégré » dépend de la distribution, mais les outils de base (fdisk, gdisk/sgdisk, grub-install, efibootmgr) sont généralement fournis.

Voici la vérité sans fioritures : la plupart des pannes durant une conversion MBR→GPT ne sont pas causées par l’outil de conversion. Elles sont causées par des personnes qui devinent quel disque est « Disk 0 », supposent que le firmware suivra automatiquement, ou découvrent trop tard que BitLocker/Secure Boot ont une politique incompatible avec le plan.

Blague n°1 : Les tables de partitions sont comme les organigrammes de bureau : tout le monde les ignore jusqu’à ce que quelque chose casse, puis soudain elles deviennent de la « documentation critique ».

Une citation sur la fiabilité qui tient en contexte :

« L’espoir n’est pas une stratégie. » — James Cameron

Dans ce contexte, « espoir » ressemble à une conversion en production sans sauvegarde vérifiée et sans confirmer que vous pouvez accéder au réglage du firmware. Ne faites pas ça.

Faits et contexte intéressants (ce qui explique les bizarreries)

1. Le plafond de 2 To de MBR vient de l’adressage sur 32 bits des secteurs avec des secteurs de 512 octets : 2^32 × 512 octets ≈ 2 To. Oui, les disques à secteurs 4K compliquent le calcul, mais la limite héritée reste problématique.
2. MBR date de l’ère PC ancienne et a été conçu pour un monde où un « grand disque » se mesurait en mégaoctets, pas en téraoctets.
3. GPT fait partie de l’écosystème UEFI, mais il peut être utilisé sans UEFI dans certaines configurations Linux. L’association est autant culturelle que technique.
4. GPT conserve un en‑tête de secours à la fin du disque. Ce n’est pas décoratif ; c’est la manière dont les outils récupèrent un en‑tête primaire écrasé.
5. MBR a une table de partitions unique pour tout le disque, tandis que GPT utilise des sommes de contrôle CRC pour détecter la corruption. C’est pourquoi les outils GPT peuvent indiquer « vos métadonnées sont mauvaises » au lieu de démarrer silencieusement dans le chaos.
6. Le « MBR protecteur » sur les disques GPT existe pour que les anciens outils ne croient pas que le disque est vide et ne viennent pas l’écraser « par gentillesse ».
7. Windows a historiquement exigé GPT pour le démarrage UEFI sur les disques système. L’outil de conversion moderne existe parce que les entreprises ont demandé une migration in situ pour les référentiels de sécurité.
8. Les entrées de démarrage UEFI résident en NVRAM et peuvent être effacées par des mises à jour de firmware, des réinitialisations de NVRAM, ou certains scripts de durcissement qui ignorent ce qu’ils suppriment.
9. Le démarrage BIOS depuis GPT est possible pour Linux via une petite « BIOS boot partition », mais Windows ne le fait pas pour les disques système. Systèmes différents, règles différentes.

Pré‑contrôle : décidez de la marche à suivre avant de toucher un disque

Avant la conversion, répondez à trois questions. Pas « je pense que oui ». Prouvez‑le avec des commandes.

1) Quel OS démarre réellement cette machine ?

Les machines en dual‑boot, les environnements de secours et les anciens hôtes de staging aiment vous surprendre. Convertir le mauvais disque et vous pratiquerez la communication d’incident.

2) Êtes‑vous actuellement démarré en BIOS/Legacy ou en UEFI ?

Cela détermine si vous pouvez conserver la même approche de démarrage ou si vous devez basculer. Pour la conversion du disque système Windows avec mbr2gpt, vous devrez passer en UEFI.

3) La disposition du disque est‑elle convertible sans déplacer des montagnes ?

mbr2gpt est pointilleux : il a besoin de place pour créer une EFI System Partition (ESP), et il impose des contraintes sur le nombre/types de partitions. Les conversions Linux peuvent être plus flexibles, mais votre chargeur de démarrage et votre fstab pourraient ne pas l’être.

Conseils orientés :

• Si c’est un portable ou un serveur critique unique et que vous n’avez pas de console hors bande : planifiez une fenêtre d’indisponibilité et ayez un média de récupération bootable prêt. « Remote hands » n’est pas un plan ; c’est une prière avec un numéro de ticket.
• Si c’est une VM : prenez un snapshot (si la politique le permet), et faites quand même les vérifications. Les snapshots ne sont pas des sauvegardes, mais ce sont d’excellents amortisseurs de regrets.
• Si c’est un LUN via contrôleur RAID : confirmez que le contrôleur n’effectue pas de réécriture « utile » des métadonnées pendant les conversions. Habituellement c’est OK, parfois maudit.

Playbook de diagnostic rapide (trouver le goulot d’étranglement vite)

Quand une « conversion MBR vers GPT » échoue, le goulot est presque toujours l’un des suivants : mauvais disque, mauvais mode de démarrage, pas d’espace pour l’ESP, ou confusion du chargeur de démarrage/NVRAM. Contrôlez dans cet ordre.

Premier : Confirmez le mode de démarrage et le disque cible

• Windows : vérifiez le mode du BIOS dans msinfo32 ou via PowerShell/WMI.
• Linux : vérifiez l’existence de /sys/firmware/efi.
• Confirmez le numéro/chemin du disque que vous comptez convertir, et confirmez qu’il contient l’OS.

Second : Validez les prérequis de conversion

• Windows : exécutez mbr2gpt /validate. Lisez l’erreur. N’improvisez pas.
• Linux : confirmez qu’il y a de la place pour ajouter une ESP (voie UEFI) ou une BIOS boot partition (voie legacy). Assurez‑vous que les changements de table de partitions ne vont pas entrer en collision avec les emplacements de métadonnées LVM/RAID.

Troisième : Planifiez le chemin de démarrage post‑conversion

• Windows : après conversion, vous devez passer le firmware en UEFI et vous assurer que l’entrée Windows Boot Manager est présente.
• Linux : décidez si vous installez GRUB en mode EFI (ESP + entrée NVRAM) ou en mode BIOS (BIOS boot partition). Installez en conséquence.

Quatrième : Si la conversion a réussi mais que la machine ne démarre pas, concentrez‑vous sur les artefacts de démarrage

• Windows : utilisez WinRE, bcdboot, et vérifiez l’ESP.
• Linux : utilisez un ISO live, efibootmgr, grub-install, et vérifiez les montages et les UUID.

Parcours Windows (intégré) : MBR2GPT + bascule UEFI

Sur Windows 10/11 et les versions modernes de Windows Server, l’outil intégré est mbr2gpt.exe. Il convertit le disque système de MBR en GPT sans modifier le contenu de vos partitions Windows existantes, crée une ESP et met à jour la configuration de démarrage. C’est la meilleure option quand elle s’applique.

Ce que mbr2gpt fait bien

• Conversion non destructive de la table de partitions (au sens où il n’efface pas le contenu des partitions de données).
• Crée une EFI System Partition et une Microsoft Reserved Partition si nécessaire.
• Met à jour le BCD pour démarrer en mode UEFI.

Ce que mbr2gpt refusera de faire

• Convertir des disques qui ne respectent pas ses contraintes de disposition.
• Reconfigurer magiquement votre firmware de Legacy à UEFI. C’est à vous de le faire.
• Corriger des gestionnaires de démarrage tiers que vous avez installés de manière créative.

Approche opérationnelle

Faites la conversion depuis WinRE ou depuis Windows complet avec /allowFullOS quand c’est nécessaire. En flotte d’entreprise, WinRE réduit les surprises du type « quelque chose avait un verrou sur les métadonnées du disque ». En pratique, si vous pouvez prendre une fenêtre d’indisponibilité de toute façon, WinRE est plus serein.

Après la conversion : redémarrez, entrez dans le setup du firmware, passez en mode UEFI, laissez Secure Boot désactivé jusqu’à confirmation du démarrage, puis activez‑le si la politique l’exige. Ne combinez pas « migration de table de partitions » avec « activation immédiate de Secure Boot » sauf si vous aimez les échecs empilés.

Parcours Linux : convertir avec gdisk/sgdisk, puis expliciter le démarrage

Linux vous donne des choix, et les choix sont la raison pour laquelle vous vous retrouvez avec sept chargeurs de démarrage et un week‑end de travail. Si votre objectif est « GPT sans réinstallation », vous avez deux stratégies sensées :

1. Convertir en GPT et conserver le démarrage Legacy en créant une petite BIOS boot partition et en réinstallant GRUB en mode BIOS.
2. Convertir en GPT et passer au démarrage UEFI en créant une ESP, en installant GRUB pour EFI et en créant une entrée de démarrage NVRAM.

La plupart des environnements modernes devraient choisir UEFI sauf contrainte formelle. UEFI n’est pas automatiquement « meilleur », mais c’est la direction que supposent votre firmware, les outils éditeur et les référentiels de sécurité.

Précaution clé pour les conversions Linux

• Si vous utilisez LVM, mdraid ou chiffrement, vos partitions sont des conteneurs. La conversion de la table de partitions ne réécrit pas le contenu, mais vous ne devez pas changer les secteurs de départ sans précaution.
• Connaissez votre chargeur de démarrage : GRUB en mode BIOS repose sur un espace d’embed ; sur des disques GPT il a typiquement besoin d’une BIOS boot partition.
• UEFI exige une ESP formatée en FAT32, typiquement montée sur /boot/efi.

Blague n°2 : Les écrans de configuration UEFI ont été dessinés par quelqu’un qui a regardé un cockpit et a dit : « Trop intuitif. »

Tâches pratiques : commandes, ce que signifie la sortie, la décision que vous prenez

Ce sont les vérifications réelles que j’exécute. Chacune a une raison : elle transforme une supposition en décision. Les commandes sont regroupées par plateforme, mais certaines s’appliquent partout.

Task 1 (Windows): Confirm BIOS mode (UEFI vs Legacy)

cr0x@server:~$ powershell -NoProfile -Command "(Get-ComputerInfo).BiosFirmwareType"
Legacy

Ce que cela signifie : Vous êtes actuellement démarré en mode Legacy.

Décision : Si vous convertissez le disque système en GPT, prévoyez un changement de firmware vers UEFI après la conversion. Si vous ne pouvez pas accéder au setup du firmware à distance, arrêtez et organisez un accès physique.

Task 2 (Windows): Identify the system disk number

cr0x@server:~$ powershell -NoProfile -Command "Get-Disk | Select Number,FriendlyName,PartitionStyle,Size"
0  NVMe SAMSUNG MZVLW512  MBR  476.94 GB
1  Virtual Disk            GPT  100.00 GB

Ce que cela signifie : Le disque 0 est en MBR et probablement votre disque OS ; le disque 1 est déjà GPT.

Décision : Ciblez le disque 0 pour la validation et la conversion. Si l’OS est sur le disque 1, votre hypothèse est fausse — vérifiez avec le mappage des partitions et volumes.

Task 3 (Windows): Confirm which partition contains Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-Partition -DiskNumber 0 | Select PartitionNumber,DriveLetter,Type,Size"
1      System     500 MB
2      Reserved   128 MB
3  C   Basic      475.8 GB

Ce que cela signifie : Le volume C: est sur le disque 0 partition 3.

Décision : La conversion doit cibler le disque 0. Si C: n’est pas ici, continuez à creuser ; ne convertissez pas « simplement Disk 0 » par habitude.

Task 4 (Windows): Validate conversion prerequisites

cr0x@server:~$ mbr2gpt /validate /disk:0 /allowFullOS
MBR2GPT: Attempting to validate disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Validation completed successfully

Ce que cela signifie : L’outil estime qu’il peut convertir ce disque en toute sécurité.

Décision : Procédez à la conversion pendant la fenêtre de maintenance. Si la validation échoue, n’essayez pas « quand même ». Corrigez la disposition d’abord.

Task 5 (Windows): Convert the disk

cr0x@server:~$ mbr2gpt /convert /disk:0 /allowFullOS
MBR2GPT: Attempting to convert disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Creating the EFI system partition
MBR2GPT: Installing the new boot files
MBR2GPT: Performing the layout conversion
MBR2GPT: Migrating default boot entry
MBR2GPT: Conversion completed successfully

Ce que cela signifie : Le disque est désormais GPT et dispose de fichiers de démarrage prêts pour l’UEFI.

Décision : Redémarrez dans le setup du firmware et passez en boot UEFI. Si vous redémarrez sans changer le firmware, vous pourriez obtenir « aucun périphérique de démarrage ».

Task 6 (Windows): Confirm disk is now GPT

cr0x@server:~$ powershell -NoProfile -Command "Get-Disk -Number 0 | Select Number,PartitionStyle"
0 GPT

Ce que cela signifie : La conversion de la table de partitions a réussi.

Décision : Continuez avec la configuration UEFI et la vérification du démarrage. Ne déclarez pas terminé tant que vous n’avez pas confirmé que le mode de démarrage est UEFI.

Task 7 (Windows): Verify ESP exists and has a drive letter temporarily (optional)

cr0x@server:~$ diskpart
DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     C                NTFS   Partition    475 GB  Healthy    Boot
  Volume 1                      FAT32  Partition    100 MB  Healthy    System

Ce que cela signifie : Il y a un volume FAT32 « System » — l’ESP.

Décision : S’il n’y a pas d’ESP, la conversion n’a pas fait ce que vous pensez. Arrêtez et inspectez la table de partitions avant de redémarrer à l’aveugle.

Task 8 (Windows/WinRE): Rebuild boot files if needed

cr0x@server:~$ bcdboot C:\Windows /s S: /f UEFI
Boot files successfully created.

Ce que cela signifie : Les fichiers de démarrage Windows ont été écrits sur l’ESP monté en S:.

Décision : Utilisez ceci quand la conversion a réussi mais que le firmware ne trouve pas d’entrée de démarrage. C’est un geste de réparation, pas le premier réflexe.

Task 9 (Linux): Confirm current boot mode

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

Ce que cela signifie : Le noyau a été démarré via le BIOS legacy.

Décision : Si vous voulez passer à l’UEFI, il vous faudra une ESP et l’installation d’un chargeur EFI. Si vous voulez rester en BIOS, prévoyez une BIOS boot partition sur GPT.

Task 10 (Linux): Inspect current disk and partition table type

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda     931.5G disk
├─sda1    512M part ext4   /boot
├─sda2    100G part LVM2_member
└─sda3    831G part LVM2_member

Ce que cela signifie : La disposition du disque est basée sur des partitions avec des membres LVM.

Décision : La conversion peut fonctionner, mais vous devez préserver les secteurs de départ des partitions. Des outils comme sgdisk sont préférés car ils ne réalignent pas « utilement » les partitions sauf si on le leur demande.

Task 11 (Linux): Verify partition table (MBR vs GPT) with parted

cr0x@server:~$ sudo parted -s /dev/sda print
Model: ATA ST1000DM003-1CH1 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Number  Start   End     Size    Type     File system  Flags
 1      1049kB  538MB   537MB   primary  ext4         boot
 2      538MB   108GB   107GB   primary
 3      108GB   1000GB  892GB   primary

Ce que cela signifie : C’est du MBR (« msdos » dans le vocabulaire de parted).

Décision : Procédez avec un plan de conversion MBR→GPT. Notez aussi : trois partitions primaires déjà présentes. Si vous avez besoin d’une BIOS boot partition ou d’une ESP, il faudra dégager de l’espace.

Task 12 (Linux): Non-destructive convert MBR → GPT with sgdisk

cr0x@server:~$ sudo sgdisk --mbrtogpt /dev/sda
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

Ce que cela signifie : Les métadonnées du disque ont été converties ; le noyau en cours utilise encore l’ancienne table.

Décision : Ne commencez pas à redimensionner des partitions dans cet état. Redémarrez (dans la fenêtre de maintenance) ou exécutez partprobe si c’est sûr, puis revérifiez avec parted.

Task 13 (Linux): Re-read partition table safely

cr0x@server:~$ sudo partprobe /dev/sda
cr0x@server:~$ sudo parted -s /dev/sda print | grep -i "Partition Table"
Partition Table: gpt

Ce que cela signifie : Le noyau et les outils sont maintenant d’accord : c’est du GPT.

Décision : Procédez maintenant à l’ajout de la partition de démarrage nécessaire (BIOS boot ou ESP) et réinstallez le chargeur de démarrage selon le cas.

Task 14 (Linux, BIOS boot path): Create a BIOS boot partition (if staying Legacy)

cr0x@server:~$ sudo parted -s /dev/sda mkpart biosboot 1MiB 3MiB
cr0x@server:~$ sudo parted -s /dev/sda set 4 bios_grub on
cr0x@server:~$ sudo parted -s /dev/sda print | tail -n +1
Model: ATA ST1000DM003-1CH1 (scsi)
Disk /dev/sda: 1000GB
Partition Table: gpt
Number  Start   End     Size    File system  Name      Flags
 1      1049kB  538MB   537MB   ext4         primary   boot
 2      538MB   108GB   107GB                primary
 3      108GB   1000GB  892GB                primary
 4      1049kB  3146kB  2097kB               biosboot  bios_grub

Ce que cela signifie : Vous avez maintenant une BIOS boot partition (minuscule, non formatée) marquée pour l’embed de GRUB.

Décision : Réinstallez GRUB en mode BIOS sur la zone protectrice MBR du disque (GRUB utilise la partition bios_grub pour l’image core sur GPT).

Task 15 (Linux, BIOS boot path): Reinstall GRUB for BIOS

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

Ce que cela signifie : Le chargeur GRUB BIOS est installé sur le disque, en utilisant la BIOS boot partition au besoin.

Décision : Redémarrez et vérifiez. Si l’hôte démarre, vous pouvez conserver le mode firmware legacy. Si vous vouliez UEFI, arrêtez‑vous et faites l’installation UEFI à la place.

Task 16 (Linux, UEFI path): Create and format an EFI System Partition

cr0x@server:~$ sudo parted -s /dev/sda mkpart esp fat32 3MiB 515MiB
cr0x@server:~$ sudo parted -s /dev/sda set 4 esp on
cr0x@server:~$ sudo mkfs.fat -F32 /dev/sda4
mkfs.fat 4.2 (2021-01-31)

Ce que cela signifie : Vous avez créé une ESP d’environ 512 MiB et l’avez formatée en FAT32.

Décision : Montez‑la sur /boot/efi et installez un chargeur EFI. Si vous aviez déjà une ESP ailleurs, ne créez pas une seconde sans réfléchir — le firmware choisira son favori.

Task 17 (Linux, UEFI path): Install GRUB for EFI and create NVRAM entry

cr0x@server:~$ sudo mkdir -p /boot/efi
cr0x@server:~$ sudo mount /dev/sda4 /boot/efi
cr0x@server:~$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
Installing for x86_64-efi platform.
Installation finished. No error reported.
cr0x@server:~$ sudo efibootmgr -v | head
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0002* GRUB HD(4,GPT,...)File(\EFI\GRUB\grubx64.efi)

Ce que cela signifie : GRUB est installé dans l’ESP et une entrée de démarrage firmware existe.

Décision : Passez le firmware en mode UEFI, assurez‑vous que l’entrée GRUB/EFI est prioritaire (ou au moins présente), puis redémarrez.

Task 18 (Linux): Verify fstab/UUIDs didn’t change in a way you didn’t expect

cr0x@server:~$ sudo blkid /dev/sda1 /dev/sda4
/dev/sda1: UUID="2e5c0b3f-8f3e-4d21-bc6a-7a8c0a2a4cbd" TYPE="ext4" PARTUUID="d9c3d8e9-01"
/dev/sda4: UUID="7A3C-1B2F" TYPE="vfat" PARTUUID="d9c3d8e9-04"

Ce que cela signifie : Les UUIDs des systèmes de fichiers sont stables ; GPT ajoute des PARTUUIDs.

Décision : Si votre configuration de démarrage utilise des PARTUUIDs, mettez à jour les configurations en conséquence. Si vous montez par UUID, vous êtes probablement OK. Confirmez que /etc/fstab inclut l’ESP pour l’UEFI.

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

Checklist A: « J’ai besoin que le disque système Windows soit GPT pour activer Secure Boot / baseline moderne »

1. Sauvegarde ou snapshot (oui, même si c’est « non destructif »). Assurez‑vous de pouvoir restaurer la machine, pas seulement les données.
2. Confirmez que l’OS démarre en Legacy et que la conversion est nécessaire (Task 1).
3. Identifiez le disque correct (Task 2) et confirmez le mappage des partitions Windows (Task 3).
4. Suspendre BitLocker si activé (selon la politique). Sinon, attendez‑vous à des demandes de clé de récupération ou pire, une impossibilité de démarrage après les changements de firmware.
5. Exécutez mbr2gpt /validate (Task 4). Si cela échoue, corrigez les raisons (souvent nombre/espacement des partitions).
6. Exécutez mbr2gpt /convert (Task 5).
7. Redémarrez dans le firmware et passez en mode UEFI. Laissez Secure Boot désactivé jusqu’à vérification du démarrage.
8. Démarrez Windows, vérifiez que le style de partition est GPT (Task 6) et que le type de firmware est UEFI (Task 1 de nouveau).
9. Ensuite seulement, activez Secure Boot si nécessaire et réactivez la protection BitLocker.

Checklist B: « Serveur Linux, convertir le disque OS en GPT et garder Legacy BIOS parce que le firmware du fournisseur est étrange »

1. Obtenez un accès console (iLO/iDRAC/IPMI ou au moins une console VM). Travailler les disques sans console est un pari, pas de l’ingénierie.
2. Confirmez le mode de démarrage actuel (Task 9). Si vous êtes déjà en UEFI, reconsidérez pourquoi vous voudriez rester en legacy.
3. Confirmez que la table actuelle est msdos (Task 11).
4. Convertissez MBR→GPT avec sgdisk --mbrtogpt (Task 12).
5. Relisez la table de partitions (Task 13) ou redémarrez en mode maintenance.
6. Créez une BIOS boot partition (Task 14) si elle n’existe pas.
7. Réinstallez GRUB pour la cible BIOS (Task 15).
8. Redémarrez et vérifiez. Gardez le média de secours jusqu’à ce que vous ayez survécu à au moins un redémarrage supplémentaire.

Checklist C: « Serveur Linux, convertir le disque OS en GPT et passer proprement à l’UEFI »

1. Confirmez que la plateforme supporte l’UEFI et que vous pouvez l’activer dans le firmware.
2. Vérifiez le mode de démarrage actuel (Task 9). Si BIOS aujourd’hui, vous basculerez après l’installation du démarrage EFI.
3. Convertissez MBR→GPT (Task 12), puis relisez (Task 13).
4. Créez une ESP et formatez‑la en FAT32 (Task 16). Taille typique : 260–512 MiB.
5. Montez l’ESP sur /boot/efi et installez GRUB EFI (Task 17).
6. Vérifiez qu’une entrée NVRAM existe (efibootmgr -v dans l’exemple Task 17).
7. Passez le firmware en mode UEFI. Si le firmware supporte les deux, préférez « UEFI only » une fois stable pour éviter l’ambiguïté de démarrage.
8. Vérifiez le démarrage, puis confirmez que l’OS voit l’UEFI (/sys/firmware/efi existe).

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: « Aucun périphérique de démarrage » juste après la conversion

Cause racine : Disque converti, mais le firmware est toujours réglé sur Legacy/CSM. Les fichiers UEFI existent, mais le firmware ne les cherche pas.

Correction : Entrez dans le setup du firmware, passez en mode UEFI, assurez‑vous que « Windows Boot Manager » (ou votre entrée Linux) est présente et prioritaire.

2) Symptom: mbr2gpt /validate échoue avec des erreurs de disposition

Cause racine : Trop de partitions, types de partition non supportés, ou espace libre insuffisant pour créer l’ESP.

Correction : Réduisez le nombre de partitions (fusionnez, supprimez une partition de récupération que vous pouvez régénérer, ou réduisez C: pour créer de l’espace). Puis relancez la validation. Ne procédez pas tant que la validation n’a pas réussi.

3) Symptom: Windows démarre, mais BitLocker demande la clé de récupération à chaque fois

Cause racine : Les mesures de démarrage du firmware/TPM ont changé (Legacy→UEFI, toggles Secure Boot, changements d’ordre de démarrage) sans que BitLocker ait été suspendu et reseal correctement.

Correction : Suspendez BitLocker avant le changement ; après un démarrage stable, réactivez la protection pour qu’elle se réinitialise sur le nouveau chemin de démarrage.

4) Symptom: Linux démarre une fois, puis après une mise à jour firmware il passe en PXE

Cause racine : Les entrées de démarrage NVRAM UEFI ont été effacées ou réordonnées par la mise à jour/réinitialisation du firmware.

Correction : Recréez l’entrée avec efibootmgr (depuis un live ISO si nécessaire) et envisagez d’installer un chargeur de secours dans \EFI\BOOT\BOOTX64.EFI sur l’ESP.

5) Symptom: parted affiche GPT mais le noyau voit encore les anciennes partitions

Cause racine : Le noyau n’a pas relu la table de partitions ; les périphériques sont encore mappés avec l’ancienne géométrie.

Correction : Utilisez partprobe et revérifiez, ou redémarrez pendant la maintenance. Évitez les opérations de redimensionnement tant que le noyau n’est pas d’accord.

6) Symptom: Après conversion Linux, invite GRUB rescue apparaît

Cause racine : L’image core de GRUB est introuvable/ineditable (BIOS sur GPT sans partition bios_grub), ou mauvais target GRUB installé.

Correction : Si vous restez en BIOS, ajoutez une BIOS boot partition et réinstallez GRUB avec --target=i386-pc. Si vous migrez vers l’UEFI, créez/montez l’ESP et installez avec --target=x86_64-efi.

7) Symptom: Le disque est GPT mais l’installateur/récupération Windows ne trouve pas Windows

Cause racine : Vous avez booté le média de récupération en Legacy alors que le disque attend des structures UEFI (ou l’inverse).

Correction : Démarrez l’environnement de récupération dans le même mode que celui prévu pour l’OS (UEFI pour un disque système GPT). Ensuite exécutez des réparations comme bcdboot.

8) Symptom: Tout a fonctionné, mais la supervision rapporte « signature de disque changée »

Cause racine : Certains outils se basent sur la signature MBR ; GPT utilise d’autres identifiants (PARTUUID/GUID).

Correction : Mettez à jour la supervision/sauvegarde pour utiliser des UUIDs de système de fichiers ou des identifiants stables plutôt que des signatures MBR.

Trois mini‑histoires du monde de l’entreprise (et ce qu’elles enseignent)

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

L’équipe avait une flotte de serveurs d’application « identiques ». Même modèle, même image OS, même automatisation. Ils devaient activer Secure Boot pour un nouveau baseline de conformité, et le plan était simple : convertir MBR en GPT, basculer en UEFI, activer Secure Boot, passer à autre chose.

Sur le premier hôte, tout a fonctionné. Sur le deuxième, il n’a pas démarré. « Aucun périphérique de démarrage. » La console distante montrait un menu de démarrage firmware avec deux disques, dont personne ne se souvenait. L’automatisation avait provisionné un petit disque secondaire des mois plus tôt pour des crash dumps. Dans le firmware, il était premier dans l’ordre de démarrage. Dans l’OS, il n’était pas monté et jamais utilisé. Dans la tête de tout le monde, il n’existait pas.

Ils avaient validé et converti le bon disque OS. L’échec était plus simple : l’ordre de démarrage firmware favorisait maintenant l’autre disque parce que l’entrée UEFI n’existait pas dessus. Le démarrage Legacy masquait ce comportement avant.

La correction était ennuyeuse : définir la bonne entrée UEFI, désactiver le démarrage depuis le disque de dump, et s’assurer que le provisioning fixait un ordre de démarrage déterministe. La leçon était claire : « Disk 0 » n’est pas un concept d’ingénierie ; c’est une commodité UI qui change quand le matériel change.

Ils ont ajouté une vérification pré‑contrôle dans l’automatisation : énumérer les disques, confirmer le serial du disque sous le volume OS, et refuser d’avancer en cas d’ambiguïté. Cela leur a pris une journée à développer. Ça les a sauvés d’une répétition à grande échelle.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait accélérer les fenêtres de maintenance. Quelqu’un a proposé de convertir depuis l’OS en cours d’exécution pour éviter de redémarrer en environnement de récupération. « C’est le même outil, ça a marché en labo. » Cette personne n’avait pas forcément tort, strictement parlant.

Ils ont lancé des conversions avec /allowFullOS en lot, une par une. La plupart ont réussi. Quelques‑unes ont échoué la validation pour des dispositions étranges — machines avec des partitions additionnelles d’anciens outils endpoints. Au lieu d’arrêter, l’opérateur a « optimisé » en supprimant à la volée la plus petite partition pour faire de la place.

Sur une machine, cette « petite partition » était une partition de récupération fournisseur contenant un environnement de diagnostic utilisé par le support distant. La supprimer n’a pas cassé le système en cours, donc ça semblait gagnant. Plus tard, un incident distinct requérait cet environnement de diagnostic, et soudain la procédure standard du support a cessé de fonctionner. Le changement de stockage n’a pas causé l’incident ; il a rendu la récupération plus lente.

Le postmortem n’était pas pour blâmer. Il visait à reconnaître une réalité : optimiser pour la vitesse tend à externaliser le risque. La réparation a été de standardiser une disposition de partitions supportée, documenter quelles partitions peuvent être supprimées, et effectuer la conversion depuis WinRE quand c’est possible pour réduire les échecs dépendants de l’état.

Ils ont quand même amélioré la vitesse — mais en rendant le processus prévisible, pas en transformant des techniciens en chirurgiens improvisés.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise financière avait une règle : tout changement affectant le démarrage nécessitait une voie de récupération testée. L’équipe ops trouvait ça fastidieux. Les ingénieurs trouvaient ça lent. Les auditeurs trouvaient ça rassurant. Tout le monde levait les yeux au ciel jusqu’au jour où ça a servi.

Pendant une conversion MBR→GPT sur une VM Windows critique, la conversion a réussi, mais la VM n’a pas démarré après la bascule en UEFI. La console hyperviseur affichait un prompt UEFI shell. Pas d’entrée « Windows Boot Manager ». Classique : bizarrerie NVRAM.

Parce que l’équipe avait suivi la check‑list ennuyeuse, ils avaient déjà WinRE attaché en tant que CD virtuel et avaient confirmé qu’ils pouvaient le démarrer en mode UEFI. Ils ont monté l’ESP, exécuté bcdboot, et recréé les fichiers de démarrage en quelques minutes. Pas de restauration nécessaire, pas de panique, pas d’indisponibilité prolongée.

La leçon : vous n’avez pas besoin de brillance pour survivre aux problèmes de démarrage. Vous avez besoin de préparation et d’un chemin de retour vers un état connu bon. La check‑list semblait bureaucratique jusqu’à ce qu’elle devienne un parachute.

FAQ

1) Puis‑je convertir MBR en GPT sans perdre de données ?

Souvent oui — des outils comme Windows mbr2gpt et Linux sgdisk --mbrtogpt sont conçus pour être non destructifs vis‑à‑vis du contenu des partitions. Mais « non destructif » n’est pas synonyme de « sans risque ». Faites une sauvegarde ou un snapshot et assurez‑vous de pouvoir récupérer le démarrage.

2) Dois‑je passer de Legacy BIOS à UEFI après la conversion ?

Pour les disques système Windows : oui, si vous voulez démarrer. Pour Linux : pas nécessairement. Linux peut démarrer en BIOS depuis GPT avec une BIOS boot partition et le bon target GRUB.

3) Quelle est la taille minimale d’une ESP ?

La pratique courante est 260 MiB sur Windows, et 260–512 MiB sur Linux si vous pouvez stocker plusieurs chargeurs/nucléis. Plus petit peut fonctionner, mais vous économisez des centimes et prenez des risques.

4) Pourquoi mbr2gpt échoue en validation alors que je n’ai « que » quelques partitions ?

Ce n’est pas que le nombre ; c’est la disposition et l’espace disponible pour l’ESP, plus les types de partitions. Les partitions OEM et de récupération peuvent vous faire dépasser les contraintes de l’outil. Corrigez la disposition, puis validez à nouveau.

5) Puis‑je faire cela sur un serveur distant sans accès console ?

Vous le pouvez. Vous ne devriez pas. Si le firmware ne bascule pas en UEFI correctement ou si les entrées de démarrage disparaissent, vous aurez besoin d’un accès console pour corriger. Si vous devez absolument le faire, organisez d’abord un accès hors bande ou des « mains distantes ».

6) La conversion en GPT va‑t‑elle améliorer les performances ?

Pas de manière significative. Il s’agit de limites de capacité, de flexibilité des partitions et d’alignement sur UEFI/Secure Boot. Si vous cherchez des performances, regardez le système de fichiers, l’ordonnanceur IO, la profondeur de file d’attente et la disposition du stockage.

7) Qu’en est‑il du RAID, Storage Spaces, LVM ou mdraid ?

En général c’est OK, mais le chemin du disque de démarrage compte. Avec un RAID matériel, vous convertissez le volume logique présenté à l’OS. Avec LVM/mdraid, préservez les secteurs de départ des partitions et soyez explicite sur la cible d’installation du chargeur.

8) Après conversion, Windows démarre mais affiche des changements « System Reserved » — dois‑je m’inquiéter ?

Attendez‑vous à un certain remaniement des partitions : une ESP est créée et les fichiers de démarrage sont déplacés. Inquiétez‑vous seulement si l’espace libre est extrêmement serré ou si des politiques exigent une disposition de partition de récupération spécifique. Validez le démarrage et les fonctions de récupération ensuite.

9) Puis‑je convertir un disque de données de MBR à GPT sans toucher au démarrage ?

Oui, et c’est moins risqué. Toujours : identifiez le bon disque, démontez‑le ou mettez‑le hors ligne si possible, et vérifiez que les applications ne dépendent pas de signatures MBR de disque.

10) Pourquoi le firmware oublie‑t‑il parfois mon entrée de démarrage Linux ?

Les entrées de démarrage UEFI vivent en NVRAM. Les mises à jour de firmware, les réinitialisations ou certains outils de sécurité peuvent les effacer ou les réordonner. Atténuez le risque avec un chargeur de secours sur l’ESP et des étapes de récupération documentées.

Étapes suivantes que vous devez vraiment faire

Si vous convertissez en production, le travail n’est pas terminé quand le disque affiche GPT. C’est terminé quand vous avez prouvé la résilience du démarrage.

1. Vérifiez le mode de démarrage après la conversion : Windows doit indiquer UEFI ; Linux doit avoir /sys/firmware/efi si vous êtes passé en UEFI.
2. Consignez ce qui a changé : disposition du disque avant/après, version de l’outil utilisée, et paramètres de firmware modifiés. Le « vous » du futur niera se souvenir.
3. Testez un second redémarrage après tout changement de politique (Secure Boot, réactivation de BitLocker, mises à jour du noyau). Un seul démarrage propre rassure ; deux en apportent la preuve.
4. Confirmez la voie de récupération : WinRE démarre en UEFI ; un live ISO Linux peut voir et monter l’ESP/root ; vous pouvez réinstaller le chargeur si nécessaire.
5. Mettez à jour l’automatisation pour détecter le mode de démarrage et le style de partition afin d’éviter une flotte mixte qui se comporte différemment lors des patchs et contrôles de conformité.

Convertissez prudemment, vérifiez impitoyablement, et traitez le démarrage comme une dépendance système — pas comme une propriété magique de « Disk 0 ».