Réparation du démarrage GPT/MBR : corriger « Aucun périphérique de démarrage » sans perte de données

Ce que signifie vraiment « Aucun périphérique de démarrage » (et ce que ça n’est pas)

Le firmware (BIOS ou UEFI) tente de localiser une cible amorçable. Il échoue tôt, avant que votre OS ait la moindre chance d’intervenir. Ce n’est pas encore un problème du système d’exploitation ; c’est un problème de « chemin vers l’OS ».

Ce chemin diffère selon le style d’amorçage :

• Legacy BIOS + MBR : Le BIOS lit le premier secteur du disque (MBR). Le MBR pointe vers du code d’amorçage (souvent un « stage 1.5 ») puis vers le chargeur d’OS.
• Legacy BIOS + GPT (oui, ça existe) : Le BIOS ne peut pas démarrer nativement GPT ; vous avez typiquement besoin d’une partition BIOS boot pour l’image core de GRUB. Certains systèmes l’implémentent mal.
• UEFI + GPT : UEFI lit une EFI System Partition (ESP), une partition FAT32 contenant des binaires .efi. Il utilise des entrées NVRAM pour choisir quel .efi exécuter.

Quand vous voyez « Aucun périphérique de démarrage », vous êtes généralement dans l’un de ces cas :

• Le firmware regarde au mauvais endroit : mauvais ordre de démarrage, mauvais disque, mauvais mode UEFI/Legacy.
• La table de partition est correcte, mais les métadonnées d’amorçage sont cassées : fichiers ESP manquants, BCD Windows absent, installation GRUB corrompue, entrée NVRAM supprimée.
• Le disque est présent mais illisible : mode SATA changé, NVMe non détecté, mode RAID modifié, comportement anormal du contrôleur, défaillance réelle du disque.
• Quelqu’un a déjà « réparé » : et sa réparation a écrit sur le mauvais disque.

Une chose de plus : la réparation du démarrage implique des écritures. Même des outils « inoffensifs » peuvent griffonner les premiers mégaoctets. Traitez cela comme la modification des règles d’un pare-feu en production : d’abord snapshot, ensuite changer, enfin vérifier.

Faits et historique qui aident réellement à déboguer

Les problèmes d’amorçage sont plus faciles à résoudre quand on comprend pourquoi le monde est ainsi. Voici des faits concrets qui apparaissent dans des incidents réels :

1. Le MBR est petit par conception : le code d’amorçage MBR classique vit dans les 446 premiers octets du secteur 0, laissant 64 octets pour quatre entrées de partition et 2 octets pour la signature 0x55AA.
2. GPT existe parce que le MBR avait atteint ses limites : l’adressage des secteurs 32 bits du MBR plafonne autour de 2 TiB avec des secteurs de 512 octets ; GPT utilise des LBA 64 bits et n’a pas cette limite.
3. GPT conserve quand même un « protective MBR » : le secteur 0 contient souvent un MBR qui indique « une grosse partition » de type 0xEE pour que les anciens outils ne détruisent pas le disque.
4. UEFI ne « scanne pas pour un OS » comme on le suppose : il utilise des entrées NVRAM pointant vers des binaires EFI spécifiques sur un chemin disque/partition précis.
5. La partition EFI System est volontairement en FAT : FAT32 a été choisi pour la compatibilité large des firmwares, pas parce que quelqu’un l’adore.
6. Secure Boot change les modes d’échec : le disque peut être parfait et le chargeur intact, mais le firmware refuse d’exécuter un chargeur non signé (ou signé différemment).
7. Windows et Linux peuvent coexister, mais ne s’accordent pas toujours : les mises à jour Windows restaurent parfois Windows Boot Manager par défaut, tandis que les installations Linux mettent souvent GRUB en premier.
8. Le boot BIOS sur GPT est un cas spécial : GRUB a besoin d’une minuscule « partition BIOS boot » non formatée (souvent 1–2 MiB) pour y stocker des éléments qu’il ne peut pas mettre dans le trou MBR.
9. Cloner des disques peut dupliquer silencieusement les identifiants : cela casse les entrées d’amorçage et confond parfois le montage au niveau OS car le système voit « deux disques identiques ».

Playbook de diagnostic rapide (vérifier premier/deuxième/troisième)

Premier : vérification firmware (60 secondes)

• Le disque est-il détecté ? Si le BIOS/UEFI ne le voit pas, arrêtez. C’est câblage, mode contrôleur ou matériel.
• Êtes-vous en mode UEFI ou Legacy/CSM ? Le mauvais mode est la cause n°1 des incidents « le disque est OK ».
• Ordre de démarrage : si vous venez de brancher une clé USB, certains firmwares lui cèdent poliment la priorité.

