Créer une clé USB bootable qui démarre vraiment (UEFI/Legacy correctement)

Le modèle mental : ce que « bootable » signifie vraiment

Quand on dit « créer une clé USB bootable », on entend généralement : « Mettre une ISO sur une clé pour que le firmware la repère, charge un chargeur d’amorçage, et que celui-ci charge un noyau ou un programme d’installation. » Cette phrase cache trois systèmes indépendants qui peuvent chacun échouer séparément :

• Le média USB et le partitionnement : la clé présente-t-elle une table de partitions et des systèmes de fichiers lisibles par le firmware ?
• Le chemin de démarrage du firmware : UEFI ou BIOS (Legacy). Chacun a des attentes différentes concernant les partitions, le secteur de boot et la disposition des fichiers.
• La chaîne du chargeur d’amorçage : exécutable EFI, GRUB/syslinux, gestionnaire de démarrage Windows, etc. Il doit correspondre au mode de la machine (UEFI vs Legacy) et à l’architecture CPU.

La fiabilité vient du contrôle des variables. « J’ai utilisé un outil graphique et ça a marché une fois » n’est pas du contrôle. Le contrôle, c’est : vérifier l’ISO, l’écrire dans un mode adapté au type d’ISO, confirmer la disposition des partitions de la clé et confirmer que la machine tente le bon mode de démarrage.

Autre chose : votre firmware n’est pas votre ami. C’est un bibliothécaire trop sûr de lui avec un système de classement strict et aucune empathie. Vous étiquetez correctement les livres ou vous n’obtenez pas de service.

Faits intéressants et contexte historique

Savoir pourquoi les choses sont comme elles sont vous évite de deviner. Voici quelques éléments historiques concrets qui apparaissent dans les problèmes de démarrage actuels :

1. Le démarrage BIOS vient de disques sans partitions du tout. Le modèle original du secteur d’amorçage précède le partitionnement moderne. C’est pourquoi « code d’amorçage dans les 446 premiers octets » compte encore en 2026.
2. La table de partitions MBR a toujours été étroite. Quatre partitions primaires semblaient généreuses jusqu’à ce que ça ne le soit plus ; c’est une des raisons des partitions étendues, et aussi pourquoi on migre vers GPT.
3. UEFI a standardisé le démarrage comme « charger un exécutable EFI depuis un système de fichiers ». C’est un changement majeur : le firmware peut lire des FAT et exécuter des fichiers comme BOOTX64.EFI.
4. La « partition système EFI » (ESP) est généralement en FAT32 pour une raison. FAT est simple et largement supporté par les firmwares, contrairement à ext4, NTFS ou autres systèmes de fichiers avec journalisation.
5. Secure Boot n’est pas du chiffrement ; c’est une enforcement de signatures. Il refuse d’exécuter des binaires EFI non signés par des clés que le firmware reconnaît.
6. Les ISO hybrides existent parce que les fournisseurs voulaient une image pour plusieurs chemins de démarrage. Certaines ISO Linux sont des images ISO9660 avec des tables de partitions intégrées, donc on peut les dd directement sur un USB.
7. Le média d’installation Windows a des contraintes sur FAT32 et la taille de fichier. Le fichier install.wim peut dépasser 4 Gio, ce que FAT32 ne peut pas contenir ; beaucoup d’outils scindent le WIM ou utilisent NTFS—avec des conséquences pour la compatibilité UEFI.
8. Les entrées de démarrage UEFI peuvent être « collantes » et trompeuses. La NVRAM du firmware garde des entrées qui pointent vers des périphériques inexistants, d’où des options fantômes et une fausse confiance.
9. Les clés USB mentent. Certaines se déclarent « disque fixe » vs « amovible » et cela change le comportement des outils Windows ; certains contrôleurs sont instables lors d’écritures soutenues et corrompent silencieusement les données.

Une citation à garder sur votre bureau :

« idée paraphrasée » — Gene Kranz : la discipline rigoureuse et des procédures claires préviennent des échecs évitables.

Choisir votre méthode de création USB (et pourquoi)

Méthode A : écriture brute de l’ISO (meilleur pour les ISO Linux hybrides)

Si l’ISO est conçue pour être écrite « telle quelle » sur l’USB (commun pour les installateurs Linux), la méthode la plus fiable est l’écriture brute. Vous clonez la disposition de l’image testée par la distribution. Pas d’interprétation créative par un outil. Pas de « formatage utile » qui casse le démarrage UEFI.

Utilisez ceci quand :

• L’ISO est un installateur Linux moderne et le fournisseur prend explicitement en charge dd ou l’imagerie brute.
• Vous voulez une chaîne de traçabilité simple : checksum → écriture → démarrage.

