lvm-Geräte unter / dev / mapper fehlen

Ich verwende Debian Squeeze und führe LVM über Software-RAID 1 aus. Ich habe gerade aus Versehen festgestellt, dass die meisten Links unter /dev/mapperfehlen, obwohl mein System anscheinend immer noch richtig funktioniert.

Ich bin nicht sicher, was passiert ist. Das einzige, was ich mir vorstellen kann, war mein gescheiterter Versuch, einen LXC-Fedora-Container zum Laufen zu bringen. Am Ende habe ich ein Verzeichnis gelöscht /cgroup/laughlin, das dem Container entspricht, aber ich kann mir nicht vorstellen, warum dies das Problem hätte verursachen sollen. /dev/mappersah (ich habe ein paar Änderungen vorgenommen, siehe unten) ungefähr so ​​aus

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 entspricht einer LV, die ich gerade erstellt hatte.

Ich habe jedoch eine ganze Reihe von VGs auf meinem System, entsprechend 4 VGs, die auf 4 Festplatten verteilt sind. vgsgibt

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

Ich habe versucht zu rennen

 /dev/mapper# vgscan --mknodes

und einige geräte wurden erstellt (siehe ausgabe unten), aber sie sind keine symbolischen links zu den dm-geräten, wie sie sein sollten, also bin ich mir nicht sicher, ob dies nutzlos oder schlimmer ist. Würden sie die Wiederherstellung der richtigen Links behindern? Soll ich diese Geräte wieder löschen?

Ich glaube, dass udev diese Links erstellt. Würde ein Neustart dieses Problem beheben oder würde ich ein nicht bootfähiges System erhalten? Was soll ich tun, um das zu beheben? Gibt es irgendwelche Diagnose- / Gesundheitsprüfungen, die ich durchführen sollte, um sicherzustellen, dass es keine anderen Probleme gibt, die ich nicht bemerkt habe? Vielen Dank im Voraus für jede Hilfe.

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

In diesen Tagen /devist auf tmpfs und wird von Grund auf neu von jedem Boot erstellt udev. Sie können problemlos einen Neustart durchführen, und diese Links werden wieder angezeigt.

Sie sollten auch LVM-Symlinks zu den /dev/dm-XKnoten in den /dev/<vg>Verzeichnissen finden, ein Verzeichnis für jede Datenträgergruppe. Diese Knoten, die von neu erstellt vgscan --mknodeswurden, funktionieren jedoch auch einwandfrei, vorausgesetzt, sie haben die richtigen Haupt- / Nebenzahlen - und es ist eine sichere Annahme, dass sie ordnungsgemäß erstellt wurden.

Sie können wahrscheinlich auch udevdie Symlinks udevadm triggermit einer entsprechenden Übereinstimmung neu erstellen und mit testen, --dry-runbis sie richtig sind. Die Mühe scheint sich jedoch kaum zu lohnen, wenn ein Neustart dies ebenfalls behebt.

Ich hatte gerade ein ähnliches Problem wie das, was Sie beschrieben, obwohl es für mich passierte, als ich versuchte, das neue Ubuntu 11.10 Oneiric Ozelot auf einem LVM-Volume zu installieren. Ich habe Folgendes getan, um lvm auf einem Live-Boot-System einzurichten (die benötigten logischen Volumes waren bereits vorhanden):

apt-get install lvm2
vgscan --mknodes -v

Nun lvscan -vzeigte meine Bände, aber sie waren weder in /dev/mappernoch in /dev/<vg>/. Endlich stellte ich fest, dass ich die Volumengruppe wie folgt aktivieren musste :

vgchange -a y <name of volume group>

Mit dem obigen Befehl wurden alle fehlenden Gerätedateien für mich erstellt. Jetzt konnte ich das Installationsprogramm starten und es würde die lvm-Volumes finden und mir erlauben, sie zu installieren.

Es war schwierig, diese Informationen auf Google zu finden. Deshalb schreibe ich diese Antwort in der Hoffnung, dass andere es leichter haben werden - daher der ausführliche Kontext und das Namedropping.

Obwohl dies nicht Teil der Frage ist, füge ich der Vollständigkeit halber hinzu, dass Sie in der obigen Situation (Installation von Ubuntu LVM) nach Abschluss der Installation lvm2 zur initrd des neu installierten Systems hinzufügen müssen, da es sonst nicht startet. Ihr neues System sollte für Sie in / target eingerichtet sein. Wenn dies nicht der Fall ist, tun Sie dies manuell wie folgt:

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

Ich musste dies tun, damit das Networking in der Chroot funktioniert, worauf ich als Nächstes eingehen werde:

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

Jetzt chroot auf das neue System und installiere lvm2:

chroot /target
apt-get install lvm2

Beachten Sie, dass update-initramfs ausgeführt wird. Geben Sie jetzt einfach exit und reboot ein, und Ihr System sollte ordnungsgemäß booten.

Das hat auch bei mir geklappt.

vgchange -a y -name of volume group-

Nach einem Kernel-Patch konnte mein RHEL-System nicht neu gestartet werden. Beschwerde einer fehlenden /dev/mapper/VG-lvDatei.

Auf Einzelplatz hochgefahren und auskommentiert /etc/fstab. Als ich online war, stellte ich fest, dass meine verschlüsselte Festplatte mit "Unbekanntes Gerät" angezeigt wurde pvs.

Behoben, aber noch keine Gerätedateien für die Volume-Gruppe. Durch Ausführen des obigen Befehls wurden die Gerätezuordnungsdateien neu erstellt und ich konnte sie bereitstellen.

Ich hatte nach dem Upgrade meines Debians ein ähnliches Problem. Während des Neustarts erschien mir folgende Meldung:

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

Ich habe die Lösung hier gefunden :

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

Und voilà, es hat sich danach gut gebootet.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616689 ist hier relevant. Dies hat mit Zeitüberschreitungen zu tun, bei denen lvm root nicht rechtzeitig angezeigt wird.