Deuxième : identifier disque et style de partition (5 minutes)

• Depuis un environnement live, déterminez : GPT ou MBR ? Y a-t-il une ESP ? Y a-t-il une partition BIOS boot ? La partition OS est-elle présente ?
• Si Windows : localisez la partition EFI et la partition Windows. Si Linux : localisez /boot, /boot/efi et la racine.

Troisième : décidez ce que vous réparez (10 minutes)

• UEFI/GPT : réparer l’entrée NVRAM et/ou restaurer les fichiers EFI ; éventuellement reconstruire le BCD ou réinstaller GRUB EFI.
• BIOS/MBR : réparer le code MBR, le drapeau de partition active (pour certains montages) et la chaîne du chargeur OS.
• BIOS/GPT : assurer l’existence d’une partition BIOS boot ; réinstaller GRUB sur le disque (pas sur une partition).

Conditions d’arrêt (quand ne pas « juste essayer des choses »)

• SMART montre une défaillance évidente (sectors réalloués en hausse, erreurs de lecture). Clonez d’abord.
• Vous n’êtes pas sûr du disque. Étiquetez-les. Débranchez-les si possible.
• Le système est chiffré et vous ne connaissez pas la procédure de récupération. Réparer le démarrage est simple ; réparer « oups, j’ai cassé le seul chemin de déverrouillage » ne l’est pas.

Avant de toucher à quoi que ce soit : règles de sécurité pour éviter la perte de données

Si vous voulez « sans perte de données », vous devez le montrer.

Règle 1 : N’écrivez pas tant que vous ne pouvez pas expliquer ce que vous écrivez

Des commandes comme bootrec /FixMbr, grub-install ou efibootmgr -c ne sont pas des « diagnostics ». Elles modifient l’état du disque ou de la NVRAM. Utilisez-les seulement après avoir identifié le disque correct et le bon mode d’amorçage.

Règle 2 : Clônez ou imagez si le disque semble malade

Si le disque échoue, chaque redémarrage et chaque analyse de système de fichiers est un lancer de pièce. Faites une image vers un autre disque et travaillez sur la copie.

Règle 3 : Préférez des changements réversibles

Modifier l’ordre de démarrage UEFI, créer une nouvelle entrée NVRAM ou réinstaller un chargeur sur l’ESP est généralement réversible. Convertir GPT↔MBR sur place n’est pas une « réparation » ; c’est une migration dangereuse.

Règle 4 : Un seul disque connecté est la meilleure gestion

Si c’est un portable, vous n’aurez peut-être pas ce luxe. Sur desktops et serveurs, débranchez tous les disques non-cibles. Cela évite l’erreur classique : vous avez réparé parfaitement le mauvais disque.

Blague courte #1 : La réparation du démarrage, c’est comme une opération chirurgicale : il est facile d’être courageux quand ce n’est pas vos données sur la table.

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

Ces tâches supposent que vous avez démarré un live USB Linux (parce que c’est une bonne boîte à outils neutre) sauf si la tâche est spécifique à Windows. Les commandes sont réalistes. Les sorties sont des exemples ; les vôtres seront différentes. L’important est comment les interpréter et décider.

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

cr0x@server:~$ ls -ld /sys/firmware/efi
drwxr-xr-x 5 root root 0 Feb  4 10:12 /sys/firmware/efi

Ce que cela signifie : Si ce répertoire existe, vous tournez en mode UEFI. S’il n’existe pas, vous êtes en mode Legacy BIOS.

Décision : Adaptez le mode de réparation au mode dans lequel l’OS a été installé. Si Windows a été installé en UEFI mais que vous avez démarré le live USB en Legacy, vous courrez après des fantômes.

Task 2: Identify disks and partition tables quickly

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE PARTTYPE                             PARTLABEL    MOUNTPOINTS
nvme0n1   476.9G disk
├─nvme0n1p1   260M part vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System
├─nvme0n1p2    16M part        e3c9e316-0b5c-4db8-817d-f92df00215ae Microsoft reserved
├─nvme0n1p3   200G part ntfs   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 Basic data
└─nvme0n1p4 276.6G part ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 Linux filesystem

Ce que cela signifie : Les GUID de type de partition GPT apparaissent dans PARTTYPE. L’ESP est en vfat et porte le GUID EFI reconnu.

Décision : C’est un système UEFI/GPT. La réparation du démarrage se concentrera sur l’ESP et les entrées UEFI, pas sur les drapeaux « actif » du MBR.

Task 3: Verify GPT vs MBR with parted (more explicit)