Évitez ceci quand :

• Vous préparez un média d’installation Windows à partir d’une ISO (écrire brutement les ISO Windows produit généralement pas la clé bootable attendue).
• Vous avez besoin d’un stockage persistant sur la même clé sans étapes supplémentaires.

Méthode B : copier des fichiers sur un ESP préparé correctement (meilleur quand vous contrôlez la disposition)

Pour le démarrage UEFI, ce qui compte est : une partition FAT32 contenant \EFI\BOOT\BOOTX64.EFI (ou l’équivalent pour l’architecture). Vous pouvez la construire délibérément. C’est idéal quand vous avez besoin de chargeurs d’amorçage personnalisés, d’arguments noyau spécifiques, ou quand vous construisez un média de secours dans un environnement contrôlé.

Méthode C : utiliser un outil multiboot (style Ventoy) quand vous privilégiez la flexibilité

Ces outils installent un chargeur une fois, puis vous copiez des ISO en tant que fichiers. C’est pratique et souvent fonctionnel, mais pas magique. Certains environnements Secure Boot le bloquent, quelques firmwares bizarres le détestent, et certaines ISO nécessitent un traitement spécial.

C’est l’option « emporter beaucoup d’outils ». Idéale pour le travail de terrain. Pas mon premier choix pour un environnement soumis à conformité stricte.

Blague #1 : une clé USB bootable, c’est comme un parachute — si c’est « probablement correct », vous apprendrez quelque chose de nouveau très vite.

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

Voici des tâches testées sur le terrain. Chaque tâche inclut la commande, une sortie d’exemple, ce que signifie la sortie et la décision à prendre. Exécutez-les sur Linux ; si vous êtes sur macOS ou Windows, transposez les idées, pas la syntaxe.

Tâche 1 : identifier correctement le périphérique USB (avant de détruire un disque)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,TRAN,RM,FSTYPE,MOUNTPOINTS
NAME   SIZE MODEL            TRAN RM FSTYPE MOUNTPOINTS
sda   953.9G Samsung_SSD      sata  0        
├─sda1  512M                  0    vfat   /boot/efi
├─sda2  200G                  0    ext4   /
└─sda3  753G                  0    ext4   /var
sdb    28.9G SanDisk_Ultra     usb  1        
└─sdb1 28.9G                   1    exfat  /media/cr0x/USB

Ce que cela signifie : sdb est amovible (RM=1) et sur un transport USB. C’est votre clé cible.

Décision : Si la cible n’est pas clairement un périphérique USB amovible, arrêtez. Relancez la commande avec la clé débranchée/rebranchée pour confirmer la différence.

Tâche 2 : confirmer qu’aucune partition de la cible n’est montée

cr0x@server:~$ mount | grep -E '^/dev/sdb'
/dev/sdb1 on /media/cr0x/USB type exfat (rw,nosuid,nodev,relatime)

Ce que cela signifie : Le système d’exploitation utilise activement le système de fichiers.

Décision : Démontez avant l’imagerie ; sinon vous risquez la corruption et le message « ça a écrit mais ça ne démarre pas ».

Tâche 3 : démonter proprement

cr0x@server:~$ sudo umount /dev/sdb1
cr0x@server:~$ echo $?
0

Ce que cela signifie : Le code de sortie 0 signifie succès.

Décision : Si le démontage échoue pour cause de « busy », fermez les gestionnaires de fichiers, les terminaux qui sont cd dedans, ou utilisez lsof pour trouver les bloqueurs.

Tâche 4 : vérifier la somme de contrôle de l’ISO (ne pas déboguer un téléchargement corrompu)

cr0x@server:~$ sha256sum ubuntu-24.04.1-live-server-amd64.iso
d7b1e3c3f8f2b6d7d8a4c1c6f0d2a0b3a4d7c5a0b8f2e1d3c4b5a6f7e8d9c0b1  ubuntu-24.04.1-live-server-amd64.iso

Ce que cela signifie : Vous avez un hash déterministe à comparer avec la valeur publiée par le fournisseur.

Décision : Si ça ne correspond pas, supprimez et retéléchargez. Ne « lancez pas quand même ». C’est comme ça qu’on gaspille des après-midis.

Tâche 5 : inspecter si l’ISO est une image hybride (indice pour écriture brute)

cr0x@server:~$ file ubuntu-24.04.1-live-server-amd64.iso
ubuntu-24.04.1-live-server-amd64.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Ubuntu-Server 24.04.1 LTS amd64'

Ce que cela signifie : « DOS/MBR boot sector » suggère une ISO hybride avec des structures d’amorçage intégrées.

Décision : Préférez l’écriture brute (dd ou équivalent) pour ce type d’image.

