Linux sans magie #42 — Créer et gérer des partitions avec fdisk et parted

Dans le #41, nous avons expliqué comment une table GPT ou MBR décrit les partitions d'un disque. Maintenant, passons de l'observation à la préparation d'un disque de laboratoire. Sous Linux, deux utilitaires courants remplissent ce rôle : fdisk et parted.

L'objectif n'est pas de mémoriser des commandes destructives. Il est de comprendre sur quel objet travaille chaque commande, de reconnaître un disque approprié et de vérifier le résultat avant de créer un filesystem. L'exemple se déroule sur un fichier image de disque : aucune commande d'écriture présentée dans le lab ne vise un disque physique, un SSD ou un volume de production.

Partitionner n'est pas formater

Reprenons la chaîne étudiée dans les articles précédents :

disque ou image disque
    ↓
table de partitions (GPT / MBR)
    ↓
partitions (début, fin, type)
    ↓
filesystem (ext4, xfs, etc.)
    ↓
point de montage

Créer une partition réserve une plage d'adresses logiques dans la table de partitions. Cela ne crée pas automatiquement un filesystem ni un point de montage. Avec GPT, une entrée contient notamment un type, un identifiant unique et les limites de la partition.

Ainsi, parted ... mkpart définit une partition, mais ne lance pas mkfs.ext4. La séparation des responsabilités est importante : une opération de partitionnement réussie ne signifie pas que le nouveau volume est immédiatement montable.

`fdisk` ou `parted` ?

Critère	`fdisk`	`parted`
Usage courant	Gestion interactive d'une table	Gestion interactive ou par commandes
GPT et MBR	Oui	Oui
Consultation sans modification	`fdisk -l`	`parted ... print`
Création d'une partition	Menu interactif puis écriture explicite	`mkpart`, modification effective
Point de vigilance	`w` écrit la table	Les commandes de modification prennent effet directement

Dans fdisk, les changements de la session interactive sont en principe préparés avant l'écriture finale. q permet de quitter sans les enregistrer ; w écrit les modifications. Dans parted, il ne faut pas considérer l'invite interactive comme un simple bac à sable : une commande telle que mklabel, mkpart ou rm modifie la structure ciblée.

Les deux outils nécessitent donc la même discipline : identifier le device, disposer d'une sauvegarde lorsque des données existent et valider le résultat avec un deuxième outil.

Préparer un laboratoire isolé

Public visé : administrateurs Linux, SysOps et ingénieurs infrastructure de niveau intermédiaire.

Prérequis : terminal Linux, utilitaires fdisk, parted, truncate, stat, mktemp et rmdir. Les commandes de création de table et de partitions sont exécutées avec sudo sur un fichier image appartenant à l'utilisateur. Aucun loop device n'est nécessaire pour ce lab. Le lab suppose une distribution Linux récente prenant en charge GPT. Les noms et chemins exacts dépendent de l'hôte.

Durée indicative : 20 à 30 minutes sur une machine de laboratoire. Objectif mesurable : créer une table GPT et deux partitions dans une image, puis confirmer leurs limites avec deux outils sans formater ni monter de volume.

Conséquences : création d'un fichier image d'environ 256 MiB et modification de sa table de partitions. Ne jamais remplacer un chemin d'image par /dev/sda ou un autre disque réel sans une procédure spécifique et une autorisation explicite. Le lab ne crée pas de filesystem.

Nous créons d'abord une image dans un répertoire temporaire privé :

LAB_DIR="$(mktemp -d)"
chmod 700 "$LAB_DIR"
IMG="$LAB_DIR/disque-lab.img"
truncate -s 256M "$IMG"
printf 'Image du lab : %s\n' "$IMG"

truncate fixe la taille logique du fichier, généralement de façon clairsemée (sparse file). La création n'écrit pas 256 MiB de zéros. Le répertoire temporaire évite d'écraser accidentellement un fichier existant.

Vérification initiale :

ls -lh "$IMG"
stat -c 'Taille logique : %s octets' "$IMG"