cr0x@server:~$ sudo parted -s /dev/nvme0n1 print
Model: Samsung SSD 970 (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  274MB   273MB   fat32        EFI System Partition          boot, esp
 2      274MB   291MB   16.8MB               Microsoft reserved partition  msftres
 3      291MB   215GB   215GB   ntfs         Basic data partition          msftdata
 4      215GB   512GB   297GB   ext4                                       

Ce que cela signifie : Partition Table: gpt et les flags boot, esp indiquent la partition EFI System.

Décision : Ne perdez pas de temps avec des commandes de réparation MBR. Vous devrez peut-être monter l’ESP et restaurer des fichiers de chargeur.

Task 4: Check whether the ESP contains plausible boot files

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ ls -R /mnt/esp/EFI | head
/mnt/esp/EFI:
Boot
Microsoft
ubuntu

/mnt/esp/EFI/Boot:
BOOTX64.EFI

Ce que cela signifie : Vous avez des répertoires standards. EFI/Boot/BOOTX64.EFI est le chemin de secours que de nombreux firmwares essaieront si les entrées NVRAM sont manquantes.

Décision : Si /mnt/esp/EFI est vide ou manque Microsoft/ubuntu, vous avez probablement une corruption ou suppression de l’ESP. La réparation sera « restaurer des fichiers », pas « repartitionner le disque ».

Task 5: Inspect UEFI NVRAM boot entries (UEFI systems)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0000,0001
Boot0000* Windows Boot Manager  HD(1,GPT,3c4b2c2e-...,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0001* ubuntu                HD(1,GPT,3c4b2c2e-...,0x800,0x82000)/File(\EFI\ubuntu\shimx64.efi)
Boot0002* UEFI: USB Flash Disk  PciRoot(0x0)/Pci(0x14,0x0)/USB(0x3,0x0)/HD(1,MBR,0x1234,0x800,0x3a9800)

Ce que cela signifie : Des entrées existent pour Windows et Ubuntu. C’est bon signe. Si votre système indique encore « Aucun périphérique de démarrage », il se peut que vous ayez démarré en mode Legacy, ou que le disque ne soit pas détecté au démarrage, ou que Secure Boot bloque le chargeur.

Décision : Si l’entrée Windows Boot Manager manque, recréez-la. Si les entrées existent mais pointent vers le mauvais GUID disque (commun après clonage), corrigez-les ou utilisez le chemin de secours.

Task 6: Recreate a missing Windows Boot Manager entry (UEFI)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Windows Boot Manager" -l '\EFI\Microsoft\Boot\bootmgfw.efi'
BootCurrent: 0002
BootOrder: 0003,0002,0000,0001
Boot0003* Windows Boot Manager  HD(1,GPT,3c4b2c2e-...,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)

Ce que cela signifie : Vous avez créé une nouvelle entrée NVRAM pointant vers le binaire Microsoft EFI sur la partition 1.

Décision : Redémarrez et sélectionnez-la dans le firmware. Si elle démarre, vous avez fini. Si le firmware oublie l’entrée après redémarrage, suspectez une pile CMOS faible/bug firmware ou un « Fast Boot » problématique ; comptez sur le chemin de secours ou les mises à jour du firmware.

Task 7: Check for BIOS/MBR boot flags and “active” partition (legacy systems)

cr0x@server:~$ sudo fdisk -l /dev/sda
Disk /dev/sda: 500 GiB, 536870912000 bytes, 1048576000 sectors
Disklabel type: dos
Device     Boot    Start        End    Sectors   Size Id Type
/dev/sda1  *        2048  1026047  1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2        1026048 1048575999 1047549952 499.5G 7 HPFS/NTFS/exFAT

Ce que cela signifie : Disklabel type dos indique MBR. Le * marque la partition active (bootable)—pertinent pour certaines chaînes d’amorçage BIOS.

Décision : S’il n’y a pas de partition active dans une configuration BIOS/Windows, définissez-la (avec précaution) sur la partition système/réservée, pas sur la partition de données.

Task 8: Set the active flag on the correct partition (MBR)

cr0x@server:~$ sudo fdisk /dev/sda
Command (m for help): a
Partition number (1-2): 1
Command (m for help): p

Device     Boot    Start        End    Sectors   Size Id Type
/dev/sda1  *        2048  1026047  1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2        1026048 1048575999 1047549952 499.5G 7 HPFS/NTFS/exFAT

Command (m for help): w
The partition table has been altered!

Ce que cela signifie : Vous avez basculé le drapeau bootable.

Décision : Redémarrez et testez. Si le démarrage échoue toujours, vous aurez probablement besoin de réparer le code d’amorçage (MBR/VBR/BCD) plutôt que les drapeaux.

Task 9: Assess disk health before writing boot structures

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "Reallocated|Pending|Uncorrect|SMART overall"
SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0

Ce que cela signifie : Pas de signes évidents de défaillance média. « PASSED » n’est pas une garantie, mais ce n’est pas alarmant non plus.

Décision : Procédez à la réparation du démarrage. Si des secteurs en attente étaient non nuls, clonez d’abord et évitez les outils générant beaucoup d’écritures.

Task 10: Clone a disk before repairs when you smell trouble

cr0x@server:~$ sudo ddrescue -f -n /dev/sda /dev/sdb /mnt/recovery/ddrescue.log
GNU ddrescue 1.27
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:        0 B,  errsize:        0 B,  errors:       0
Current status
rescued:  500000 MB,  errsize:      0 B,  current rate:  120 MB/s
ipos: 500000 MB,  errors:       0,    average rate:  115 MB/s
Finished

Ce que cela signifie : Vous avez copié le disque source vers un disque destination en journalisant la récupérabilité. ddrescue est conçu pour les médias imparfaits.

Décision : Faites toutes les réparations d’amorçage ultérieures sur /dev/sdb (la copie). Gardez /dev/sda intact comme preuve originale.

Task 11: Mount Linux system partitions correctly for chroot repair

cr0x@server:~$ sudo mount /dev/nvme0n1p4 /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done
cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# ls /boot/efi/EFI
Boot  Microsoft  ubuntu

Ce que cela signifie : Vous opérez dans l’environnement de l’OS installé, avec l’ESP monté là où l’OS s’attend à le trouver.

Décision : C’est le contexte correct pour réinstaller GRUB ou régénérer initramfs sans corrompre l’environnement du live USB.

Task 12: Reinstall GRUB for UEFI systems (Linux)

cr0x@server:~$ sudo chroot /mnt /bin/bash -c "grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu && update-grub"
Installing for x86_64-efi platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
done

Ce que cela signifie : Le binaire EFI de GRUB et la configuration ont été installés, et il a détecté Windows aussi.

Décision : Redémarrez et choisissez « ubuntu » ou définissez l’ordre de démarrage. Si Secure Boot est activé et que vous avez installé un GRUB non signé, vous devrez peut-être ajouter des paquets shim ou désactiver temporairement Secure Boot.

Task 13: Install GRUB for BIOS/MBR systems (Linux)

cr0x@server:~$ sudo chroot /mnt /bin/bash -c "grub-install /dev/sda && update-grub"
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-31-generic
done

Ce que cela signifie : GRUB est installé dans la zone de démarrage MBR du disque (pas sur une partition), et la config a été reconstruite.

Décision : Redémarrez. Si ça échoue encore, vérifiez que le BIOS est effectivement configuré pour démarrer depuis /dev/sda et que le disque est en première position.

Task 14: Detect GPT/BIOS boot partition requirement (Linux on GPT in BIOS mode)

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

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB   ext4
 2      538MB   1000GB  999GB   ext4

Ce que cela signifie : Disque GPT, mais pas de petite partition avec le flag bios_grub. Le boot BIOS de GRUB sur GPT nécessite typiquement cela.

Décision : Si la machine démarre en mode Legacy, créez une partition BIOS boot de 1–2 MiB (non formatée) et définissez le flag bios_grub—seulement si vous pouvez réduire/déplacer des partitions en toute sécurité. Si vous pouvez passer le firmware en mode UEFI, faites-le plutôt. C’est plus propre.

Task 15: Windows UEFI: rebuild BCD from recovery environment

Depuis l’invite de récupération Windows (pas Linux), vous assignez habituellement une lettre à l’ESP et reconstruisez les fichiers d’amorçage. Exemple :

cr0x@server:~$ diskpart
DISKPART> list vol
Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
----------  ---  -----------  -----  ----------  -------  ---------  --------
Volume 0     C                NTFS   Partition    200 GB  Healthy    Boot
Volume 1          SYSTEM      FAT32  Partition    260 MB  Healthy    System

DISKPART> sel vol 1
DISKPART> assign letter=S
DISKPART> exit

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

Ce que cela signifie : bcdboot a copié les fichiers d’amorçage Windows sur l’ESP et a construit un magasin BCD adapté à l’UEFI.

Décision : Redémarrez et mettez Windows Boot Manager en premier dans le firmware si nécessaire. Si ça échoue, l’ESP peut être mal montée, ou l’installation Windows n’est pas réellement à C:\Windows en mode récupération—vérifiez les lettres de lecteurs.

Task 16: Windows BIOS/MBR: repair boot chain (carefully)

cr0x@server:~$ bootrec /FixMbr
The operation completed successfully.
cr0x@server:~$ bootrec /FixBoot
Access is denied.
cr0x@server:~$ bootrec /RebuildBcd
Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  D:\Windows
Add installation to boot list? Yes(Y)/No(N)/All(A): Y
The operation completed successfully.

Ce que cela signifie : /FixMbr a écrit le code d’amorçage MBR. /FixBoot échouant avec « Access is denied » est courant sur certaines versions de Windows et peut indiquer des permissions de partition/une confusion d’ESP (surtout quand on est en réalité sur UEFI/GPT) ou un environnement de récupération inadapté.

Décision : Si vous êtes vraiment en BIOS/MBR, assurez-vous que la partition système correcte est active et possède un secteur d’amorçage ; parfois bootsect /nt60 SYS est utilisé. Si le disque est GPT, arrêtez d’utiliser les outils BIOS et passez à la réparation UEFI (bcdboot).

Task 17: Verify filesystem integrity on the ESP (FAT can get weird)

cr0x@server:~$ sudo umount /mnt/esp
cr0x@server:~$ sudo fsck.vfat -a /dev/nvme0n1p1
fsck.fat 4.2 (2021-01-31)
FATs differ but appear to be intact. Using first FAT.
Reclaimed 12 unused clusters (49152 bytes) in 3 chains.

Ce que cela signifie : Incohérences FAT mineures réparées. S’il signale une corruption sévère, il faudra peut-être recréer l’ESP et restaurer les fichiers d’amorçage.

Décision : Après réparation, remontez et vérifiez à nouveau le contenu du répertoire EFI.

Voies de réparation selon la plateforme et le style d’amorçage

UEFI + GPT : le « standard moderne »

C’est la plupart des portables et desktops de la dernière décennie. Votre récupération tourne autour de trois choses : partitions disque, fichiers sur l’ESP, et entrées NVRAM.

• Si le disque n’est pas détecté dans le firmware : ce n’est pas un problème de chargeur. Vérifiez le mode contrôleur (AHCI vs RAID), les réglages NVMe, le câblage, les mises à jour firmware.
• Si l’ESP existe mais est vide/endommagé : restaurez EFI/Microsoft via bcdboot (Windows) ou réinstallez GRUB (Linux). Utilisez fsck.vfat pour les corruptions mineures.
• Si l’ESP est OK mais les entrées d’amorçage manquent : recréez-les avec efibootmgr (Linux) ou laissez la réparation Windows les recréer (Récupération Windows).
• Si les entrées existent mais pointent vers un mauvais ID disque (après clonage) : créez de nouvelles entrées référant le bon disque/partition, puis supprimez les anciennes.
• Si Secure Boot bloque : utilisez des paquets shim/GRUB signés, enregistrez les clés appropriées, ou désactivez temporairement Secure Boot pour confirmer le diagnostic.

Legacy BIOS + MBR : toujours présent dans des appliances et anciens systèmes

Cette voie concerne moins les fichiers et plus les petits segments de code d’amorçage. Vos cibles :

• Le code d’amorçage MBR (premier secteur)
• Le secteur d’amorçage de la partition (VBR) pour la partition active (Windows) ou la configuration de GRUB (Linux)
• Le BCD (Windows) ou la config GRUB (Linux)

L’erreur la plus risquée ici est d’installer le code d’amorçage sur le mauvais disque. Sur des systèmes multi-disques, il est courant de « réparer » le disque de données tandis que le disque OS reste intact et offusqué.

Legacy BIOS + GPT : « n’y touchez que si nécessaire »

Ça peut fonctionner, mais c’est fragile et se casse souvent après des déplacements de disque ou des basculements de firmware. Si vous héritez d’un tel système, le meilleur résultat est généralement de passer au démarrage UEFI si le matériel le permet. Sinon, il vous faudra une partition BIOS boot et une installation GRUB correctement effectuée sur le disque.

Ce qu’il ne faut pas faire : conversions sur place pendant une panne

Convertir MBR↔GPT est possible. C’est aussi un projet différent de la « réparation du démarrage », surtout si vous cherchez à préserver les données. Ne le faites qu’avec des sauvegardes et un contrôle de changement. Si votre objectif est de démarrer aujourd’hui, n’entreprenez pas une aventure format/convert.

Blague courte #2 : Les entrées NVRAM UEFI sont comme les paramètres d’imprimante : tout le monde est sûr que c’est simple jusqu’à ce que ce soit la seule chose entre vous et une échéance.

Trois mini-histoires d’entreprise tirées de la vie réelle

Incident n°1 : la mauvaise hypothèse (« Le disque est mort »)

Un portable revenu du terrain avait « Aucun périphérique de démarrage ». L’utilisateur jurait que c’était arrivé après une décharge de batterie. Le helpdesk a d’abord pensé « SSD mort », parce que c’est un récit simple et tout le monde aime remplacer des pièces.

Quelqu’un a remplacé le SSD. Toujours pas de démarrage. Le récit est devenu « carte mère défaillante », car si le nouveau SSD ne démarre pas, la machine doit être maudite. Le ticket a tourné pendant un jour alors que la date butoir de l’utilisateur approchait.

Quand ça a atterri chez un SRE déjà brûlé par ce type de problème, la première étape a été humiliantement simple : confirmer si le firmware était en mode UEFI. Il ne l’était pas. Un reset du BIOS l’avait basculé en Legacy/CSM. L’installation Windows d’origine était UEFI/GPT. En mode Legacy, le firmware cherchait une signature MBR, n’en trouvait pas et abandonnait.

Rétablissez le firmware en UEFI, Windows Boot Manager réapparaît, la machine démarre. Le SSD « mort » était en fait bon. Le SSD remplacé est devenu un nouveau problème : il a dû être effacé et renvoyé en stock.

Leçon : Ne supposez pas qu’« Aucun périphérique de démarrage » signifie défaillance de stockage. Cela signifie souvent que le firmware regarde par la mauvaise porte.

Incident n°2 : optimisation qui se retourne contre vous (l’ESP « golden image »)

Une équipe fleet voulait accélérer le provisioning. Ils ont créé une image « golden » clonée : même layout GPT, même OS, mêmes apps. C’était rapide. En labo ça marchait. Puis ils ont déployé sur des portables en série.

Une semaine plus tard : des machines au hasard présentant « Aucun périphérique de démarrage » après une mise à jour firmware. Pas toutes. Juste assez pour que ce soit intéressant. Le pattern était confus : surtout des machines récemment ré-imagées.

Cause racine : le processus de clonage a dupliqué les identifiants de disque et laissé des entrées NVRAM UEFI pointant vers une identité disque/partition spécifique qui n’était pas stable à travers la série. Certains firmwares toléraient et « rescannaient ». D’autres non. Après mise à jour, la NVRAM a été nettoyée et le chemin de secours n’était pas correctement peuplé, donc les machines n’avaient aucun pointeur valide vers un binaire EFI.

La réparation n’a rien de magique. Elle est prosaïque : après imagerie, exécutez toujours une étape post-déploiement qui garantit que l’ESP a un chargeur de secours correct et enregistre proprement les entrées d’amorçage pour cet appareil. Et n’espérez pas que tous les firmwares se comportent pareil.

Leçon : Le démarrage est d’état. Le clonage marche jusqu’à ce qu’il ne marche plus—et quand cela arrive, c’est au pire moment : le premier démarrage après un changement.

Incident n°3 : la pratique ennuyeuse et correcte qui a sauvé la situation (imagerie d’abord)

Un ingénieur base de données a signalé un poste de travail qui a cessé de démarrer après une coupure de courant. Il contenait des jeux de données locaux pas bien sauvegardés. L’impulsion immédiate dans la pièce fut de « lancer bootrec » parce que c’est rapide et donne l’impression d’agir.

La personne stockage a posé une question : « SMART dit quoi ? » Il a montré des secteurs en attente. Pas énormément, mais assez. Le disque n’était pas mort ; il était peu fiable. Chaque lecture supplémentaire pouvait être la lecture qui le rendrait irrécupérable.

Ils ont imager le disque avec ddrescue vers un SSD sain, en utilisant un fichier de log pour pouvoir relancer les zones problématiques sans relire les zones bonnes. Ce n’est qu’ensuite qu’ils ont réalisé des réparations d’amorçage sur la copie. La copie a démarré après une réparation EFI et une reconstruction du BCD. Le disque original a ensuite empiré, comme prévu.

Rien d’héroïque dans le processus. Juste de la discipline : préserver la preuve, travailler sur une copie, vérifier les résultats. Cette discipline a sauvé les données et évité le post-mortem gênant « on a réparé le démarrage mais perdu vos fichiers ».

Leçon : S’il y a le moindre indice d’un problème disque, copiez d’abord. La réparation d’amorçage est bon marché ; la récupération de données est coûteuse.

Un maxime opérationnel à garder (idée paraphrasée) vient de Richard Cook : Les systèmes complexes réussissent parce que les gens s’adaptent continuellement et corrigent des problèmes cachés.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: « Aucun périphérique de démarrage » juste après un reset BIOS ou une mise à jour firmware

Cause racine : Mode d’amorçage basculé (UEFI ↔ Legacy/CSM), ou ordre de démarrage réinitialisé.

Correctif : Remettez le mode que l’OS utilisait à l’installation. Si GPT + ESP existe, utilisez le mode UEFI. Restaurez l’ordre de démarrage vers Windows Boot Manager ou votre entrée GRUB.

2) Symptom: Le disque apparaît dans un live USB Linux mais pas dans le menu de démarrage firmware

Cause racine : Entrée d’amorçage UEFI manquante ; le firmware n’utilise que les entrées enregistrées et ignore le chemin de secours, ou le chemin ESP est incorrect.

Correctif : Utilisez efibootmgr -v pour inspecter les entrées ; créez une nouvelle entrée pointant vers \EFI\Microsoft\Boot\bootmgfw.efi ou \EFI\ubuntu\shimx64.efi. Assurez-vous que le chemin de secours \EFI\Boot\BOOTX64.EFI existe.

3) Symptom: Les outils de réparation Windows râlent « Access is denied » sur FixBoot