Tâche 6 : écrire brut l’ISO sur l’USB (Linux)

cr0x@server:~$ sudo dd if=ubuntu-24.04.1-live-server-amd64.iso of=/dev/sdb bs=4M conv=fsync status=progress
1562378240 bytes (1.6 GB, 1.5 GiB) copied, 32 s, 48.8 MB/s
2971666432 bytes (3.0 GB, 2.8 GiB) copied, 61 s, 48.7 MB/s
4026531840 bytes (4.0 GB, 3.8 GiB) copied, 83 s, 48.5 MB/s
4630511616 bytes (4.6 GB, 4.3 GiB) copied, 96 s, 48.2 MB/s
1103+1 records in
1103+1 records out
4630511616 bytes (4.6 GB, 4.3 GiB) copied, 96.1312 s, 48.2 MB/s

Ce que cela signifie : L’image a été écrite complètement, et conv=fsync force la vidange des données.

Décision : Après dd, ne retirez pas la clé immédiatement. Laissez udev se stabiliser, puis validez la disposition.

Tâche 7 : forcer le noyau à relire la table de partitions

cr0x@server:~$ sudo partprobe /dev/sdb
cr0x@server:~$ lsblk -f /dev/sdb
NAME   FSTYPE FSVER LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdb                                                                   
├─sdb1 iso9660      Ubuntu-Server 2024-08-28-14-10-41-00             0     100%  
└─sdb2 vfat   FAT16 UEFI_BOOT   2A1B-3C4D                            

Ce que cela signifie : Vous avez maintenant une partition ISO9660 et une petite partition FAT pour le démarrage UEFI. C’est typique de nombreuses images hybrides.

Décision : Si vous ne voyez pas de partition FAT alors que vous attendez le démarrage UEFI, inspectez l’ISO ; certaines images sont réservées au Legacy ou reposent sur d’autres structures.

Tâche 8 : confirmer que le chemin de secours UEFI existe sur la clé

cr0x@server:~$ sudo mkdir -p /mnt/usb-uefi
cr0x@server:~$ sudo mount /dev/sdb2 /mnt/usb-uefi
cr0x@server:~$ sudo find /mnt/usb-uefi/EFI -maxdepth 2 -type f
/mnt/usb-uefi/EFI/BOOT/BOOTX64.EFI
/mnt/usb-uefi/EFI/BOOT/grubx64.efi

Ce que cela signifie : Un firmware qui ne peut ou ne veut pas utiliser les entrées NVRAM peut quand même démarrer via le chemin par défaut \EFI\BOOT\BOOTX64.EFI.

Décision : Si BOOTX64.EFI manque, le démarrage UEFI est probablement mort sur place à moins que le fournisseur n’offre un chemin différent et que vous n’ajoutiez manuellement une entrée.

Tâche 9 : valider que l’ISO a été écrite correctement en échantillonnant des octets

cr0x@server:~$ sudo cmp -n 1048576 ubuntu-24.04.1-live-server-amd64.iso /dev/sdb && echo "first 1MiB matches"
first 1MiB matches

Ce que cela signifie : Le début du périphérique correspond à l’ISO. Cela détecte un nombre surprenant de problèmes causés par des « contrôleurs qui mentent ».

Décision : Si ça diffère, essayez un autre port USB, désactivez la mise en veille sélective USB, ou remplacez la clé. Déboguer un périphérique à 8 $ est un hobby, pas des opérations.

Tâche 10 : vérifier GPT vs MBR sur l’USB (aide à expliquer le comportement du firmware)

cr0x@server:~$ sudo fdisk -l /dev/sdb | sed -n '1,20p'
Disk /dev/sdb: 28.9 GiB, 31016853504 bytes, 60579840 sectors
Disk model: SanDisk Ultra
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6e9b2a1c

Ce que cela signifie : Cette clé utilise un label MBR (« dos »). Beaucoup d’ISO hybrides en font usage.

Décision : Si vous avez besoin de GPT explicitement (certains firmwares d’entreprise se comportent mieux), envisagez une méthode de copie de fichiers avec une table de partitions GPT et une ESP FAT32.

Tâche 11 : créer un GPT délibéré + ESP FAT32 (pour un média UEFI personnalisé)

cr0x@server:~$ sudo wipefs -a /dev/sdb
cr0x@server:~$ sudo parted -s /dev/sdb mklabel gpt
cr0x@server:~$ sudo parted -s /dev/sdb mkpart ESP fat32 1MiB 1025MiB
cr0x@server:~$ sudo parted -s /dev/sdb set 1 esp on
cr0x@server:~$ sudo mkfs.vfat -F32 -n UEFI_INSTALL /dev/sdb1
mkfs.fat 4.2 (2021-01-31)

