Le piège du « Chainboot failed! » sur disque GPT

Étape finale d’une migration NAS vers Debian : le BIOS boote le flash interne, syslinux 3.31 démarre, charge chain.c32 qui doit chainloader le disque SATA contenant Debian + GRUB. Configuration syslinux.cfg :

LABEL sata
  KERNEL chain.c32
  APPEND hd1

Sur la console série je vois enfin :

SYSLINUX 3.31 v1.07
Booting...
Chainboot failed!

Le module se charge, comprend la commande, mais refuse de chainboot. Pourquoi ?

Diagnostic

Je sors le disque SATA, branche sur PC via dock USB-SATA, vérifie le MBR :

$ dd if=/dev/sda bs=512 count=1 2>/dev/null | strings | head
GRUB
Geom
Hard Disk
Read
 Error

✓ GRUB est bien installé dans le MBR. Boot code commence par eb 63 90 = jump GRUB stage 1.

$ dd if=/dev/sda bs=1 skip=510 count=2 2>/dev/null | od -An -tx1
 55 aa

✓ Signature MBR présente.

$ dd if=/dev/sda bs=1 skip=446 count=1 2>/dev/null | od -An -tx1
 00

❌ Flag boot = 00 sur la 1ère entrée de la table MBR !

Pourquoi le flag boot manque

Le disque est en GPT (créé par sgdisk lors de mon installation Debian via debootstrap). En GPT :

• Le MBR n’a qu’une MBR Protective (une seule entrée de type 0xEE couvrant tout le disque)
• Le flag boot/active n’est pas utilisé en GPT (le boot loader cherche autre chose)
• sgdisk ne marque jamais cette entrée comme active

Mais chain.c32 v3.86 vérifie que le disque cible a au moins une partition active dans son MBR avant de booter. Sinon → Chainboot failed!. Comportement non documenté qui peut surprendre.

Solutions

A — Forcer le flag active sur la MBR Protective

printf '\x80' | sudo dd of=/dev/sda bs=1 seek=446 count=1 conv=notrunc

C’est un hack mais le flag est ignoré par GRUB et par tout OS qui lit la GPT. Sans risque.

B — Utiliser une option chain.c32 alternative

LABEL sata
  KERNEL chain.c32
  APPEND mbr=1 hd1

Le paramètre mbr=1 force le chainboot du MBR sans vérifier la table de partition.

C — Convertir en MBR DOS classique

Plus radical : faire gdisk → r → g (GPT to MBR convert). Limite à 4 partitions primaires et 2 To max. Plus simple mais moins flexible.

Lessons learned

• Le flag « active » du MBR est un héritage des PC IBM des années 80, supposé désuet en GPT. Mais certains outils (comme chain.c32 syslinux 3.x) le vérifient encore.
• GPT + MBR Protective n’a pas de partition active naturellement. C’est volontaire, mais ça casse le chainload syslinux.
• chain.c32 mbr=1 ou un set manuel du flag à 0x80 débloque la situation.
• Vérifier le MBR avec dd | strings : si on voit « GRUB », le boot code est OK. Si on voit autre chose ou rien, GRUB n’est pas installé correctement.