Étendre la partition LVM racine saturée
df -h / affiche 100 % et vgs annonce encore 40.00 GiB libres dans le groupe de volumes : lvextend -l +100%FREE -r /dev/vg/root rend l’espace manquant en une commande, racine montée, sans redémarrage et sans retoucher /etc/fstab.
Sommaire
Debian 12 bookworm embarque lvm2 2.03.16-2 d’après la page lvextend(8) publiée par Debian, qui documente -r comme le redimensionnement du système de fichiers confié à fsadm(8). Ubuntu 24.04 LTS embarque lvm2 2.03.16-3ubuntu3 selon le paquet lvm2 publié par Ubuntu. Deux chiffres commandent la suite : VFree dans la sortie de vgs, LSize dans celle de lvs.
Étendre le volume logique racine en six étapes
L’extension d’une racine LVM tient en six étapes, dont une seule écrit sur le disque lorsque le groupe de volumes contient déjà des extents libres. Le cas décrit ici a été relevé sur Debian 12 bookworm (lvm2 2.03.16-2) et sur Ubuntu 24.04 LTS (lvm2 2.03.16-3ubuntu3), avec une racine ext4 montée sur /dev/mapper/vg-root. L’ordre suit la dépendance des couches : lvextend puise dans les extents libres du groupe, puis fsadm agrandit le système de fichiers pour qu’il occupe le nouveau volume. La page lvextend(8) livrée par Debian bookworm montre cette commande sous la forme lvextend -l+100%FREE -r vg01/lvol01, et le wiki Arch rappelle que la croissance se fait en ligne, racine montée comprise. Six commandes suffisent donc, à condition de mesurer avant d’écrire. Le wiki Arch conseille toutefois de laisser 256 MiB libres dans le groupe pour e2scrub(8), ce que +100%FREE ne permet pas.
- Relever l’espace disponible.
findmnt / df -h / sudo vgsÀ l’écran : findmnt indique la source de /, par exemple /dev/mapper/vg-root, et vgs affiche la colonne VFree. Une valeur de 0 impose l’étape suivante.
- Créer de l’espace dans le groupe, uniquement si VFree vaut 0. Le disque doit d’abord avoir été agrandi côté hyperviseur.
sudo growpart /dev/sda 3 sudo pvresize /dev/sda3À l’écran : growpart renvoie une ligne CHANGED avec l’ancienne et la nouvelle taille, puis pvresize termine par 1 physical volume(s) resized or updated / 0 physical volume(s) not resized.
- Étendre le volume logique et son système de fichiers d’un seul geste.
sudo lvextend -l +100%FREE -r /dev/vg/rootÀ l’écran : une première ligne donne la nouvelle taille, du type Size of logical volume vg/root changed from 20.00 GiB (5120 extents) to 60.00 GiB (15360 extents), une seconde confirme Logical volume vg/root successfully resized.
- Contrôler les deux couches.
df -h / sudo lvsÀ l’écran : la taille de / dans df -h se rapproche de LSize dans lvs. L’écart vient des métadonnées du système de fichiers et des 4 MiB de granularité des extents.
- Rattraper une extension lancée sans -r. Si df -h n’a pas bougé alors que lvs affiche un volume plus grand :
sudo resize2fs /dev/vg/rootSur une racine XFS, la commande diffère.
sudo xfs_growfs /À l’écran : resize2fs donne le nouveau nombre de blocs ; relancé, il répond The filesystem is already 5120 (4k) blocks long. Nothing to do!
- Vérifier après le redémarrage.
sudo reboot findmnt /À l’écran : findmnt / renvoie toujours /dev/mapper/vg-root, avec la nouvelle taille dans df -h /.
Une racine vidée de son espace libre se retrouve sans marge, et la prochaine extension redemandera l’étape 2. Pour garder de quoi faire tourner e2scrub(8), 256 MiB suffisent selon le wiki Arch : sur un groupe de 8 GiB libres, +95%FREE en laisse 400. Sur une racine qui contient des données uniques, une sauvegarde rsync avant lvextend coûte moins cher qu’une reprise.
Le piège : lvextend réussit et df -h ne bouge pas
Un lvextend lancé sans -r agrandit le volume logique, laisse le système de fichiers à son ancienne taille, et df -h continue d’afficher la valeur d’avant. La cause tient en une option : la page lvextend(8) réserve -r au redimensionnement du système de fichiers via fsadm(8), sans quoi LVM se contente d’allouer des extents. Rien n’est perdu et aucun redémarrage n’est nécessaire, il suffit de finir le travail à la main. Le second piège guette quand le groupe de volumes est plein : LVM refuse alors l’extension, et le message parle d’extents, pas de disque. Deux erreurs, deux remèdes distincts, et dans les deux cas les blocs déjà occupés ne sont pas touchés. Un lvextend resté sans effet sur df -h se répare avec resize2fs sur ext4 et xfs_growfs sur XFS, tandis qu’un groupe sans extents libres se répare avec growpart puis pvresize.
Le message de LVM reprend le nombre d’extents réclamés et le nombre disponible, dont la base de connaissances Red Hat publie un exemple :
Insufficient free space: 5110 extents needed, but only 0 availableTrois causes produisent ce refus : un disque jamais agrandi côté hyperviseur, une partition qui ne touche pas la fin du disque, ou un disque physique jamais rattaché au groupe. La colonne VFree de vgs tranche entre les trois, et vgextend /dev/vg /dev/sdb1 rattache un disque neuf sans toucher à la racine.
growpart échoue aussi lorsque la partition n’est pas la dernière du disque ; la base de connaissances Red Hat cite NOCHANGE: partition 1 could only be grown by -25769801728 [fudge=2048]. Le seuil –fudge documenté par growpart(1) chez Debian vaut 20480 secteurs de 512 octets, soit environ 10 MB : un gain inférieur ne déclenche aucune écriture de table de partition.
ext4, XFS et Btrfs ne se redimensionnent pas avec la même commande
Le système de fichiers posé sur la racine décide si l’option -r suffit ou s’il faut une commande séparée. Sur ext4, resize2fs(8), livré par e2fsprogs 1.47.4 en mars 2025, agrandit un système monté dès lors que le noyau et le système de fichiers gèrent le redimensionnement en ligne, ce que font les noyaux Linux 2.6 et suivants. XFS exige au contraire un système monté, et xfs_growfs(8) prend le point de montage en argument. Btrfs se redimensionne avec btrfs filesystem resize, et la page fsadm(8) du projet LVM2 énumère ext2, ext3, ext4, ReiserFS et XFS sans citer Btrfs. Un tableau vaut mieux qu’un paragraphe pour choisir, chaque ligne indiquant la commande de croissance et le sort de la réduction. Les distributions Linux concernées, Debian 12, Debian 13 et Ubuntu 24.04 LTS, livrent toutes ces commandes.
| Système de fichiers | Croissance racine montée | Commande de croissance | Redimensionnement par -r | Réduction |
|---|---|---|---|---|
| ext4 | Oui | resize2fs /dev/vg/root | Oui, via fsadm(8) | Hors ligne uniquement |
| XFS | Oui, système monté obligatoire | xfs_growfs / | Oui, via fsadm(8) | Dernier groupe d’allocation seulement |
| Btrfs | Oui | btrfs filesystem resize max / | Non documenté par fsadm(8) | Oui, en ligne |
Une divergence mérite d’être signalée : la page fsadm(8) du projet LVM2 énumère ext2, ext3, ext4, ReiserFS et XFS, alors que la page LVM du wiki Arch mentionne Btrfs parmi les systèmes gérés par -r dans un passage, tout en reprenant la liste de fsadm dans sa note détaillée. Sur une racine Btrfs, mieux vaut donc lancer lvextend sans -r, puis btrfs filesystem resize max /.
Debian 12 bookworm embarque lvm2 2.03.16-2, dont la page lvextend(8) porte la mention LVM TOOLS 2.03.16(2) du 18 mai 2022, et Debian 13 trixie passe à lvm2 2.03.31-2, daté du 27 février 2025, sans changer la syntaxe de -r. Un extent physique mesure 4 MiB par défaut selon le wiki Arch, donc 10 GiB libres font 2560 extents, jamais un compte rond au mégaoctet près. Lorsque /home vit dans la racine, un volume dédié répartit la croissance, comme le montre la création d’une partition home sur Debian.
Cinq documents font autorité sur ces commandes
Trois pages de manuel et deux sites de projet couvrent cette procédure. Celle de lvextend(8), publiée par Debian, fixe la syntaxe de -l et de -r pour lvm2 2.03.16-2 et fournit l’exemple lvextend -l+100%FREE -r vg01/lvol01. Le projet e2fsprogs documente resize2fs(8), qui agrandit un système monté et refuse de le réduire, sous la version 1.47.4 datée de mars 2025. Chez LVM2, la page fsadm(8) énumère les systèmes de fichiers que l’option -r sait traiter, et le site sourceware.org héberge les sources de lvm2 avec ses pages de manuel. Le wiki Arch documente la croissance en ligne, la granularité de 4 MiB des extents et la réserve de 256 MiB exigée par e2scrub(8). Les deux messages d’erreur reproduits plus haut viennent de la base de connaissances Red Hat, qui publie aussi la solution pour un groupe de volumes vide. Aucune de ces sources ne décrit de commande différente pour Debian 12, Debian 13 ou Ubuntu 24.04 LTS.
- lvextend(8), lvm2 2.03.16-2 sur Debian bookworm
- resize2fs(8), e2fsprogs 1.47.4
- LVM, wiki Arch
- Insufficient free space, base de connaissances Red Hat
- LVM2 Resource Page, projet LVM2
Une racine LVM agrandie ne se réduit plus sans démontage
Une racine LVM agrandie ne redevient pas plus petite sans démonter le système de fichiers, et cette contrainte décide de la taille à demander au premier essai. La page resize2fs(8) d’e2fsprogs autorise la réduction d’un ext4 uniquement lorsque le système est démonté, ce qui suppose de démarrer sur une clé ou un système de secours. Un XFS se réduit encore moins : xfs_growfs(8) ne traite que le dernier groupe d’allocation. Btrfs fait exception, sa réduction en ligne étant documentée par le wiki Arch. Le choix de la taille dépend ensuite de l’espace réellement disponible dans le groupe, de la présence d’un second disque et du système de fichiers posé sur la racine. Étendre par paliers de 10 GiB laisse une porte de sortie qu’un +100%FREE referme, et le seuil de 256 MiB du wiki Arch fixe la marge minimale à conserver pour e2scrub(8).
Faut-il acheter un disque neuf pour étendre la racine LVM ?
Non, tant que vgs affiche une colonne VFree non nulle : lvextend -l +100%FREE -r /dev/vg/root se sert alors dans les extents libres, sans matériel supplémentaire. Un disque ne devient nécessaire que si VFree vaut 0 et si la dernière partition touche déjà la fin du disque. Il se rattache avec vgextend /dev/vg /dev/sdb1, et growpart n’écrit la table de partition que si le gain dépasse 20480 secteurs, soit environ 10 MB selon growpart(1).
-r ou un redimensionnement manuel : que choisir ?
L’option -r fait tout en une passe, et la page lvextend(8) de Debian bookworm en fait la dernière de ses quatre exemples. Le manuel garde deux usages : un système de fichiers absent de la liste de fsadm(8), comme Btrfs, ou la vérification de df -h entre l’extension du volume et celle du système de fichiers. Dans le doute, lvextend -l +100%FREE -r /dev/vg/root reste la voie courte.
Comment savoir si l’espace manque dans le groupe ou dans le disque ?
vgs répond en une ligne, avec VFree pour l’espace du groupe et VSize pour sa taille totale. Quand VFree vaut 0, growpart -N /dev/sda 3 montre en simulation ce que la table de partition gagnerait, option documentée par growpart(1). Si la partition ne peut plus bouger, pvs affiche la colonne PFree et vgextend accepte un disque supplémentaire.
Peut-on réduire la racine après avoir pris trop d’espace ?
Non, pas sans démonter : resize2fs(8) ne réduit un ext4 que hors ligne, et xfs_growfs(8) ne touche qu’au dernier groupe d’allocation d’un XFS. Btrfs accepte la réduction en ligne selon le wiki Arch. Étendre par paliers de 10 GiB avec -L +10G avant de finir par -l +100%FREE évite ce retour en arrière.
Et si la racine est en Btrfs ou derrière LUKS ?
Btrfs ne figure pas dans la liste de fsadm(8), donc -r ne s’y applique pas : lancez lvextend sans redimensionnement, puis btrfs filesystem resize max /. Derrière LUKS, fsadm(8) propose -c et –cryptresize, qui redimensionnent le mapping dm-crypt en même temps que le système de fichiers. Ces deux cas exigent la version de lvm2 fournie par la distribution.