Ce que cela signifie : Vous avez maintenant une partition FAT32 de la taille d’une ESP avec le drapeau GPT correct.

Décision : Utilisez ceci lorsque vous construisez un média manuellement (binaires EFI personnalisés, shims signés, environnement de secours spécifique au fournisseur).

Tâche 12 : copier le chargeur d’amorçage EFI dans le chemin de secours

cr0x@server:~$ sudo mount /dev/sdb1 /mnt/usb
cr0x@server:~$ sudo mkdir -p /mnt/usb/EFI/BOOT
cr0x@server:~$ sudo cp BOOTX64.EFI /mnt/usb/EFI/BOOT/BOOTX64.EFI
cr0x@server:~$ sudo ls -l /mnt/usb/EFI/BOOT
total 1312
-rwxr-xr-x 1 root root 1343488 Feb  4 09:10 BOOTX64.EFI

Ce que cela signifie : Le firmware dispose d’un emplacement standard où regarder, indépendamment de l’état de la NVRAM.

Décision : Si vous supportez du matériel mixte, incluez toujours le chemin de secours. C’est une assurance peu coûteuse.

Tâche 13 : vérifier que la machine a démarré en mode UEFI (depuis l’environnement live)

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

Ce que cela signifie : Linux expose les services runtime UEFI via /sys/firmware/efi.

Décision : Si vous attendiez UEFI mais avez Legacy, arrêtez de blâmer l’USB. Corrigez la sélection du mode de démarrage dans le firmware.

