périphériques lvm sous / dev / mapper manquants

J'utilise Debian Squeeze et j'exécute LVM en plus du RAID logiciel 1. Je viens juste de découvrir par accident que la plupart des liens ci-dessous /dev/mappersont manquants, bien que mon système semble toujours fonctionner correctement.

Je ne sais pas ce qui s'est passé. La seule chose que je peux imaginer qui a causé cela était ma tentative infructueuse de faire fonctionner un conteneur fedora LXC. J'ai fini par supprimer un répertoire /cgroup/laughlin, correspondant au conteneur, mais je ne peux pas imaginer pourquoi cela aurait dû causer le problème. /dev/mapperressemblait (j'ai fait quelques changements, voir ci-dessous) à peu près

orwell:/dev/mapper# ls -la
total 0
drwxr-xr-x  2 root root     540 Apr 12 05:08 .
drwxr-xr-x 22 root root    4500 Apr 12 05:08 ..
crw-------  1 root root  10, 59 Apr  8 10:32 control
lrwxrwxrwx  1 root root       7 Mar 29 08:28 debian-root -> ../dm-0
lrwxrwxrwx  1 root root       8 Apr 12 03:32 debian-video -> ../dm-23

debian-video correspond à un LV que je venais de créer.

Cependant, j'ai un certain nombre de VG sur mon système, correspondant à 4 VG répartis sur 4 disques. vgsdonne

orwell:/dev/mapper# vgs
  VG         #PV #LV #SN Attr   VSize   VFree  
  backup       1   2   0 wz--n- 186.26g  96.26g
  debian       1   7   0 wz--n- 465.76g 151.41g
  olddebian    1  12   0 wz--n- 186.26g  21.26g
  testdebian   1   3   0 wz--n- 111.75g  34.22g

J'ai essayé de courir

 /dev/mapper# vgscan --mknodes

et certains appareils ont été créés (voir la sortie ci-dessous), mais ils ne sont pas des liens symboliques vers les appareils dm comme ils devraient l'être, donc je ne sais pas si c'est inutile ou pire. Seraient-ils susceptibles de recréer les bons liens? Dois-je à nouveau supprimer ces appareils?

Je crois que udev crée ces liens, donc un redémarrage résoudrait-il ce problème, ou aurais-je un système non amorçable? Que dois-je faire pour résoudre ce problème? Existe-t-il des diagnostics / vérifications d'intégrité que je dois exécuter pour m'assurer qu'il n'y a pas d'autres problèmes que je n'ai pas remarqués? Merci d'avance pour toute aide.

orwell:/dev/mapper# ls -la
total 0
drwxr-xr-x  2 root root     540 Apr 12 05:08 .
drwxr-xr-x 22 root root    4500 Apr 12 05:08 ..
brw-rw----  1 root disk 253,  1 Apr 12 05:08 backup-local_src
brw-rw----  1 root disk 253,  2 Apr 12 05:08 backup-video
crw-------  1 root root  10, 59 Apr  8 10:32 control
brw-rw----  1 root disk 253, 15 Apr 12 05:08 debian-boot
brw-rw----  1 root disk 253, 16 Apr 12 05:08 debian-home
brw-rw----  1 root disk 253, 22 Apr 12 05:08 debian-lxc_laughlin
brw-rw----  1 root disk 253, 21 Apr 12 05:08 debian-lxc_squeeze
lrwxrwxrwx  1 root root       7 Mar 29 08:28 debian-root -> ../dm-0
brw-rw----  1 root disk 253, 17 Apr 12 05:08 debian-swap
lrwxrwxrwx  1 root root       8 Apr 12 03:32 debian-video -> ../dm-23
brw-rw----  1 root disk 253, 10 Apr 12 05:08 olddebian-etch_template
brw-rw----  1 root disk 253, 13 Apr 12 05:08 olddebian-fedora
brw-rw----  1 root disk 253,  8 Apr 12 05:08 olddebian-feisty
brw-rw----  1 root disk 253,  9 Apr 12 05:08 olddebian-gutsy
brw-rw----  1 root disk 253,  4 Apr 12 05:08 olddebian-home
brw-rw----  1 root disk 253, 11 Apr 12 05:08 olddebian-lenny
brw-rw----  1 root disk 253,  7 Apr 12 05:08 olddebian-msi
brw-rw----  1 root disk 253,  5 Apr 12 05:08 olddebian-oldchresto
brw-rw----  1 root disk 253,  3 Apr 12 05:08 olddebian-root
brw-rw----  1 root disk 253, 14 Apr 12 05:08 olddebian-suse
brw-rw----  1 root disk 253,  6 Apr 12 05:08 olddebian-vgentoo
brw-rw----  1 root disk 253, 12 Apr 12 05:08 olddebian-wsgi
brw-rw----  1 root disk 253, 20 Apr 12 05:08 testdebian-boot
brw-rw----  1 root disk 253, 18 Apr 12 05:08 testdebian-home
brw-rw----  1 root disk 253, 19 Apr 12 05:08 testdebian-root

Ces jours-ci /devsont sur tmpfs et sont créés à partir de zéro à chaque démarrage udev. Vous pouvez redémarrer en toute sécurité et ces liens reviendront.

Vous devriez également trouver des liens symboliques LVM vers les /dev/dm-Xnœuds dans les /dev/<vg>répertoires, un répertoire pour chaque groupe de volumes. Cependant, ces nœuds recréés par vgscan --mknodesfonctionneront également très bien, en supposant qu'ils ont les bons nombres majeurs / mineurs - et c'est une hypothèse sûre qu'ils ont été créés correctement.

Vous pouvez probablement aussi udevrecréer les liens symboliques en utilisant udevadm triggerune correspondance appropriée, en testant avec --dry-runjusqu'à ce qu'il soit correct. Cela ne semble guère en valoir la peine quand un redémarrage le corrigera également.

J'ai juste eu un problème similaire à ce que vous décrivez, mais pour moi, cela s'est produit lorsque j'essayais d'installer le nouveau Ubuntu 11.10 Oneiric Ozelot sur un volume LVM. J'avais fait ce qui suit pour configurer lvm sur un système de démarrage en direct (les volumes logiques dont j'avais besoin étaient déjà présents):