Pour la suite, deux approches sont possibles. parted sait travailler directement sur un fichier image : c'est celle retenue ici, car elle évite d'attacher une image à un block device. Nous utiliserons ensuite fdisk -l pour la contrôler. Un loop device serait utile pour explorer les partitions comme de véritables devices, mais il n'est pas nécessaire pour atteindre l'objectif de cet article.

Étape 1 — Examiner l'image avant toute modification

Une image neuve ne contient pas encore de table GPT. Interrogeons-la :

sudo fdisk -l "$IMG"

Selon la version de fdisk, la sortie peut décrire la taille du disque sans afficher de type de table valide. Il ne faut pas interpréter cette situation comme une erreur du lab : nous n'avons encore rien écrit.

La lecture seule est notre premier point de contrôle. Elle permet de vérifier quel objet sera modifié avant de passer à une commande d'écriture.

Étape 2 — Créer une table GPT, uniquement sur l'image

La commande suivante écrit une nouvelle table GPT dans le fichier image :

sudo parted -s "$IMG" mklabel gpt

-s active le mode non interactif. mklabel gpt initialise une nouvelle table, ce qui rendrait inaccessibles d'éventuelles partitions existantes : ici, c'est acceptable uniquement parce que l'image vient d'être créée.

Attention : sur un disque en production, cette opération est potentiellement destructive. Elle ne constitue jamais une simple méthode de vérification.

Contrôlons la présence de GPT :

sudo parted -s "$IMG" print
sudo fdisk -l "$IMG"

La sortie doit indiquer un type de table gpt, sans partitions utilisateur créées pour le moment.

Étape 3 — Créer deux partitions

Nous allons découper une partie de l'image en deux plages : de 1 MiB à 96 MiB, puis de 96 MiB à 224 MiB. L'espace restant conserve une marge à la fin du disque ; les premières positions sont également réservées aux métadonnées GPT et à l'alignement.

sudo parted -s "$IMG" unit MiB mkpart data1 1 96
sudo parted -s "$IMG" unit MiB mkpart data2 96 224

Dans ce contexte GPT, data1 et data2 sont des noms de partitions. Les limites exprimées en MiB sont explicites. Il ne faut pas confondre ces noms avec un label de filesystem et les limites avec une capacité de données nette.

Vérification :

sudo parted -s "$IMG" unit MiB print
sudo fdisk -l "$IMG"

On attend deux entrées de partitions sur une table GPT. Le détail des secteurs peut varier selon la géométrie logique déclarée par l'outil ; ce sont surtout la structure, les limites et l'absence d'erreur qu'il faut contrôler.

Étape 4 — Contrôler l'alignement

Un partitionnement correct ne dépend pas seulement de la taille souhaitée. L'alignement compte aussi pour les supports modernes et certaines couches de virtualisation ou de stockage.

sudo parted -s "$IMG" align-check optimal 1
sudo parted -s "$IMG" align-check optimal 2

Les résultats sont à interpréter selon la topologie que l'outil connaît. Une image de fichier n'expose pas nécessairement toutes les caractéristiques d'un SSD ou d'une baie réelle. Le lab illustre la commande de contrôle, mais ne prétend pas simuler fidèlement la performance d'un stockage physique.

Pour étudier un disque réellement déployé, il faut aussi examiner ses paramètres de blocs logiques et physiques, puis tenir compte d'éventuelles couches LVM, RAID ou chiffrement.

Étape 5 — Comprendre ce que nous n'avons PAS créé

À ce stade, aucune commande de formatage n'a été exécutée. Les partitions existent dans la table GPT de l'image ; elles ne contiennent pas de filesystem ext4 prêt à être monté.

Il serait donc incorrect de conclure : « le disque est prêt pour la production ». Une procédure complète impliquerait ensuite, selon le besoin, la sélection d'un type de partition adapté, le filesystem, les permissions, le montage, la persistance et la sauvegarde.

Le choix du partitionnement dépend aussi de l'usage. Par exemple, une partition destinée à LVM, à un système de fichiers classique ou à une EFI System Partition ne répond pas exactement aux mêmes conventions de type.

