Je comprends mieux, effectivement c’était un abus de langage je pensé répertoire mais j’ai écris partition 
On ne réduit pas un disque physique. Même si on réduit ses partitions, cela ne change pas sa taille. Certes, on peut réduire sa capacité apparente avec hdparm -N s’il supporte la fonctionnalité HPA mais je ne pense pas que tu fasses allusion à cela. Je ne connais pas VMware converter, ni dans quelle mesure cela fait une différence sur le résultat que le disque physique soit entièrement occupé par des partitions ou pas.
Si tu veux réduire le PV LVM (la partition sda5), il faut :
- réduire le système de fichiers racine (démonté) dans /dev/MUFASA-vg/root avec resize2fs à la taille souhaitée
- réduire le volume logique /dev/MUFASA-vg/root avec
lvreduceà une taille égale ou légèrement supérieure (pas inférieure) - on ne peut pas réduire un swap, il faut le détruire et le recréer avec une taill différente.
- déplacer les blocs vers le début du volume physique /dev/sda5 avec
pvmove - réduire le volume physique /dev/sda5 à la taille souhaitée avec
pvresize - réduire la partition /dev/sda5 à une taille égale ou légèrement supérieure (pas inférieure)
- réduire la partition étendue /dev/sda2
Pas sûr que ce soit plus simple que de créer de nouveaux PV/VG/LV et d’y transférer les données.
Merci @PascalHambourg de ces explications très complète.
Pense tu qu’il soit possible de faire une nouvelle installation (avec ou sans LVM) sur un autre disque et d’y déplacer l’intégralité de mes données et configurations pour me pas a voir à réinstaller l’ensemble de mes paquets ?
Oui. Mais avant, peux-tu rapporter la sortie de la commande suivante :
lvdisplay -m@PascalHambourg voila les infos que tu m’as demandé :
gudbes@MUFASA:~$ lvdisplay -m
--- Logical volume ---
LV Path /dev/MUFASA-vg/root
LV Name root
VG Name MUFASA-vg
LV UUID hTmGzm-Rb4J-SyBT-FtsI-bc0x-iMFl-vU18Oz
LV Write Access read/write
LV Creation host, time MUFASA, 2018-03-18 12:25:17 +0100
LV Status available
# open 1
LV Size 919,36 GiB
Current LE 235355
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:1
--- Segments ---
Logical extents 0 to 235354:
Type linear
Physical volume /dev/mapper/sda5_crypt
Physical extents 0 to 235354
--- Logical volume ---
LV Path /dev/MUFASA-vg/swap_1
LV Name swap_1
VG Name MUFASA-vg
LV UUID sOXxdf-tXlk-Vhdy-z50O-qeUu-2pOv-LDR5Ji
LV Write Access read/write
LV Creation host, time MUFASA, 2018-03-18 12:25:17 +0100
LV Status available
# open 2
LV Size 11,91 GiB
Current LE 3050
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:2
--- Segments ---
Logical extents 0 to 3049:
Type linear
Physical volume /dev/mapper/sda5_crypt
Physical extents 235355 to 238404J’avais oublié qu’en plus, le PV est un volume chiffré, qu’il vaut mieux désactiver avant de réduire sa partition, et donc désactiver les volumes logiques qu’il contient avant.
Le volume root est physiquement au début du PV, et le volume swap_1 est derrière, à la fin. Après avoir réduit le volume root, il sera possible de déplacer le volume swap_1 afin de pouvoir réduire le PV.
Oula Je comprend les grandes lignes mais ça s’arrête là. Je pense que la gestion de LVM me dépasse un peu, ajouter à cela le fait que le volume est Chiffrée et on obtient une vraie usine à gaz 
Ne serait il pas plus simple de refaire une installation (au pire sans LVM (car je n’en ai pas d’utilité je pense)) et déplacer les données via la commande dd ?
Il est risqué d’utiliser des systèmes comme LVM, le chiffrement, le RAID… si on ne les maîtrise pas un minimum, sinon en cas de problème on ne s’en sort pas.
Tu n’as pas besoin de LVM, mais as-tu besoin du chiffrement ?
Je ne vois pas bien comment dd pourrait servir à déplacer les données dans une nouvelle installation.
Il sert à cloner le contenu d’un disque, partition ou volume entier (ou partiel en spécifiant la taille utile à condition que le contenu n’occupe pas tout le volume).
D’autre part le clonage écraserait l’emplacement de destination, donc la racine de la nouvelle installation. Donc il faut soit faire une nouvelle installation et transférer les données fichier par fichier (cp, rsync, tar…), soit cloner le système de fichiers racine réduit dans un nouveau volume.
En effet, je ne maitrise pas trop le sujet de LVM et chiffrement de façon avancée (juste débutant) mais la mise en place de LVM c’etait pour apprendre 
et le chiffrement pour protéger mon serveur de données …
Est un bon choix … pas sur car ça semble un univers bien complexe …
Je pense que je ne vais pas avoir le choix de faire une nouvelle installation ( ça me servira de leçon … car je vais encore passer un moment à tout reinstaller mes paquets )
Merci @PascalHambourg et tout les autres de votre aide.
Si c’était pour apprendre, alors il me semble que voilà une bonne occasion d’approfondir ses connaissances. Je ne saurais trop recommander de s’exercer sur une VM “bac à sable” (les snapshots, c’est pratique pour faire des essais et revenir en arrière si on a tout cassé).
Réinstaller les paquets, ce n’est pas compliqué : il suffit d’exporter la liste sur le système actue et de l’importer sur le nouveau système. Le plus délicat, c’est la configuration.
La solution d’apprentissage c’est celle que je préfère mais celle qui me fait le plus peur dans la compréhension comme dans la mise en place … je pense que je vais faire une installation toute propre dans une VM en collant à mon PC actuel et faire des tests.
Merci @PascalHambourg
J’ai donc mis en place une VM pour faire des tests et voilà ou j’en suis :
1/ réduire le système de fichiers racine (démonté) dans /dev/MUFASA-vg/root avec resize2fs à la taille souhaitée
-> # resize2fs /dev/MUFASA-vg/root
2/ réduire le volume logique /dev/MUFASA-vg/root avec lvreduce à une taille égale ou légèrement supérieure (pas inférieure)
-> lvreduce -L 11G /dev/MUFASA-vg/root
Mais après validation (par la lettre Y), j’ai le message suivant : Command failed with status code 5.
As tu une idée du pourquoi du comment.
Merci
Je précise que j’ai démarré sur le CD de Debian en mode recovery pour taper ces commandes.
resize2fs n’est pas devin, il faut lui indiquer la taille souhaitée.
La commande resize2fs /dev/mapper/VMLVM–vg-root 11G retourne :
Le système de fichiers de /dev/mapper/VMLVM–vg-root est monté sur / ; le changement de taille doit être effecté en ligne. resize2fs : La réduction en ligne n’est pas supportée.
Je précise que j’ai suivi ce tuto qui indique de démonter la partition : https://journaldunadminlinux.fr/tutoriel-gerez-votre-systeme-de-fichier-grace-a-lvm-logical-volume-management/
En effet un système de fichiers ext4 ne peut être réduit que lorsqu’il n’est pas monté (pour info, btrfs n’a pas cet inconvénient). Or visiblement il est monté sur /, et il est évidemment impossible de démonter la racine du système courant. Il faut démarrer avec un autre système.
Une astuce pour ne pas devoir démarrer depuis un autre système consiste à effectuer l’opération depuis l’initramfs avant que la racine soit montée. Comme resize2fs n’est pas inclus en standard dans l’initramfs, il faut regénérer l’initramfs en l’incluant explicitement. Voir la documentation de initramfs-tools pour les détails.
Je vais partir sur un système tout propre et essayer de migrer mes logiciels je pense que se sera plus simple et pas de LVM du coup… 