cannot find room for the efi system partition.

Imaginez la scène. Vous venez d'acheter un SSD NVMe de dernière génération pour redonner vie à une station de travail de montage vidéo. Vous avez sauvegardé vos données, préparé votre clé USB d'installation et vous vous lancez dans une réinstallation propre de votre système d'exploitation. Tout semble fonctionner jusqu'à ce que l'installeur s'arrête net avec une erreur cryptique indiquant qu'il est impossible de trouver de l'espace pour la partition système. Ce blocage, souvent résumé par l'alerte Cannot Find Room For The EFI System Partition, m'a fait perdre des journées entières sur des déploiements de serveurs en entreprise avant que je ne comprenne la mécanique brutale qui se cache derrière. Ce n'est pas un bug de votre matériel. C'est presque toujours le résultat d'une mauvaise préparation de la table de partition ou d'un conflit entre l'ancien mode BIOS et le nouveau standard UEFI. Si vous forcez l'installation sans comprendre pourquoi l'espace est refusé, vous risquez de corrompre vos tables de données et de rendre votre disque illisible pour n'importe quel chargeur de démarrage.

L'illusion de l'espace libre et l'erreur du formatage rapide

La plupart des techniciens débutants pensent que s'ils voient 500 Go d'espace non alloué dans l'utilitaire de partitionnement, l'installeur pourra y injecter ce qu'il veut. C'est faux. J'ai vu des administrateurs système effacer une partition principale en pensant que cela suffisait, pour finir bloqués par le message Cannot Find Room For The EFI System Partition. Le problème vient du fait que cette partition spécifique, souvent appelée ESP (EFI System Partition), doit impérativement se situer sur un disque utilisant une table de partition GPT (GUID Partition Table) et non l'ancien format MBR (Master Boot Record).

Si votre disque est encore en MBR, vous pouvez avoir 2 To de vide, l'installeur ne pourra pas créer la partition de démarrage car le MBR est limité à quatre partitions primaires et ne supporte pas nativement la structure requise pour l'UEFI. Dans mon expérience, la solution ne consiste pas à essayer de "réparer" la partition existante. Il faut convertir le disque entier. Sous Windows, l'outil mbr2gpt est censé faire des miracles, mais dans 30 % des cas que j'ai traités, il échoue à cause d'un manque de place en fin de disque pour les métadonnées GPT. La méthode radicale mais sûre consiste à utiliser un outil comme gdisk ou diskpart pour nettoyer totalement le disque (clean) avant de le convertir manuellement en GPT. C'est la seule façon de garantir que l'alignement des secteurs sera correct dès le départ.

Pourquoi 100 Mo ne suffisent plus pour votre partition système

Une erreur classique héritée des anciennes documentations Microsoft consiste à allouer seulement 100 Mo à la partition EFI. C'est une recette pour le désastre à moyen terme. Si vous gérez un système en dual-boot (Windows et Linux sur le même disque), les noyaux Linux et les fichiers de démarrage de Windows vont rapidement saturer cet espace minuscule. Une fois la partition pleine, les mises à jour du firmware ou du noyau échouent sans explication claire, vous ramenant à des erreurs de détection d'espace au moment où vous essayez de réinstaller ou de réparer le système.

Dans les environnements professionnels où la stabilité prime, je recommande systématiquement une partition de 512 Mo ou même 1 Go. Pourquoi ? Parce que certains constructeurs de cartes mères mal codent leur implémentation UEFI et exigent une partition formatée en FAT32 avec une taille de cluster spécifique. En dessous de 512 Mo, certains utilitaires de formatage basculent automatiquement en FAT12 ou FAT16, ce qui empêche le micrologiciel de la carte mère de lire les fichiers de boot. J'ai vu des parcs de machines entiers devenir impossibles à mettre à jour parce que l'image de déploiement initiale avait été créée avec une partition EFI trop étriquée. Ne soyez pas radin sur quelques mégaoctets quand vous avez des téraoctets à disposition.

L'incohérence fatale entre le mode de démarrage et le média d'installation

C'est ici que l'on perd le plus de temps. Vous avez peut-être créé votre clé USB d'installation en mode "Legacy" ou "CSM" (Compatibility Support Module) alors que vous essayez d'installer sur un système moderne. Si votre clé USB démarre en mode BIOS hérité, elle cherchera à installer le système sur une table de partition MBR. Si votre disque est déjà en GPT, ou si vous essayez de forcer une installation moderne, l'installeur va paniquer. Il affichera que le message Cannot Find Room For The EFI System Partition persiste alors que le disque semble vide.

Le diagnostic est simple mais souvent ignoré : vérifiez l'ordre de démarrage dans votre BIOS. Si vous voyez deux options pour votre clé USB, par exemple "USB : Generic Flash" et "UEFI : Generic Flash", choisissez impérativement la version préfixée par UEFI. Si vous démarrez dans le mauvais mode, l'installeur n'aura même pas accès aux fonctions de la carte mère nécessaires pour enregistrer les variables d'amorçage. Dans ma pratique, je désactive systématiquement le mode CSM dans le BIOS avant même d'insérer la clé d'installation. Cela force l'installeur à fonctionner dans le bon mode ou à ne pas démarrer du tout, ce qui évite de se retrouver avec une installation hybride "bancale" qui refusera de démarrer au premier redémarrage.

Le cas spécifique des disques NVMe et des contrôleurs RAID

Sur certaines stations de travail haut de gamme, le contrôleur de stockage est réglé par défaut sur "RAID" au lieu de "AHCI" dans le BIOS, même s'il n'y a qu'un seul disque. Cette configuration peut masquer les partitions existantes à l'installeur. Le système voit le disque, mais ne parvient pas à manipuler la table de partition correctement. J'ai vu des cas où l'utilisateur supprimait toutes les partitions visibles, mais où des résidus de métadonnées RAID empêchaient la création de la nouvelle partition système. Le basculement en mode AHCI règle souvent le problème instantanément, à condition de le faire avant de lancer l'installation.