Tâche 14 : inspecter les entrées de démarrage UEFI existantes (utile quand le firmware est confus)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0007,0003,0001
Boot0001* ubuntu	HD(1,GPT,2f1c...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0003* UEFI: SanDisk, Partition 2	PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/HD(2,MBR,0x6e9b2a1c,0x3a00,0x8000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0007* UEFI: Built-in EFI Shell	FvFile(7C04...)

Ce que cela signifie : Le firmware voit le chemin EFI de l’USB, et vous pouvez confirmer lequel a réellement démarré (BootCurrent).

Décision : Si l’entrée USB n’existe pas mais que la clé contient \EFI\BOOT\BOOTX64.EFI, utilisez le menu de démarrage ponctuel ; certains firmwares ne l’enregistrent pas automatiquement.

Tâche 15 : détecter l’état de Secure Boot (cause fréquente d’échec instantané)

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Ce que cela signifie : Les binaires EFI non signés ne s’exécuteront pas sauf si des clés inscrites le permettent.

Décision : Si votre USB utilise un chargeur non signé, soit désactivez Secure Boot pour l’installation, soit utilisez une chaîne basée sur un shim signé.

UEFI vs Legacy : comment la machine décide quoi démarrer

Démarrage Legacy BIOS en un paragraphe

Le BIOS Legacy regarde le premier secteur du disque (MBR) et exécute le code qui s’y trouve. Ce code trouve ensuite un « next stage » quelque part. C’est pourquoi des détails minutieux — comme où le chargeur attend de trouver stage2 — importent. C’est aussi pourquoi le type de système de fichiers n’importe pas directement pour le BIOS au départ : le BIOS ne lit pas les fichiers ; il exécute du code d’amorçage.

Démarrage UEFI en un paragraphe

UEFI lit les partitions, monte un système de fichiers (généralement FAT) et charge un exécutable EFI. Il peut le faire via des entrées NVRAM (chemins explicites) ou via le chemin de secours \EFI\BOOT\BOOTX64.EFI. UEFI est plus propre, mais les implémentations firmware varient énormément, surtout autour du support des systèmes de fichiers et du comportement sur média amovible.

Règles de compatibilité clés à suivre

• Si vous voulez démarrer en UEFI partout : fournissez une partition FAT32 contenant \EFI\BOOT\BOOTX64.EFI.
• Si vous voulez démarrer en Legacy partout : assurez-vous d’avoir un code MBR valide, et que le chargeur supporte le mode BIOS.
• Si vous voulez les deux : utilisez des ISO hybrides fournies par le vendeur, ou construisez un média qui prend en charge les deux chaînes. Ne supposez pas qu’un média « compatible UEFI » démarrera en Legacy, ou inversement.
• Ne mélangez pas les modes pendant l’installation. Installer un OS en mode UEFI requiert en général une ESP sur le disque cible ; installer en Legacy utilise des secteurs d’amorçage différents. Le mélange conduit à la tragédie classique « installé mais ne démarre pas ».

Blague #2 : les menus de configuration du firmware sont le seul endroit où « Enregistrer & Quitter » ressemble à une menace.

Secure Boot : quand « marche » devient « bloqué »

Secure Boot est la raison pour laquelle une clé USB démarre bien sur un serveur plus ancien mais s’effondre sur un portable plus récent avec image d’entreprise. Le firmware vérifie les signatures des binaires EFI avant de les exécuter. Si le binaire n’est pas signé par une clé de confiance, il ne s’exécutera pas. Certains firmwares affichent un message ; d’autres refusent silencieusement et passent à l’option de démarrage suivante, ce qui ressemble à « clé USB non détectée ». Elle a été détectée. Elle a été rejetée.

Que faire en environnements réels

• Pour les installateurs Linux grand public : utilisez des images qui incluent un shim signé et un GRUB signé. La plupart le font.
• Pour des outils de secours personnalisés : signez vos binaires EFI et inscrivez votre clé (MOK ou DB du firmware), ou prévoyez une procédure contrôlée de désactivation de Secure Boot.
• Pour les médias Windows : respectez la procédure de création officielle, car les composants de démarrage Windows sont signés et doivent correspondre.

En entreprise, désactiver Secure Boot peut être interdit sauf procédure d’urgence. Dans ce cas, la méthode de création de la clé n’est pas une préférence personnelle ; c’est une contrainte de conformité.

Trois mini-récits d’entreprise (anonymisés, plausibles et techniquement réels)

Incident n°1 : la mauvaise hypothèse (UEFI c’est « en gros du BIOS, non ? »)

Une entreprise de taille moyenne a déployé une nouvelle flotte de portables pour les développeurs. L’équipe d’image a fabriqué une clé USB interne « golden » d’installation Linux. Elle démarrait sur le banc de test, qui était composé de quelques anciens desktops configurés en Legacy BIOS parce que c’est ce que le banc avait toujours eu.

Sur les nouveaux portables, la clé apparaissait dans le menu de démarrage ponctuel — deux fois même : une fois « UEFI: USB » et une fois « USB HDD ». Les techniciens ont choisi celle qui sonnait familière. « USB HDD » était rassurant. Elle a démarré sur un écran noir puis est revenue au menu. Ils ont conclu que l’image était mauvaise.

Ils ont reconstruit la clé. Même résultat. Ils ont essayé différentes clés. Même résultat. Le vrai problème : les portables étaient configurés pour interdire complètement le démarrage Legacy. « USB HDD » était le chemin Legacy. L’entrée UEFI fonctionnait, mais seulement si elle était sélectionnée. Personne n’avait dit à l’équipe d’image que la nouvelle flotte était UEFI-only et Secure Boot activé.

Une fois qu’ils ont choisi « UEFI: USB », l’installateur s’est lancé immédiatement. La correction opérationnelle a été : mettre à jour le runbook pour indiquer explicitement de choisir l’entrée UEFI, et mettre à jour le processus d’imagerie pour vérifier /sys/firmware/efi dans l’environnement live avant de continuer. Le postmortem n’a pas été « les gens devraient mieux savoir ». Il a été « nous avons livré un processus qui dépendait du savoir tribal ».

Incident n°2 : une optimisation qui s’est retournée contre eux (NTFS pour la vitesse, UEFI pour les ennuis)

Une autre organisation a construit des clés USB d’installation Windows pour un programme de renouvellement interne. Quelqu’un a remarqué que formater en FAT32 était plus lent et échouait parfois quand le install.wim dépassait 4 Gio. L’« optimisation » a été de formater la clé en NTFS et de copier les fichiers, parce que NTFS gère les gros fichiers et que copier est plus rapide que d’écrire une image.

Ça a marché sur la plupart des desktops. Puis ça a atteint un lot de petites machines avec un firmware qui refusait de démarrer UEFI depuis NTFS sur média amovible. Le menu listait la clé, mais la sélectionner ramenait juste au menu. Les techniciens ont blâmé le lot matériel et ont ouvert un dossier fournisseur.

La réponse du fournisseur a été ennuyeuse : « le firmware UEFI n’est obligé de supporter que FAT pour le démarrage amovible. » Le support NTFS est optionnel. Leurs appareils ne l’avaient pas implémenté. L’« optimisation » était en fait une régression de compatibilité. La flotte avait désormais deux classes de matériel, et la clé fonctionnait sur une seule.

La correction a aussi été ennuyeuse : revenir au FAT32 et scinder le WIM, ou utiliser un outil qui construit une clé à deux partitions (petite ESP FAT32 pour le boot + partition NTFS pour les gros fichiers d’installation) avec un chargeur capable de lire NTFS. La leçon du postmortem : les optimisations de vitesse qui changent le format du système de fichiers ne sont pas des optimisations ; ce sont des décisions produit avec un rayon d’impact.

Incident n°3 : la pratique ennuyeuse qui a sauvé la situation (checksums et modèle connu bon)

Une équipe de services financiers gardait un kit USB « break-glass » pour la récupération des serveurs. Le kit incluait une ISO rescue Linux validée et deux modèles de clés USB spécifiques achetés en lot. Le runbook exigeait de vérifier le hash de l’ISO, puis d’écrire l’image en brut, puis de vérifier le premier MiB avec cmp.

Cela ressemblait à de la cérémonie. Et ça a marché.

Lors d’une panne moche, ils devaient démarrer une machine dont le chargeur d’amorçage était corrompu après un remplacement de disque raté. La première clé qu’ils ont prise ne démarravaient pas. Au lieu de paniquer, l’astreignant a suivi le runbook : ils ont vérifié la disposition de la clé, confirmé le mode UEFI, et testé la clé sur un second hôte. Elle échouait aussi là-bas.

Ils ont passé à la seconde clé — même ISO, même procédure — et elle a démarré immédiatement. La première clé était physiquement défaillante. Parce qu’ils avaient des étapes de vérification déterministes et un modèle de clé connu bon, ils n’ont pas perdu une heure à se rejeter la faute. Ils ont restauré le chargeur d’amorçage et terminé l’incident. La leçon n’était pas sexy : redondance et vérification sur les « petites choses » réduisent le MTTR comme rien d’autre.

Mode opératoire de diagnostic rapide

Ceci est l’ordre qui trouve rapidement le goulot d’étranglement. Ne jouez pas les improvisateurs. Suivez la chaîne de « le firmware le voit-il » à « peut-il l’exécuter » à « le chargeur peut-il continuer ».

Première étape : confirmer le mode et la politique de démarrage de la machine

• Vérifiez les réglages du firmware : le Legacy est-il désactivé ? Secure Boot est-il activé ? le démarrage USB est-il autorisé ?
• Dans le menu de démarrage : voyez-vous des entrées séparées pour UEFI et Legacy pour la même clé ?
• Décision : Si l’environnement est UEFI-only, arrêtez d’essayer des médias Legacy. Si Secure Boot est appliqué, arrêtez d’essayer des chargeurs non signés.

Deuxième étape : confirmer que l’USB a été écrit correctement (pas « copié » incorrectement)

• Vérifiez la somme de contrôle de l’ISO.
• Confirmez la disposition de la clé avec lsblk et fdisk -l.
• Confirmez la présence de \EFI\BOOT\BOOTX64.EFI pour le démarrage UEFI.
• Décision : Si la disposition est incorrecte, recréez la clé en utilisant la méthode adaptée à cette ISO.

Troisième étape : déterminer dans quelle classe d’échec vous êtes

• USB non listée du tout : matériel/port, démarrage USB désactivé dans le firmware, clé morte.
• USB listée mais retourne au menu : rejet Secure Boot, EFI d’architecture erronée, chemin de secours manquant, firmware incapable de lire le système de fichiers.
• Le chargeur démarre puis échoue : écriture corrompue, fichiers manquants, noyau/initrd non concordants, mauvaise config, ISO corrompue.
• L’installateur démarre mais ne voit pas les disques : pilotes de stockage, mode RAID/HBA, VMD, RST, ou abstraction constructeur — pas un problème d’USB.

Quatrième étape : valider depuis un environnement live fonctionnel

• Confirmez le mode avec /sys/firmware/efi.
• Vérifiez l’état de Secure Boot avec mokutil.
• Inspectez les entrées de démarrage UEFI avec efibootmgr (si installé).
• Décision : Si votre mode n’est pas celui attendu, corrigez cela avant toute autre chose.

Erreurs courantes : symptôme → cause racine → correction

1) Symptomatique : la clé USB n’apparaît pas dans le menu de démarrage

Cause racine : démarrage USB désactivé, port défectueux (les ports avant/hubs USB peuvent être instables), clé morte, ou le firmware n’énumère l’USB qu’au démarrage à froid.

Correction : Activez le démarrage USB dans le firmware ; essayez un port arrière de la carte mère ; essayez un port USB 2.0 si disponible (certains firmwares râlent sur l’initialisation USB 3.x) ; coupez l’alimentation complètement ; testez la clé sur un autre hôte.

2) Symptomatique : la clé apparaît, mais la sélectionner ramène immédiatement au menu