Cause racine : Souvent vous êtes en réalité sur UEFI/GPT et utilisez la mauvaise voie de réparation, ou la partition système n’est pas celle que vous croyez.

Correctif : Préférez bcdboot C:\Windows /s S: /f UEFI après avoir assigné une lettre à l’ESP. Vérifiez quel volume est l’ESP (FAT32, « System »).

4) Symptom: Invite GRUB rescue, « unknown filesystem »

Cause racine : GRUB ne trouve pas ses modules/config à cause de partitions déplacées, image core écrasée, ou /boot manquant.

Correctif : Démarrez un Linux live, montez root et boot, chroot, réinstallez GRUB (UEFI : --target=x86_64-efi ; BIOS : installez sur le disque), puis update-grub.

5) Symptom: Système dual-boot démarre désormais directement sous Windows

Cause racine : Une mise à jour Windows a mis Windows Boot Manager en premier dans l’ordre, ou a réécrit l’entrée par défaut.

Correctif : Réorganisez via l’interface firmware ou efibootmgr -o. Si l’entrée GRUB manque, réinstallez GRUB sur l’ESP et recréez l’entrée.

6) Symptom: Après clonage, le système ne démarre que lorsque l’ancien disque est connecté

Cause racine : L’entrée d’amorçage pointe vers le disque original. Le clone a une identité différente (GUID de partition différent).