Nous nous arrêtons volontairement avant cette étape. L'article #43 abordera les problématiques de changement de taille et les relations entre partition et filesystem.

Et `fdisk` pour créer les mêmes partitions ?

fdisk sait modifier les tables GPT. Son fonctionnement interactif convient notamment lorsqu'un opérateur veut examiner chaque choix avant l'écriture. Sur une image préparée spécifiquement pour l'exercice, le parcours typique est :

sudo fdisk /chemin/vers/image-de-lab.img
g    → nouvelle table GPT (destructif pour l'ancienne table)
n    → nouvelle partition
p    → afficher les entrées en cours
q    → quitter sans enregistrer
w    → enregistrer réellement les modifications

Ce bloc est une illustration du menu, pas une séquence à recopier directement. Les réponses interactives dépendent de la version, de la géométrie et de l'état du disque. Le geste professionnel consiste à afficher la table, vérifier les valeurs proposées et n'écrire qu'après validation.

Dans notre lab, nous avons choisi parted pour créer et fdisk -l pour contrôler : cela montre qu'on peut employer les deux outils de façon complémentaire.

Bonnes pratiques opérationnelles

Avant toute opération de partitionnement sur un environnement réel, documenter au minimum : l'identité du disque, sa taille, son numéro de série lorsqu'il est disponible, le propriétaire du service, les partitions existantes, les filesystems, les montages, les dépendances applicatives et la sauvegarde récupérable.

Une convention de nommage ne suffit jamais. /dev/sdb aujourd'hui n'est pas une garantie d'identité après un redémarrage ou un changement de contrôleur. Il faut corréler les informations de lsblk, udevadm, de l'hyperviseur ou du fournisseur de stockage selon l'environnement.

Éviter les écritures sur des périphériques montés, actifs ou contenant des données nécessaires. Préférer une fenêtre de maintenance, une sauvegarde testée, une procédure de retour arrière réaliste et une validation explicite du périmètre.

Enfin, mklabel n'est pas un moyen d'effacer sûrement des données sensibles. Modifier une table de partitions et réaliser un effacement sécurisé sont deux opérations différentes.

Nettoyage et retour arrière du laboratoire

Le retour arrière est simple parce que toutes les écritures ont eu lieu dans un fichier temporaire créé pour cet exercice. Vérifiez d'abord que la variable désigne bien ce fichier :

printf 'Répertoire : %s\nImage : %s\n' "$LAB_DIR" "$IMG"
test -f "$IMG" && sudo fdisk -l "$IMG"

Lorsque les contrôles sont terminés, supprimer uniquement ce fichier de lab avec :

rm -- "$IMG"
rmdir -- "$LAB_DIR"

Ces commandes suppriment le fichier image du laboratoire. Elles ne doivent être exécutées que lorsque les variables affichées correspondent aux chemins créés au début de l'exercice. Si rmdir indique que le répertoire n'est pas vide, ne le supprimez pas récursivement : inspectez son contenu.

Aucun service cloud payant n'est impliqué par ces commandes. L'espace temporaire et les ressources de l'hôte restent les contraintes principales.

Références officielles

fdisk(8), util-linux : https://man7.org/linux/man-pages/man8/fdisk.8.html
lsblk(8), util-linux : https://man7.org/linux/man-pages/man8/lsblk.8.html
GNU Parted, manuel utilisateur : https://www.gnu.org/software/parted/manual/parted.html
losetup(8), util-linux, pour prolonger le lab avec les loop devices : https://man7.org/linux/man-pages/man8/losetup.8.html

Conclusion

Créer une partition n'est ni créer un filesystem, ni monter un volume. fdisk et parted travaillent d'abord sur la table de partitions : ils sont utiles, mais leurs commandes d'écriture sont sensibles.

L'exercice sur image démontre une méthode reproductible : préparer un périmètre isolé, inspecter, écrire uniquement dans ce périmètre, contrôler avec deux outils, puis nettoyer. Cette discipline est plus importante que la mémorisation d'un menu.

Dans le #43, nous étudierons une opération encore plus délicate : agrandir une partition et le filesystem qu'elle contient sans confondre les deux étapes.