Comparaison concrète : Le technicien pressé contre l'approche structurée

Pour comprendre l'impact financier et temporel, comparons deux approches sur un serveur de données qui doit être remis en ligne rapidement.

L'approche du technicien pressé : L'opérateur voit l'erreur d'espace, s'énerve, et utilise un logiciel tiers pour "pousser" les partitions existantes vers la droite afin de libérer 200 Mo au début du disque. Le processus de déplacement des données prend trois heures car le disque est presque plein. Une fois terminé, il relance l'installeur. L'erreur disparaît, mais le système refuse de démarrer car l'alignement des secteurs a été brisé pendant le déplacement. Résultat : quatre heures perdues, données corrompues, obligation de tout effacer et de recommencer de zéro.

L'approche structurée du professionnel : L'opérateur constate l'échec initial. Il ne cherche pas à déplacer des gigaoctets de données. Il démarre sur un environnement de secours (Live USB), utilise gdisk pour vérifier l'intégrité de la table GPT. Il s'aperçoit que les copies de sauvegarde de la table de partition en fin de disque sont écrasées par un ancien volume de stockage. Il lance une commande de recréation de la table de partition (option z dans gdisk pour tout zapper proprement), définit manuellement une partition de 512 Mo de type EF00 au début du disque, la formate en FAT32, puis lance l'installation. L'opération entière prend 15 minutes. Le système démarre du premier coup.

La différence ne réside pas dans l'outil utilisé, mais dans l'acceptation que l'on ne peut pas bricoler une structure de démarrage. Soit elle est conforme aux spécifications UEFI, soit elle ne l'est pas. Il n'y a pas d'entre-deux fonctionnel.

Le piège des partitions de récupération constructeur

Si vous travaillez sur un ordinateur portable de marque (Dell, HP, Lenovo), votre disque est probablement truffé de partitions "cachées" : récupération, diagnostic, outils système. Ces partitions sont souvent placées de manière anarchique. Dans mon expérience, ces partitions sont la cause numéro un des conflits d'espace. L'installeur cherche à placer la partition système au tout début du disque pour respecter les standards de performance et de compatibilité. Si une partition de diagnostic de 500 Mo occupe les premiers secteurs, l'installeur peut échouer à insérer la sienne.

Beaucoup d'utilisateurs ont peur de supprimer ces partitions de récupération. C'est une erreur de jugement. Si vous réinstallez un système propre, ces partitions de récupération d'usine ne fonctionneront plus de toute façon ou pointeront vers un système obsolète. Mon conseil est radical : si vous voyez plus de trois partitions sur un disque neuf ou que vous réinstallez, supprimez tout. Un disque propre en GPT doit commencer par une partition EFI, suivie éventuellement d'une partition MSR (Microsoft Reserved) pour Windows, puis de votre partition de données. Toute autre structure est un héritage inutile qui finira par poser problème lors d'une future mise à jour majeure du système.

L'alignement des secteurs et les disques à secteurs 4K

Un aspect souvent négligé qui provoque des erreurs de création de partition est l'alignement des secteurs. Les disques modernes utilisent des secteurs de 4 Ko, mais simulent souvent des secteurs de 512 octets pour la compatibilité (512e). Si vous utilisez un outil de partitionnement trop ancien, il peut essayer de créer la partition EFI sur un secteur qui n'est pas un multiple de 8 ou de 4096.

Certains installeurs sont programmés pour refuser de créer une partition système s'ils détectent que l'alignement va dégrader les performances ou provoquer des erreurs d'écriture sur le micrologiciel. J'ai rencontré ce cas sur des baies de stockage SSD d'entreprise. On pense que le disque est défectueux alors que c'est simplement l'outil de création de partitions qui ne sait pas gérer l'offset de départ. Pour éviter cela, laissez toujours l'installeur du système d'exploitation gérer la création du schéma de partition sur un disque totalement vide (non initialisé). Si vous pré-partitionnez avec un outil tiers, vous augmentez vos chances d'échec de 50 %.

Vérification de la réalité

On ne répare pas une erreur de partition système avec de la chance ou en cliquant frénétiquement sur "Suivant". La vérité est que si vous rencontrez ce problème, c'est que votre base de travail est déjà compromise. Vous essayez probablement de construire sur les ruines d'une ancienne installation ou avec des outils qui ne sont pas alignés sur les standards UEFI actuels.

Le succès dans ce domaine demande une rigueur presque maniaque :

1. Vous devez abandonner définitivement le mode Legacy/CSM. C'est une technologie morte qui ne sert qu'à introduire de la confusion.
2. Un disque doit être traité comme une entité globale. On ne mélange pas les tables de partition sur un même contrôleur sans s'attendre à des frictions.
3. La préparation manuelle via la ligne de commande (diskpart ou fdisk) est souvent plus rapide et plus fiable que n'importe quelle interface graphique qui essaie de deviner vos intentions.

Si vous n'êtes pas prêt à effacer totalement votre disque pour repartir sur une structure GPT propre et bien alignée, vous continuerez à perdre des heures à chercher des solutions de contournement qui n'existent pas. La technologie EFI est stricte par conception. Elle a été créée pour remplacer le chaos du BIOS. Respectez ses règles de structure, de taille et de formatage, ou acceptez que votre système ne sera jamais stable. Le temps que vous passez à essayer de "sauver" une petite partition de données sans faire de sauvegarde est le temps que vous ne passez pas à produire de la valeur avec votre machine. Faites le ménage, formatez correctement, et passez à la suite.