Cause racine : rejet par Secure Boot, BOOTX64.EFI manquant, architecture EFI incorrecte (x86_64 vs ARM64), ou UEFI ne peut pas lire le système de fichiers (NTFS/exFAT).

Correction : Utilisez FAT32 pour l’ESP ; assurez-vous que \EFI\BOOT\BOOTX64.EFI existe ; utilisez une chaîne de démarrage signée ou désactivez Secure Boot (si autorisé) ; assurez-vous d’avoir l’ISO pour l’architecture matérielle correcte.

3) Symptomatique : démarre sur une machine, pas sur une autre

Cause racine : l’une démarre en Legacy, l’autre en UEFI ; ou l’une applique Secure Boot ; ou l’un des firmwares supporte NTFS pour le boot et l’autre non.

Correction : Standardisez sur le démarrage UEFI et une ESP FAT32 avec chemin de secours ; documentez quelle entrée du menu sélectionner ; évitez les hypothèses de démarrage UEFI uniquement NTFS.

4) Symptomatique : GRUB démarre, puis « unknown filesystem » ou « file not found »

Cause racine : écriture partielle, clé défectueuse, ou configuration GRUB pointant vers le mauvais UUID/périphérique parce que la disposition média diffère.

Correction : Recréez la clé avec écriture brute ; vérifiez avec cmp ; remplacez le matériel suspect ; évitez de « remixer » manuellement le contenu de l’ISO à moins de comprendre la configuration du chargeur.