Correctif : Créez de nouvelles entrées UEFI pointant vers le clone. Envisagez de supprimer les doublons et d’utiliser le chemin de secours EFI/Boot.

7) Symptom: « Aucun périphérique amorçable » seulement quand des clés USB sont insérées

Cause racine : L’ordre de démarrage privilégie les médias amovibles ou traite une clé insérée comme première option, mais elle n’est pas amorçable.

Correctif : Ajustez l’ordre de démarrage ; désactivez « boot from USB » si la politique le permet ; ou assurez-vous que la clé est réellement amorçable.

8) Symptom: Linux démarre, Windows absent de GRUB

Cause racine : os-prober désactivé par la politique de la distribution, ou la partition Windows inaccessible (BitLocker verrouillé, hibernation, ou fast startup).

Correctif : Désactivez le démarrage rapide Windows ; déverrouillez BitLocker si nécessaire ; activez et lancez os-prober si approprié, puis régénérez la config GRUB.

Listes de vérification / plan étape par étape

Checklist A: Flux à risque minimal pour « Aucun périphérique de démarrage » (générique)

1. Entrez dans le setup firmware : confirmez que le disque est détecté.
2. Confirmez le mode d’amorçage : UEFI vs Legacy. Ne devinez pas.
3. Définissez l’ordre de démarrage sur le disque/entrée correct (Windows Boot Manager, ou votre entrée Linux).
4. Démarrez un live USB dans le même mode (UEFI ou BIOS) que l’OS installé.
5. Identifiez disques et partitions (lsblk, parted).
6. Si SMART est mauvais, clonez avec ddrescue d’abord.
7. Montez l’ESP et inspectez les répertoires EFI.
8. Inspectez et corrigez les entrées UEFI (efibootmgr) ou les drapeaux MBR (fdisk).
9. Réparez le chargeur :
   • Windows UEFI : bcdboot
   • Windows BIOS : bootrec (et vérifications de partition active)
   • Linux UEFI : grub-install --target=x86_64-efi
   • Linux BIOS : grub-install /dev/sdX
