Vous n'êtes pas identifié(e).
Dernière modification par Abuishaq (13-09-2016 12:55:21)
Hors ligne
En règle générale, les partitions utilisant LVM se redimensionnent bien, mais il y a des précautions à prendre. En revanche je ne l'ai jamais essayé sur une configuration utilisant du chiffrement.
Hors ligne
Hors ligne
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
1) Pourquoi supprimer le volume swap ?
J'ai sûrement une mauvaise représentation de l'agencement "physique" des partitions sur le disque et encore peu d'expérience dans la manipulation "avancée" de LVM (surtout quand il s'agît de réduire la taille des volumes).
Du coup je pensais qu'après réduction du FS dans vg/root (en effet, j'ai omis ce point important !) puis du volume logique root lui-même, il y aurait un espace entre la fin de ce dernier et le début du LV swap. Et qu'il était plus rapide de supprimer et de récréer ce volume que de le déplacer.
Donc si j'ai bien compris et pour reprendre les points que tu évoques, la procédure serait :
- boot sur ISO Live ou tout autre système ;
- désactivation des 2 volumes LVM ( / et swap) ; (<= ne faut-il pas les désactiver avant toute opération ?)
- réduction du système de fichiers dans vg/root avec resize2fs (si ext2/3/4) ;
- réduction de la taille du volume vg/root avec lvreduce ;
- déplacement du LV swap ? ;
- réduction PV LVM avec pvresize dans sda5_crypt ;
- réduction du volume chiffré (ou désactivation) avec cryptsetup ;
- réduction de la taille de la partition sda5 ;
- réactivation du volume chiffré (le cas échéant) et des deux volumes root et swap.
Hors ligne
Petite question justement concernant Clonezilla, les fichiers sont compressés pour tenir dans une petite clé ?
Je ne sais plus si clonezilla est capable de compresser les images de disques et de partitions (probablement), mais il est capable de ne copier que les blocs contenant des données utiles avec les systèmes de fichiers qu'il connaît. Cependant aucune de ces deux fonctionnalités ne sera utile pour sauvegarder une partition chiffrée dont le contenu est par nature incompréhensible. Seule une sauvegarde du contenu du LV root en tirerait parti ; dans ce cas, la sauvegarde sans compression occupera la taille de l'espace utilisé dans le système de fichiers, ou approximativement la moitié avec compression (dépend du contenu des fichiers). A cela ajouter le contenu de sda1 qui ne doit pas représenter plus de 40 Mo.
je pensais qu'après réduction du FS dans vg/root (en effet, j'ai omis ce point important !) puis du volume logique root lui-même, il y aurait un espace entre la fin de ce dernier et le début du LV swap. Et qu'il était plus rapide de supprimer et de récréer ce volume que de le déplacer.
L'idée n'est pas mauvaise, à conditition que le LV swap soit effectivement à la fin du PV. Un gros avantage de LVM est que contrairement aux partitions on n'a pas besoin de se préoccuper de la position physique des volumes logiques, qui ne sont pas forcément contigus et peuvent être divisés en plusieurs fragments, comme les fichiers (mais avec une taille de bloc ou "extent" beaucoup plus grosse). Un calcul à la louche me donne environ 10 minutes pour le déplacement d'un volume de 16 Go, donc si "lvdisplay -m" indique que les extents qui constituent le LV swap sont bien à la fin dans la partie qui va être raccourcie, alors il peut être intéressant de le supprimer et le recréer (avec le même UUID).
Il vaut mieux montrer que raconter.
Hors ligne
Petite question justement concernant Clonezilla, les fichiers sont compressés pour tenir dans une petite clé ? Car je n'ai malheureusement pas beaucoup d'espace (8G) et ça m'étonnerai que je puisse faire quelque chose avec ça.
La taille finale de l'image dépendra de l'espace actuellement occupé sur le disque (ou les partitions que tu choisiras de "cloner"). Certainement plus de 8 Go en effet
Je te conseille de ne pas te précipiter et de te familiariser avec cet outil puissant qui t'évitera des problèmes dans des opérations de partitionnement risquées.
@ raleur : merci pour ces précisions, ça me fait dire qu'il faudrait un jour que je revois la théorie sur LVM et que je pratique un peu en VM !
Hors ligne
- boot sur ISO Live ou tout autre système ;
- désactivation des 2 volumes LVM ( / et swap) ; (<= ne faut-il pas les désactiver avant toute opération ?)
- réduction du système de fichiers dans vg/root avec resize2fs (si ext2/3/4) ;
- réduction de la taille du volume vg/root avec lvreduce ;
- déplacement du LV swap ? ;
- réduction PV LVM avec pvresize dans sda5_crypt ;
- réduction du volume chiffré (ou désactivation) avec cryptsetup ;
- réduction de la taille de la partition sda5 ;
- réactivation du volume chiffré (le cas échéant) et des deux volumes root et swap.
Tout se ferait à partir d'un boot live ou ?
Je suis en train de suivre ce cours : https://openclassrooms.com/courses/le-m … -gnu-linux qui explique la partie partitionnement, peut-être que je trouverai quelques tuyaux ! Mais ça m'étonnerait qu'il parle d'une partition chiffrée quoi qu’apparemment d'après les descriptions que j'ai pu voir, la manière dont c'est rédigé, les auteurs parlant d'une désactivation ou d'un remodelage du volume chiffré reflètent une certaine "facilitée".
On verra bien mais j'aimerai tout-de-même pouvoir sauvegarder mes données au cas où car j'aime bien fouiller et faire mes test mais si jamais je perds mes données.. Aïe !
Je me demandais également, n'est-il pas possible de faire du DD entier une partition chiffrée puis à l'intérieur de ce volume, partitionner pour installer des distributions/OS ? Ou alors le logiciel de chiffrement à nécessairement besoin de lancer un OS en premier pour fonctionner ?
Merci pour votre implication.
Hors ligne
ThinkPad T530 - Debian - CoreBoot
Hors ligne
à mon souvenir c'est l'étape la plus difficile
Moi qui ne comprends déjà pas tout le charabia avec les LVM/LV, on est mal barrés !
Hors ligne
une chose de certain c'est qu'il va te falloir déchiffrer ton volume avant de faire quoi que ce soit
Qu'entends-tu par "déchiffrer" ? Si tu veux dire accéder au contenu en clair du volume chiffré via /dev/mapper/sda5_crypt, il faut bien sûr le faire pour accéder aux volumes logiques afin de les redimensionner/déplacer. Si tu veux dire réécrire tout le contenu en clair directement sur le disque, alors d'une part ce n'est absolument pas nécessaire et d'autre part ce n'est pas une opération possible directement : il faut copier le contenu en clair ailleurs, supprimer le volume chiffré et recopier le contenu en clair dans la partition.
Les étapes révisées :
- boot sur ISO Live ou tout autre système ;
- ouverture du volume chiffré avec cryptsetup luksOpen
- activation du volume LVM root avec lvchange -ay si pas déjà actif ; ne pas le monter, et le démonter s'il a été monté (il doit être actif mais non monté pour l'étape suivante)
- réduction du système de fichiers dans le LV root avec resize2fs (si ext2/3/4) ou outil équivalent si autre système de fichiers ;
- réduction de la taille du LV root avec lvreduce ;
- sauvegarde de l'UUID du swap indiqué par blkid
- suppression du LV swap ;
- désactivation du LV root avec lvchange -an ;
- réduction du PV LVM avec pvresize dans sda5_crypt ;
- désactivation du volume chiffré avec cryptsetup luksClose ;
- réduction de la taille de la partition sda5 ;
- réactivation du volume chiffré avec cryptsetup luksOpen
- création d'un LV swap avec lvcreate
- initialisation du swap avec mkswap -U <uuid> (remettre l'UUID de l'ancien swap)
Pour les réductions, prends de la marge large (1 Go) : assure-toi que le contenu reste plus petit que le contenant :
taille du système de fichier < taille LV root
taille PV < taille de sda5.
Tu pourras ensuite ajuster à chaud la taille du PV avec pvresize et la taille du système de fichiers du LV root avec resize2fs à la nouvelle taille de leur contenant sans spécifier de taille.
Attention avec quoi tu réduis la partition : certains programmes utilisent des multiplicateurs binaires (fdisk), comme lvm et resize2fs, tandis que d'autres utilisent par défaut des multiplicateurs décimaux (parted). 1 Gio binaire = 1,07 Go décimal.
Dernière modification par raleur (12-08-2016 14:00:30)
Il vaut mieux montrer que raconter.
Hors ligne
- boot sur ISO Live ou tout autre système ;
Que veux-tu dire par là ? Je dois par exemple booter sur mes CD d'install Debian ? Je n'ai pas trop compris car si je boot sur ça par exemple ou même autre chose, comment accèder aux commandes par la suite ?
Quant au reste des étapes, "cryptsetup luksOpen", "lvchange" (-ay si pas déjà actif), "resize2fs", "lvreduce", "blkid", "pvresize", "cryptsetup luksClose" , "lvcreate" et "mkswap" toutes ces "expressions" sont bien à rentrer dans un terminal (root de toute évidence) ? Je n'ai rien à ajouter de plus par exemple avec lvreduce (la taille à réduire ou la taille désirée) ? Ou alors les indication viennet après avoir lancer la commande ? Ca me ferait juste genre :
Je préfère vraiment avoir le maximum d'info avant de me lancer pour éviter de revenir pendant les étapes
Attention avec quoi tu réduis la partition : certains programmes utilisent des multiplicateurs binaires (fdisk), comme lvm et resize2fs, tandis que d'autres utilisent par défaut des multiplicateurs décimaux (parted). 1 Gio binaire = 1,07 Go décimal.
Merci de me le faire rappeler ! Justement je viens de découvrir cette différence dans le cours que j'ai mis en lien précédemment.
Dernière modification par Abuishaq (12-08-2016 19:02:36)
Hors ligne
Quand tu dis :"boot sur ISO Live ou tout autre système"
Ce n'ai pas moi qui l'ai écrit, je n'ai fait que le recopier avec ta liste que tu as toi-même recopiée de la liste de Sogal au message #8.
Les systèmes live incluent généralement toutes ces commandes. Elles sont aussi disponibles dans le mode "rescue" de l'installateur Debian que tu peux donc utiliser (par contre les pages de manuel ne sont pas disponibles, en cas de besoin il faudra avoir une autre poste à côté ou avoir noté les options nécessaires avant). Ça commence comme l'installation mais à un moment il te demandera la passphrase pour ouvrir le volume chiffré, activera les LV, affichera la liste des partitions et volumes détectés et te demandera lequel monter comme racine. Au lieu d'en choisir un, bascule dans un des shells accessibles par Ctrl+Alt+F2 ou F3 pour exécuter tes commandes.
Quant au reste des étapes, "cryptsetup luksOpen", "lvchange" (-ay si pas déjà actif), "resize2fs", "lvreduce", "blkid", "pvresize", "cryptsetup luksClose" , "lvcreate" et "mkswap" toutes ces "expressions" sont bien à rentrer dans un terminal (root de toute évidence) ? Je n'ai rien à ajouter de plus
Si, évidemment. Autrement ce serait trop facile. Je n'ai indiqué que la commande et le cas échéant l'action à passer à la commande en argument. Mais il y a d'autres arguments à fournir : nom du volume, taille... Tu dois lire la page de manuel de chaque commande ("man <commande>") pour comprendre comment elle fonctionne. Beaucoup de ces commandes peuvent provoquer des pertes de données si elles sont mal utilisées, il est donc hors de question que tu tapes des lignes de commande sans les comprendre.
Je te fais quand même un résumé pour que tu ne sois pas trop perdu dans les pages de manuel
- ouvrir un volume chiffré stocké sur /dev/sdXN :
cryptsetup luksOpen /dev/sdXN sdXN_crypt
- activer (rendre disponible) un LV vg/root :
lvchange -ay /dev/vg/root
- démonter un système de fichiers dans /dev/vg/root :
umount /dev/vg/root
- vérifier un système de fichiers ext2/3/4 dans /dev/vg/root (si resize2fs l'exige) :
e2fsck -f /dev/vg/root <N>G
-redimensionner un système de fichier ext2/3/4 dans /dev/vg/root à <N> Gio :
resize2fs -p /dev/vg/root <N>G
- redimensionner un LV /dev/vg/root à <N> Gio :
lvresize -L <N>G /dev/vg/root
- enregistrer l'UUID d'un volume /dev/vg/swap dans le fichier uuid.txt (respecter les espaces) et vérifier :
blkid /dev/vg/swap | sed -e 's/.* UUID="//' -e 's/".*//' > uuid.txt
cat uuid.txt
- supprimer un LV vg/swap :
lvremove /dev/vg/swap
- désactiver (rendre non disponible) un LV vg/root :
lvchange -an /dev/vg/root
- redimensionner un volume physique dans /dev/mapper/sdXN_crypt à <N> Gio :
pvresize --setphysicalvolumesize <N>G /dev/mapper/sdXN_crypt
- fermer un volume chiffré :
cryptsetup luksClose sdXN_crypt
- redimensionner une partition /dev/sdX<N> à <L> Gio :
parted /dev/sdX resizepart <N> <L>Gi
- ouvrir un volume chiffré stocké sur /dev/sdXN :
cryptsetup luksOpen /dev/sdXN sdXN_crypt
- ajuster la taille d'un PV dans /dev/mapper/sdXN_crypt :
pvresize /dev/mapper/sdXN_crypt
- activer un volume logique LVM vg/root :
lvchange -ay /dev/vg/root
-ajuster la taille d'un système de fichier ext2/3/4 dans /dev/vg/root :
resize2fs -p /dev/vg/root
- créer un LV vg/swap de <N> Gio :
lvcreate -L <N>G -n vg/swap
- créer un swap dans /dev/vg/swap avec l'UUID enregistré dans le fichier uuid.txt :
mkswap -U $(cat uuid.txt) /dev/vg/swap
NOTE : l'option -U <UUID> n'est pas disponible avec la version de mkswap de l'installateur Debian, il faudra donc créer le swap depuis un "vrai" système ou modifier l'UUID dans /etc/fstab du système cible pour qu'il corresponde à celui du nouveau swap, affiché avec blkid
Conseil : n'hésite pas à exécuter d'autres commandes informatives pour vérifier la situation à tout moment, par exemple :
cryptsetup status <volume> # état d'un volume chiffré
lvdisplay # état des LV
fdisk -l # liste des partitions sur les disques
cat /proc/partitions # liste des volumes (disques, partitions...) avec les tailles en blocs de 1 Kio tel que vus par le noyau
Ouais, parce que certains programmes comme fdisk ne peuvent pas mettre à jour la vue du noyau si une partition du disque est en cours d'utilisation. Parted n'a pas ce problème. Il est important que le noyau prenne en compte les changements apportés à la table de partition avant de poursuivre. Dans le doute redémarrer.
Il vaut mieux montrer que raconter.
Hors ligne
ThinkPad T530 - Debian - CoreBoot
Hors ligne
Au final pas besoin d'une commande spéciale pour modifier le volume chiffré mais juste un désactivation pour permettre sa modification.
Aussi, tu me disais de laisser une marge d'un Go pour être sûr de ne pas faire de bourde dans le redimensionnement du contenu. Peut-être que j'ai mal compris mais d'après le manuel des commandes de resize, si je ne spécifie pas la taille il se mettra automatiquement à la taille du conteneur. Si quelqu'un pouvait me confirmer à la limite ça me facilitera encore plus.
Merci à tous.
Je vais tester tout ça dès que j'aurai réussi à faire une sauvegarde du système sur un support qui en aura la place. Je pense utiliser Grsync qui est pourvu d'un interface graphique et qui me facilitera au moins pour ça.
Hors ligne
Dernière modification par raleur (14-08-2016 10:42:53)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
- 1) Réduire vg-root à 250 Go
Cela se décompose en deux opérations successives :
1a) réduire le système de fichiers à 249 Go
1b) réduire le LV à 250 Go
Et fais attention aux unités, resize2fs et lvresize travaillent avec des Gio, pas des Go.
la commande que tu m'avais donné : "blkid /dev/vg/swap | sed -e 's/.* UUID="//' -e 's/".*//' > uuid.txt", lorsque que je tente un "cat uuid.txt" ça ne me donne rien,
Comme je l'avais écrit dans la description de la ligne précédente, c'est pour un swap qui serait dans un volume /dev/vg/swap à titre d'exemple. Il faut mettre le nom du volume réel.
- 3) Reduire sda5_crypt à 267 Go
Le PV (avec pvresize), pas le volume chiffré (avec cryptsetup resize). Le volume chiffré s'ajustera automatiquement à la taille de la partition à sa prochaine ouverture.
Et donc selon ce que j'avais vu par rapport au fait de en pas spécifier la taille, ça serait dans le cadre ou je referais ces manipulations mais dans le sens inverse simplement pour regagner les quelques Go perdus
Oui.
Il vaut mieux montrer que raconter.
Hors ligne
Cela se décompose en deux opérations successives :
1a) réduire le système de fichiers à 249 Go
1b) réduire le LV à 250 Go
Donc dans cette logique, je dois faire de même avec les 16 Go de swap ?
(C'est o.k pour uuid.txt, j'ai pu le générer simplement en changer la cible /dev/X-vg/swap_1, merci !)
Et fais attention aux unités, resize2fs et lvresize travaillent avec des Gio, pas des Go.
Donc 250 Gio ne sera pas égal 250 Go (mais plutôt 262 Go si j'ai bien compris?) mais légèrement plus, c'est bien ça ?
Le PV (avec pvresize), pas le volume chiffré (avec cryptsetup resize). Le volume chiffré s'ajustera automatiquement à la taille de la partition à sa prochaine ouverture.
Donc en réalité, j'enlève une étape, rien que le changement de sda5 modifiera tout seul au final la taille de sda5_crypt qui se réajustera à sa réactivation. Ca me facilite grandement !
Le soucis du départ d'une modification d'un volume chiffré se règle plus ou moins seul, automatiquement, à condition de le désactiver et de modifier son contenant.
Dernière modification par Abuishaq (14-08-2016 14:15:11)
Hors ligne
Donc dans cette logique, je dois faire de même avec les 16 Go de swap ?
Non puisque le swap va être supprimé puis recréé, et non redimensionné.
Donc 250 Gio ne sera pas égal 250 Go (mais plutôt 262 Go si j'ai bien compris?) mais légèrement plus, c'est bien ça ?
Plutôt 268 Go, mais c'est l'idée.
Que tu choisisses 250 Gio ou 250 Go, peu importe mais il faut que toutes les tailles soient cohérentes. Comme la plupart des commandes utilisées pour cette opérations (resize2fs, lvresize, pvresize, lvcreate) fonctionnent avec des multiplicateurs binaires (bien que notés k, M, G... et non Ki, Mi, Gi...) et l'autre, parted, peut utiliser des multiplicateurs binaires (Gi) ou décimaux (G) à condition de le spécifier, je te recommande de tout faire avec des Gio.
Il vaut mieux montrer que raconter.
Hors ligne
Donc en réalité, j'enlève une étape, rien que le changement de sda5 modifiera tout seul au final la taille de sda5_crypt
Il n'y a pas d'étape à enlever, il faut quand même réduire le PV sda5_crypt (avec pvresize) en prévision de la réduction de la partition chiffrée.
Il vaut mieux montrer que raconter.
Hors ligne
Alors que j'ai bien entré le nom du vg sans faute
Puis, si jamais il avait bien été activé avant ma commande verbose (car je ne l'ai fait qu'après pour voir le problème):
Voila, ça ne doit être qu'un détail mais ça commence comme ça
Hors ligne