apt-get install lvm2
vgscan --mknodes -v

A maintenant lvscan -vmontré mes volumes mais ils n'étaient /dev/mapperni dedans ni dedans /dev/<vg>/. J'ai finalement trouvé que j'avais besoin d' activer le groupe de volumes, comme ceci:

vgchange -a y <name of volume group>

La commande ci-dessus a créé tous les fichiers de périphérique manquants pour moi. Maintenant, je pouvais démarrer le programme d'installation et il trouverait les volumes lvm et me permettrait de les installer.

Trouver ces informations sur google a été difficile, donc j'écris cette réponse dans l'espoir que d'autres auront plus de facilité - d'où le contexte approfondi et le nommage.

Bien que cela ne fasse pas partie de la question, pour être complet, j'ajouterai que dans la situation ci-dessus (installation d'Ubuntu LVM), vous devez ajouter lvm2 à l'initrd du système nouvellement installé une fois l'installation terminée, sinon il ne démarrera pas. Votre nouveau système doit être configuré pour vous dans / target, mais si ce n'est pas le cas, faites-le manuellement comme ceci:

mount /dev/vg/new_root /target
mount /dev/sdx1 /target/boot       # important
mount -o bind /proc /target/proc
mount -o bind /sys /target/sys
mount -o bind /dev /target/dev
mount -o bind /dev/pts /target/dev/pts

J'avais besoin de faire cela pour faire fonctionner le réseautage dans le chroot, auquel je reviendrai ensuite:

cp /etc/resolv.conf /target/etc/

Maintenant, passez au nouveau système et installez lvm2:

chroot /target
apt-get install lvm2

Notez qu'il exécute update-initramfs. Maintenant, tapez simplement exit et redémarrez, et votre système devrait démarrer correctement.

Cela a également fonctionné pour moi.

vgchange -a y -name of volume group-

Suite à un correctif du noyau, mon système RHEL n'a pas pu redémarrer. Plainte d'un /dev/mapper/VG-lvfichier manquant .

Démarré pour un seul utilisateur et commenté /etc/fstab. Une fois en ligne, j'ai découvert que mon disque crypté était affiché comme "appareil inconnu" pvs.

Correction de ce problème, mais toujours aucun fichier de périphérique pour le groupe Volume. L'exécution de la commande ci-dessus a recréé les fichiers du mappeur de périphériques et m'a permis de monter.

J'ai eu un problème similaire après avoir mis à jour mon debian. Lors du redémarrage, ce message m'est apparu:

Unable to find LVM Volume. 
/dev/mapper/debian-root does not exist.

J'ai trouvé la solution ici :

cryptsetup luksOpen /dev/sda5 lvmsys
lvm
lvm> vgscan        ## scan for volume groups
lvm> vgchange -a y ## activates the volume groups

Et voilà, il a bien redémarré après cela.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616689 est pertinent ici. Il s'agit de délais d'attente tels que la racine lvm n'apparaît pas à temps.