10. Redémarrez une fois. Vérifiez. Ne faites pas dix boucles de réparation ; c’est comme ça qu’on perd la trace de l’état.

Checklist B: Réparation UEFI/GPT quand l’ESP existe mais l’entrée manque

1. Montez l’ESP et vérifiez que le .efi cible existe.
2. Créez une nouvelle entrée avec efibootmgr -c en la pointant.
3. Optionnel : créez/vérifiez le chemin de secours : \EFI\Boot\BOOTX64.EFI.
4. Réglez l’ordre de démarrage pour mettre la nouvelle entrée en premier.
5. Redémarrez et confirmez.

Checklist C: Flux « Je ne fais pas confiance à ce disque » (données d’abord)

1. Démarrez un live USB, n’exécutez pas encore de réparations de système de fichiers.
2. Vérifiez SMART ; si des secteurs en attente/incorrigibles apparaissent, arrêtez.
3. Clonez avec ddrescue vers un nouveau disque.
4. Déconnectez le disque original.
5. Réparez l’amorçage sur la copie.
6. Après restauration du démarrage, sauvegardez correctement les données. Ne vivez pas sur la copie comme si de rien n’était.

FAQ

1) Puis-je réparer « Aucun périphérique de démarrage » sans réinstaller l’OS ?

En général oui. La plupart du temps les partitions OS sont intactes et seules les métadonnées d’amorçage sont cassées : mauvais mode firmware, entrée UEFI manquante, ESP endommagé, BCD cassé, ou GRUB corrompu.