5) Symptomatique : la clé d’installation Windows démarre en Legacy mais pas en UEFI

Cause racine : clé formatée en NTFS sans ESP FAT32 ; le firmware exige FAT32 pour démarrer UEFI sur média amovible.

Correction : Construisez le média Windows avec une partition de démarrage FAT32 ; si les fichiers dépassent 4 Gio, scindez le WIM ou utilisez une approche à deux partitions avec une partition FAT32 de boot.

6) Symptomatique : l’installateur démarre, mais le disque cible n’est pas visible

Cause racine : mode du contrôleur de stockage (RAID/VMD/RST), pilote manquant, ou NVMe derrière une abstraction constructeur.

Correction : Ajustez le mode de stockage dans le BIOS (AHCI vs RAID) selon le besoin ; chargez le pilote constructeur dans l’installateur ; mettez à jour le firmware ; validez avec lspci et lsblk dans l’environnement live. Réécrire l’USB cinq fois ne résoudra pas ça.

Listes de contrôle / plan pas à pas

Plan A : fabriquer une clé d’installation Linux qui démarre UEFI de façon fiable (recommandé)

1. Téléchargez l’ISO et la valeur de somme de contrôle fournie par le fournisseur.
2. Vérifiez la somme avec sha256sum. En cas de mismatch : retéléchargez.
3. Identifiez le périphérique USB avec lsblk. Confirmez qu’il est amovible et que la taille correspond.
4. Démontez les partitions sur ce périphérique.
5. Écrivez l’ISO en brut avec dd en utilisant conv=fsync.
6. Relisez les partitions avec partprobe et confirmez la disposition.
7. Confirmez que le fichier de démarrage UEFI existe : montez la partition FAT et vérifiez \EFI\BOOT\BOOTX64.EFI.
8. Testez sur deux machines : une moderne UEFI-only et une plus ancienne en mode mixte. Notez quelle entrée du menu fonctionne.

Plan B : construire une clé UEFI personnalisée (pour média de secours ou outils internes)

1. Commencez avec un modèle de clé connu bon. Achetez-en plusieurs. Sérieusement.
2. wipefs -a le périphérique pour supprimer les signatures conflictuelles.
3. Créez GPT, puis une partition ESP FAT32 (au moins 512 MiB ; je préfère 1 GiB par commodité).
4. Placez votre binaire EFI à \EFI\BOOT\BOOTX64.EFI.
5. Si Secure Boot est activé dans votre environnement, assurez-vous que le binaire EFI est correctement signé ou fournissez une chaîne shim signée.
6. Validez sur une machine de test avec efibootmgr -v et en sélectionnant « UEFI: USB » dans le menu ponctuel.

Plan C : supporter UEFI et Legacy sans douleur

1. Préférez les ISO hybrides du fournisseur qui supportent explicitement les deux modes.
2. Si vous devez personnaliser : construisez des clés séparées UEFI et Legacy, étiquetez-les physiquement et arrêtez de prétendre qu’une seule clé satisfait tous les cas bord.
3. Documentez quel mode est requis pour installer l’image OS que vous déployez (UEFI recommandé). Faites-le respecter dans la checklist d’installation.

Checklist d’hygiène opérationnelle (les choses ennuyeuses)

• Gardez une clé « connue bonne » scellée comme contrôle.
• Conservez les hash dans votre runbook interne pour les images approuvées.
• Consignez les réglages firmware requis (politique Secure Boot, politique Legacy boot, mode SATA/RAID).
• Lors du débogage, changez une variable à la fois. L’univers punit les suppositions parallèles.

