LVM : Live Session > Accès aux Volumes Logiques (LV) Le sujet est résolu

Demande d'aide : c'est ici.
Répondre
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3548
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

Bonjour,

Dans une session Live (stretch) de maintenance,
je ne parviens pas à accéder aux Volumes Logiques du LVM que j'ai déjà créés depuis l'OS installé (buster).

Ces volumes portent tous un FS ext4 tout neuf (jamais monté)
sauf un sur lequel j'ai déjà mis une copie complète de /boot


Je précise qu'il s'agit d'un VPS OVH
et que je n'ai pas d'autre choix que la session en "Rescue Mode"
avec une ISO "OVH" basée sur stretch.
Cette image ne contient pas LVM



Voici ce que j'ai :

Code : Tout sélectionner

# uname -a
Linux rescue-pro 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux
J'ai installé LVM avec :
# apt-get install lvm2

Pour les services :

Code : Tout sélectionner

# systemctl list-units lvm2*
UNIT                 LOAD   ACTIVE SUB       DESCRIPTION                
lvm2-lvmetad.service loaded active running   LVM2 metadata daemon       
lvm2-lvmetad.socket  loaded active running   LVM2 metadata daemon socket
lvm2-lvmpolld.socket loaded active listening LVM2 poll daemon socket

Code : Tout sélectionner

# vgscan
  Reading volume groups from cache.
  Found volume group "lvm-vg0" using metadata type lvm2
  

vgscan trouve mon groupe lvm-vg0,
mais rien ne s'affiche nul-part dans : /dev/...

Code : Tout sélectionner

# ls -1 /dev/disk/by-path
pci-0000:00:04.0-scsi-0:0:0:0
pci-0000:00:04.0-scsi-0:0:0:0-part1
vvvvvvvvvvv Disque du VPS vvvvvvvvvvvv
pci-0000:00:04.0-scsi-0:0:0:1
pci-0000:00:04.0-scsi-0:0:0:1-part1
pci-0000:00:04.0-scsi-0:0:0:1-part2
pci-0000:00:04.0-scsi-0:0:0:1-part3

Le groupe "lvm-vg0" ne contient qu'1 volume physique -> part3

Je vous épargne la sortie complète de : # ls -Ra /dev
car il n'y a rien qui corresponde,
p.ex :

Code : Tout sélectionner

/dev/mapper:
.  ..  control
Alors,
je suis passé à côté de quelque-chose pour accéder aux volumes
ou
c'est mission impossible ?

Merci pour vos avis.
**Simple Utilisateur** -- Debian stable - XFCE
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3548
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

Il est possible que cette question n'ait pas vraiment lieu d'être ???

Sous réserve de test (en cours)
il ne doit pas être nécessaire d'utiliser la session live pour déplacer le système du partitionnement normal vers LVM.

Par ailleurs, je pensais déplacer /boot sur un LV mais cela ne fait que compliquer inutilement,
alors je vais conservé /boot sur sda1 que je réduirai ensuite à 200Mo (actuellement 2Go)
cela va aussi m'éviter de chercher comment mettre le drapeau "boot" sur un LV.
**Simple Utilisateur** -- Debian stable - XFCE
PascalHambourg
Contributeur
Contributeur
Messages : 930
Inscription : 05 août 2016, 20:25
Status : Hors-ligne

Tu as vérifié si les volumes logiques étaient bien détectés avec lvs et lvscan ?
Ils sont peut-être inactifs. Dans ce cas as-tu essayé de les activer avec

Code : Tout sélectionner

vgchange -ay
?
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3548
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

PascalHambourg a écrit : 21 mars 2020, 12:21 Tu as vérifié si les volumes logiques étaient bien détectés avec lvs et lvscan ?
Ils sont peut-être inactifs. Dans ce cas as-tu essayé de les activer avec

Code : Tout sélectionner

vgchange -ay
?
Pas du tout ! (même pas idée de la possibilité)

Merci, je teste ça dans la journée

@+
**Simple Utilisateur** -- Debian stable - XFCE
PascalHambourg
Contributeur
Contributeur
Messages : 930
Inscription : 05 août 2016, 20:25
Status : Hors-ligne

dezix a écrit : 20 mars 2020, 22:43 il ne doit pas être nécessaire d'utiliser la session live pour déplacer le système du partitionnement normal vers LVM.
Non, mais c'est un peu plus délicat de le faire depuis le système à déplacer lui-même car certains fichiers peuvent être modifiés pendant que la copie se déroule, créant de possibles incohérences. Il vaut donc mieux arrêter tous les services non indispensables comme les serveurs divers (sauf SSH), les bases de données...
dezix a écrit : 20 mars 2020, 22:43 Par ailleurs, je pensais déplacer /boot sur un LV mais cela ne fait que compliquer inutilement,
Et c'est plus risqué.
dezix a écrit : 20 mars 2020, 22:43 cela va aussi m'éviter de chercher comment mettre le drapeau "boot" sur un LV.
Il n'y a pas de drapeau boot sur un volume logique. Ce n'est pas une partition. Si tu dois mettre un drapeau boot sur une partition, tu peux le faire sur celle qui sert de PV. Mais sache que ça n'a aucune utilité pour GRUB ou LILO, ça n'est utile qu'avec certains BIOS défectueux qui exigent la présence de ce drapeau sur une partition du MBR pour considérer un disque comme amorçable.
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3548
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

PascalHambourg a écrit : 21 mars 2020, 12:21 Tu as vérifié si les volumes logiques étaient bien détectés avec lvs et lvscan ?
Ils sont peut-être inactifs. Dans ce cas as-tu essayé de les activer avec

Code : Tout sélectionner

vgchange -ay
?


C'est la SOLUTION !

Après installation de LVM2 qui n'est pas inclu dans ma session de secours

# apt-get install lvm2

à ce stade les LV sont vus par lvs et lvscan
mais sont inactifs :

Code : Tout sélectionner

# lvs -a
  LV             VG      Attr         LSize    
  lv_home       <vg>    -wi-------  300.00m                                                    
  lv_racine    	<vg>    -wi-------    3.91g
  .....
et

/dev/mapper
ne contient que :
control

Après : # vgchange -ay

/dev/mapper/ est "peuplé"
ainsi que : /dev/<vg>
et

Code : Tout sélectionner

# lvs -a
  LV            VG      Attr         LSize    
  lv_home       <vg>    -wi-a-----  300.00m                                                    
  lv_racine    	<vg>    -wi-a-----    3.91g
  .....

Merci :023:
**Simple Utilisateur** -- Debian stable - XFCE
Répondre