2) Comment savoir si le disque est GPT ou MBR ?

Depuis Linux : parted -s /dev/sdX print affiche « Partition Table: gpt » ou « msdos. » Depuis Windows : diskpart → list disk affiche un * sous GPT pour les disques GPT.

3) Quel est le moyen le plus rapide pour savoir que je suis en mauvais mode d’amorçage ?

Si le disque est GPT et a une ESP, mais que le firmware est en Legacy/CSM, vous obtenez souvent « Aucun périphérique de démarrage. » À l’inverse, une installation MBR/BIOS ne démarrera pas en pur mode UEFI sans un chargeur UEFI.

4) Est-il sûr d’exécuter bootrec ou grub-install ?

C’est sûr quand vous savez quel disque vous ciblez et que vous avez décidé que c’est la réparation correcte. C’est dangereux en mode tâtonnement, surtout sur des systèmes multi-disques. Si le disque est défaillant, clonez d’abord.

5) Pourquoi UEFI oublie parfois des entrées d’amorçage ?

La NVRAM peut être réinitialisée par des mises à jour firmware, des resets BIOS, ou par un firmware buggy. Certains systèmes se comportent mal quand les identifiants de disque changent après clonage. Avoir un chargeur de secours valide à \EFI\Boot\BOOTX64.EFI aide.