FAQ

1) Pourquoi l’écriture brute d’une ISO crée parfois plusieurs partitions ?

Parce que beaucoup d’ISO d’installateur sont des images « hybrides » qui incluent des tables de partitions (souvent MBR, parfois GPT). Écrites sur un disque, l’OS voit ces partitions.

2) Pourquoi ne puis-je pas simplement copier le fichier ISO sur une clé et la démarrer ?

Le firmware ne démarre généralement pas depuis un fichier ISO posé sur un système de fichiers quelconque. Il démarre via des secteurs d’amorçage (Legacy) ou des exécutables EFI sur une partition FAT (UEFI). Les outils multiboot ajoutent un chargeur capable de comprendre les ISO ; le firmware simple ne le fait pas.

3) GPT ou MBR pour une clé USB bootable ?

Pour UEFI, GPT avec une ESP est propre et prévisible. Pour le BIOS Legacy, MBR importe. Les ISO hybrides Linux utilisent souvent MBR car c’est très compatible. Si vous construisez un média personnalisé pour des flottes modernes, GPT + ESP FAT32 est généralement le bon défaut.

4) Ma clé est en FAT32 mais ne démarre toujours pas en UEFI. Pourquoi ?

Raisons communes : \EFI\BOOT\BOOTX64.EFI manquant, mauvaise architecture (ARM vs x86_64), Secure Boot rejetant le binaire, ou firmware buggy qui exige la clé insérée avant la mise sous tension.

5) Secure Boot est activé. Dois-je le désactiver pour démarrer des installateurs Linux ?

Non, pas forcément. Beaucoup d’installateurs mainstream incluent un shim signé et un chargeur signé compatibles Secure Boot. Les binaires EFI personnalisés ne le seront pas à moins que vous ne les signiez et que le firmware fasse confiance à la clé de signature.

6) Pourquoi le menu de démarrage affiche-t-il deux entrées pour la même clé ?

L’une est le chemin UEFI et l’autre est Legacy/CSM. Choisissez celle qui correspond au mode d’installation souhaité. Si vous voulez une installation UEFI, choisissez l’entrée étiquetée UEFI.

7) L’installateur démarre, mais après l’installation la machine ne démarre pas. La clé est-elle en faute ?

Généralement non. C’est typiquement un mauvais mode d’installation (installé en Legacy sans MBR correct, ou installé en UEFI sans ESP), ou un problème d’ordre de démarrage/NVRAM du disque cible. Vérifiez si l’installateur a tourné en mode UEFI et si le disque cible possède une ESP.

8) Pourquoi certaines méthodes de création de clé Windows échouent sur certains PC ?

UEFI est obligé de supporter FAT pour le boot amovible, mais pas NTFS. Une clé Windows reposant sur le boot NTFS peut fonctionner sur certains firmwares et échouer sur d’autres.

9) exFAT est-il un bon choix pour les clés bootables ?

Pour le démarrage UEFI : en général non. Beaucoup d’implémentations firmware ne démarrent pas depuis exFAT. Utilisez FAT32 pour la partition de boot.

10) Quel est le meilleur contrôle de bon sens une fois la clé écrite ?

Montez l’ESP (ou la partition FAT) et confirmez que \EFI\BOOT\BOOTX64.EFI existe. Testez ensuite la clé sur une seconde machine. Si elle ne fonctionne que sur un seul hôte, vous n’avez pas fini.

Conclusion : prochaines étapes pratiques

Si vous voulez une clé USB bootable qui démarre vraiment, arrêtez de la traiter comme un loisir créatif. Traitez-la comme un artefact de déploiement. Vérifiez l’entrée (somme de contrôle), utilisez la méthode de création adaptée au type d’ISO, et confirmez le contrat face au firmware : une disposition de partitions utilisable et un chemin de secours UEFI valide.

Actions concrètes à faire aujourd’hui :

• Choisissez un modèle de clé USB approuvé et achetez-en une petite quantité. Retirez les clés mystère.
• Standardisez les installations sur UEFI à moins d’avoir une exigence Legacy défendable.
• Ajoutez trois vérifications à votre runbook : correspondance sha256sum, sanity lsblk, et présence de \EFI\BOOT\BOOTX64.EFI.
• Quand ça échoue, suivez le mode opératoire de diagnostic rapide dans l’ordre. L’objectif est l’isolation rapide, pas le bidouillage héroïque.

La meilleure clé USB bootable est celle que vous avez testée la semaine dernière sur deux machines différentes, pas celle que vous « avez faite une fois et laissée dans un tiroir ». Les firmwares changent. Les gens changent. Les tiroirs sont éternels.