Salut!
on en causait ce vendredi avec Piernov, de la légitimité de LVM et de ses contraintes... Notamment comme écrit ici URL:https://doc.ubuntu-fr.org/lvm#inconvenients_de_lvm
Si un des volumes physiques devient HS, alors c'est l'ensemble des volumes logiques qui utilisent ce volume physique qui sont perdus. Pour éviter ce désastre, il faudra utiliser LVM sur des disques raid par exemple.
Comme je viens d'avoir un petit SSD de 120Go, je voudrais le mettre sur le petit PC de TV (pas un Rasp, non, un Packard-Bell iMax mini). 1/ il s'agit d'un HDD de 150Go... bas, juste à réduire les partitions puis un coup de dd... je suis rôdé grâce à Julien! 2/ flûte, c'est du LVM... et du coup je ne sais pas bien comment procéder! (Piernov, interdit de te moquer!) 2-bis/ je ne veux pas simplement réduire les partitions sous LVM, je veux me sauver de LVM pour revenir sur du classique MBR!
Même si je crains qu'une réinstallation soit le plus simple (vite dit, car ma Manjaro FluxBox m'avait fait une bonne série de caprices...), j'aimerais bien savoir comment procéder?
Merci! Vincent.
On 07/26/2016 03:58 PM, Vincent wrote: (lvm)
Si un des volumes physiques devient HS, alors c'est l'ensemble des volumes logiques qui utilisent ce volume physique qui sont perdus. Pour éviter ce désastre, il faudra utiliser LVM sur des disques raid par exemple.
Hello Vincent,
Bon, effectivement, mais tu me diras : avec de bonnes vieilles partitions c'est pareil quand tu perds un disque, hein. A mon sens, pas un inconvénient très valable.
Non, un vrai inconvénient c'est plutôt quand tu perds tes définitions de vgs et lvs. Là tu rigoles bien :)
..
2/ flûte, c'est du LVM... et du coup je ne sais pas bien comment procéder! (Piernov, interdit de te moquer!) 2-bis/ je ne veux pas simplement réduire les partitions sous LVM, je veux me sauver de LVM pour revenir sur du classique MBR!
Même si je crains qu'une réinstallation soit le plus simple (vite dit, car ma Manjaro FluxBox m'avait fait une bonne série de caprices...), j'aimerais bien savoir comment procéder?
Pas de problème !
Mettons que tu veuilles bouger un lv 'toto' d'un vg 'titi' en ext[234] vers une partition /dev/sda3 que tu vas créer à la place sur le même disque, par exemple.
1. Réduire les lvs à sauver :
# resize2fs -M /dev/mapper/titi-toto (resize2fs te dit la taille obtenue; disons : XXX) # lvresize -L XXX /dev/mapper/titi-toto ...
2. Dumper les lvs ainsi réduits vers un endroit temporaire à coup de dd (puisque tu aimes bien dd) :
# dd if=/dev/mapper/titi-toto bs=1M of=/temp/titi-toto.img ...
3. Quand tu as tout sauvé, détruire le setup lvm proprement à coup de lvremove, vgremove, pvremove. Puis refaire à la place des partitions qui vont bien, de taille "au moins" XXX pour l'exemple qui nous concerne.
4. Restaurer les filesystems à coup de dd et aussi un resize pour être sûr de bien occuper toute la place si la partition est un peu plus grande :
# dd if=/temp/titi-toto.img bs=1M of=/dev/sda3 # resize2fs /dev/sda3
Et voilà !
Un raffinement supplémentaire si tu es aventureux : un coup de lzo à la volée pour le dump/restore, histoire de gagner encore un peu de temps et de place :
lzop -c1 </dev/mapper/titi-toto >/temp/titi.toto.img.lzo lzop -dc </temp/titi-toto.img.lzo >/dev/sda3
Et puis il y a moyen de faire du md5sum après dump, avant destruction, si tu es parano comme moi.
Bonne IT,
Vincent.
Le 26/07/2016 à 17:08, Vincent Stehlé a écrit :
Non, un vrai inconvénient c'est plutôt quand tu perds tes définitions de vgs et lvs. Là tu rigoles bien :)
Un exemple de perte de définition? La zone d'amorce écrasée par une fausse manip?
Mettons que tu veuilles bouger un lv 'toto' d'un vg 'titi' en ext[234] vers une partition /dev/sda3 que tu vas créer à la place sur le même disque, par exemple.
Tant qu'on évoque pas les PV, je supporte! 8-)
Réduire les lvs à sauver :
# resize2fs -M /dev/mapper/titi-toto (resize2fs te dit la taille obtenue; disons : XXX) # lvresize -L XXX /dev/mapper/titi-toto ...
Dumper les lvs ainsi réduits vers un endroit temporaire à coup de dd
(puisque tu aimes bien dd) :
# dd if=/dev/mapper/titi-toto bs=1M of=/temp/titi-toto.img ...
- Quand tu as tout sauvé, détruire le setup lvm proprement à coup de
lvremove, vgremove, pvremove. Puis refaire à la place des partitions qui vont bien, de taille "au moins" XXX pour l'exemple qui nous concerne.
- Restaurer les filesystems à coup de dd et aussi un resize pour être
sûr de bien occuper toute la place si la partition est un peu plus grande :
# dd if=/temp/titi-toto.img bs=1M of=/dev/sda3 # resize2fs /dev/sda3Et voilà !
C'est simple, écrit ainsi, sans doute pour cela que je n'ai trouvé aucun tuto? Je n'espérais pas qu'on puisse utiliser dd aussi simplement, merveilleux cet outil en dépit de son nom familier (Disk Destroyer). Bon, il reste à réécrire le grub et le fstab/mtab. Tiens, d'ailleurs, il faudrait que je regarde ce qu'il contient, au moins pas curiosité.
Un raffinement supplémentaire si tu es aventureux : un coup de lzo à la volée pour le dump/restore, histoire de gagner encore un peu de temps et de place :
lzop? Tiens, je vais regarder!
Merci! Vincent.
Zut, dans mon empressement de petit scarabée ébloui, j'ai oublié de te saluer... Fichtre!
Te verrais-je au BSL en août?
A+ Vincent.
Le 26/07/2016 à 15:58, Vincent a écrit :
Salut!
Salut,
Même si je crains qu'une réinstallation soit le plus simple (vite dit, car ma Manjaro FluxBox m'avait fait une bonne série de caprices...), j'aimerais bien savoir comment procéder?
Une autre possibilité est d'utiliser rsync pour le transfert de fichiers. Je n'ai pas tous les paramètres en tête, mais quelque chose comme : rsync -avAHX <source> <destination> est peut être suffisant. D'autres utilisent la commande `tar` pour avoir un résultat similaire.
Il faudra au préalable créer la table de partition sur le nouveau disque puis formatter les partitions et les monter. Attention aussi, si le fstab contient des UUID, il faut penser à les mettre à jour. Si ce sont des LABEL il faut évidemment nommer correctement les partitions du nouveau disque. Il faudra donc aussi probablement regénérer l'initrd et mettre à jour la configuration de GRUB, tout ça en chroot sur le nouveau disque. Il faudra penser à réinstaller GRUB sur le MBR du nouveau disque. Dans le cas d'UEFI, il faudra aussi faire un `grub-install` pour mettre à jour l'entrée de démarrage dans l'UEFI.
salut tout le monde je vois que dans la procédure proposée, la partition est redimentionnée à la taille voulue puis le lv redimentionné. attention à cette manip. il vaut mieux resiser la partition vers une taille plus petite, puis resizer le lv puis remplir l'espace libre. voir ceci : https://blog.shadypixel.com/how-to-shrink-an-lvm-volume-safely/ sinon, si le volume lvm n'es pas créé par kvm ou autre, il est possible de faire un dd directement du lv vers la nouvelle partition sans passer par une image.
On 07/26/2016 05:59 PM, ssm2017 wrote: ..
je vois que dans la procédure proposée, la partition est redimentionnée à la taille voulue puis le lv redimentionné.
En fait de partition tu veux dire le filesystem je pense; mais oui, c'est bien la manip' proposée.
attention à cette manip. il vaut mieux resiser la partition vers une taille plus petite, puis resizer le lv puis remplir l'espace libre.
Euh ? N'est-ce pas exactement la manip' précédente ? J'ai dû rater un truc quelque part...
En tout cas je peux affirmer quel l'enchaînement resize2fs-puis-lvresize marche, quand on ne se trompe pas dans les paramètres :)
voir ceci : https://blog.shadypixel.com/how-to-shrink-an-lvm-volume-safely/
'faudra que j'essaye lvreduce; ça a l'air plus "tout en un" avec moins de chance de se blesser...
sinon, si le volume lvm n'es pas créé par kvm ou autre, il est possible de faire un dd directement du lv vers la nouvelle partition sans passer par une image.
Tout à fait, et ça sera plus rapide, si on ne crée pas la partition à la place du physical volume lvm.
Amicalement,
Vincent.
-
piernov -
ssm2017 -
Vincent -
Vincent Stehlé