6) Dois-je recréer l’EFI System Partition si elle est corrompue ?

Pas toujours. Une corruption FAT mineure peut être réparée avec fsck.vfat. Si l’ESP est manquante, gravement endommagée, ou que la table de partition a été modifiée, vous devrez peut-être la recréer et restaurer les fichiers d’amorçage (Windows : bcdboot ; Linux : grub-install).

7) Qu’en est-il de BitLocker ou du chiffrement total du disque ?

Le chiffrement change vos priorités. Vous pouvez souvent réparer l’EFI/chargeur sans toucher aux volumes chiffrés, mais assurez-vous d’avoir les clés de récupération et de comprendre la chaîne de démarrage. Ne « repartitionnez » pas pour réparer.

8) Mon système est en double amorçage et maintenant un seul OS apparaît. Ai-je perdu l’autre OS ?

Pas nécessairement. Les menus de démarrage sont des pointeurs. L’autre OS est généralement encore présent ; il faut réparer la config GRUB ou restaurer l’ordre/entrées UEFI corrects.

9) Dois-je convertir MBR en GPT (ou inverse) pour réparer le démarrage ?

Non, pas en première option. Les incompatibilités de mode et les fichiers d’amorçage manquants sont bien plus courants. La conversion est un changement contrôlé qui nécessite sauvegardes et planification.

10) Quand dois-je arrêter les réparations et appeler du hardware ?

Si le disque n’est pas détecté dans le firmware, si SMART montre des erreurs de lecture/pending sectors en augmentation, ou si vous ne pouvez pas lire les partitions de façon fiable depuis un live, considérez une défaillance matérielle. Imagez d’abord, puis récupérez.

Conclusion : étapes pratiques suivantes

Les défaillances d’amorçage semblent dramatiques parce que le système reste silencieux, mais la réparation est souvent ennuyeuse : le firmware est dans le mauvais mode, l’ESP manque des fichiers, ou l’entrée d’amorçage pointe vers nulle part.

Faites cela ensuite, dans l’ordre :

1. Confirmez la détection du disque et le mode d’amorçage dans le firmware.
2. Démarrez un environnement live dans le même mode que l’OS installé.
3. Identifiez GPT vs MBR, puis localisez l’ESP/les partitions système.
4. Si le disque semble instable, clonez avec ddrescue et réparez la copie.
5. Réparez la couche correcte : entrées UEFI + fichiers ESP pour UEFI/GPT ; MBR/partition active/BCD ou GRUB pour BIOS/MBR.
6. Redémarrez une fois, vérifiez, puis faites une vraie sauvegarde. Un chargeur réparé n’est pas une stratégie de sauvegarde.