J'ai rebooté hier soir un serveur dédié chez ovh et il a du mal à se
réveiller... Je n'arrive pas encore à joindre le support technique, mais
voici ce que j'ai réussi a vérifier en mode rescue :
Mais avant l'archi du serveur : /dev/md1 qui contient la racine,
/dev/md2 qui contient 3 vg lvm2 (/tmp, /var et /home).
J'arrive très bien à mounter /dev/md1 et à atteindre mes données de la
racine.
Par contre pas moyen d'atteindre le /home (en fait /dev/mapper/vg0-lvhome)
rescue:~# mount /dev/mapper/vg0-lvhome /mnt/
mount: /dev/mapper/vg0-lvhome: can't read superblock
en regardant de plus près, j'ai le résultat de pvscan pas normal :
rescue:~# pvscan
Found duplicate PV uD3ZfS9z3hPNplXh0iC6bpiLdEMo3nKG: using /dev/sdb2
not /dev/sda2
PV /dev/sda2 VG vg0 lvm2 [73.18 GB / 0 free]
Total: 1 [73.18 GB] / in use: 1 [73.18 GB] / in no VG: 0 [0 ]
J'ai du /dev/sda2 alors que je m'attendais à du /dev/md2
J'ai alors regardé le fichier de backup de lvm dans la racine mountée et
j'y vois bien un pv sur /dev/md2
J'ai alors essayé un vgcfgrestore :
rescue:~# vgcfgrestore -tvvf /mnt/md1/etc/lvm/backup/vg0 vg0
Test mode: Metadata will NOT be updated.
Setting global/locking_type to 1
Setting global/locking_dir to /var/lock/lvm
File-based locking enabled.
Locking /var/lock/lvm/P_orphans WB
Locking /var/lock/lvm/V_vg0 W
/dev/sda1: No label detected
/dev/md1: No label detected
/dev/sda2: lvm2 label detected
/dev/md2: lvm2 label detected
Duplicate PV uD3ZfS9z3hPNplXh0iC6bpiLdEMo3nKG on /dev/sda2 - using
md /dev/md2
/dev/sda3: No label detected
/dev/sdb1: No label detected
/dev/sdb2: lvm2 label detected
Found duplicate PV uD3ZfS9z3hPNplXh0iC6bpiLdEMo3nKG: using /dev/sdb2
not /dev/sda2
/dev/sdb3: No label detected
/dev/sda2: lvm2 label detected
Restored volume group vg0
Unlocking /var/lock/lvm/V_vg0
Unlocking /var/lock/lvm/P_orphans
Test mode: Wiping internal cache
Il détecte du lvm sur plusieur choses et en définitif n'utilise pas la
bonne (/dev/md2)
Est-ce qu'il y a possibilité de lui forcer le choix du pv?
Même si je ne sais pas encore ce qui se passe au boot, pouvoir mounter
ces partitions me permettrait de récupérer plus vites mes données que de
les extraires du backup ftp d'ovh.
mil
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Émile CARRY
Émile CARRY a écrit :
Bonjour à tous,
[...]
Je me réponds j'ai trouvé le pb
Il détecte du lvm sur plusieur choses et en définitif n'utilise pas la bonne (/dev/md2)
Est-ce qu'il y a possibilité de lui forcer le choix du pv?
Il fallait modifier l'option md_component_detection à 1 dans le /etc/lvm/lvm.conf du systeme de rescue. Puis lancer un "vgscan" pour les caches tiennent compte de la modif, "vgchange -a n" pour désactiver les vg, "vgcfgrestore -tvvf /mnt/md1/etc/lvm/backup/vg0 vg0" pour effectuer la modif puis "vgchange -a y" pour réactiver le vg.
Et là le pvscan donne bien /dev/md2 comme support du pv.
J'ai pu du coup chrooter les répertoires manquant et mettre à jour la distro.
Et enfin redémarrer correctement
mil
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS
Émile CARRY a écrit :
Bonjour à tous,
[...]
Je me réponds j'ai trouvé le pb
Il détecte du lvm sur plusieur choses et en définitif n'utilise pas la
bonne (/dev/md2)
Est-ce qu'il y a possibilité de lui forcer le choix du pv?
Il fallait modifier l'option md_component_detection à 1 dans le
/etc/lvm/lvm.conf du systeme de rescue. Puis lancer un "vgscan" pour les
caches tiennent compte de la modif, "vgchange -a n" pour désactiver
les vg, "vgcfgrestore -tvvf /mnt/md1/etc/lvm/backup/vg0 vg0" pour
effectuer la modif puis "vgchange -a y" pour réactiver le vg.
Et là le pvscan donne bien /dev/md2 comme support du pv.
J'ai pu du coup chrooter les répertoires manquant et mettre à jour la
distro.
Et enfin redémarrer correctement
mil
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Il détecte du lvm sur plusieur choses et en définitif n'utilise pas la bonne (/dev/md2)
Est-ce qu'il y a possibilité de lui forcer le choix du pv?
Il fallait modifier l'option md_component_detection à 1 dans le /etc/lvm/lvm.conf du systeme de rescue. Puis lancer un "vgscan" pour les caches tiennent compte de la modif, "vgchange -a n" pour désactiver les vg, "vgcfgrestore -tvvf /mnt/md1/etc/lvm/backup/vg0 vg0" pour effectuer la modif puis "vgchange -a y" pour réactiver le vg.
Et là le pvscan donne bien /dev/md2 comme support du pv.
J'ai pu du coup chrooter les répertoires manquant et mettre à jour la distro.
Et enfin redémarrer correctement
mil
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS
