26 Jul
2016
26 Jul
'16
3:58 p.m.
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.
26 Jul
26 Jul
5:08 p.m.
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.
5:20 p.m.
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-)
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à !
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.
5:23 p.m.
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.
5:38 p.m.
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.
--
//piernov — https://chiplevel.repair/ — http://repaircafesophia.org/
//JM2L — http://jm2l.linux-azur.org/ — contact(a)jm2l.linux-azur.org
5:59 p.m.
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.
10:15 p.m.
New subject: <DKIM> Re: [TECH] convertir sous-partitions LVM en partitions MBR?
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 :)
'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.
2855
days inactive
2855
days old
7 comments
4 participants
participants (4)
-
piernov -
ssm2017 -
Vincent -
Vincent Stehlé