Logische Volumes sind beim Booten inaktiv

Ich habe die Größe meines logischen Volumes und meines Dateisystems geändert und alles verlief reibungslos. Ich habe einen neuen Kernel installiert und nach dem Neustart kann ich weder den aktuellen noch den früheren starten. Nach Auswahl der Option grub (2) wird der Fehler "Volume Group Not Found" angezeigt. Die Überprüfung von der Besetztbox zeigt, dass die Volumes nicht im Geräte-Mapper registriert sind und inaktiv sind. Ich konnte sie nach der Aktivierung nicht mounten. Ich habe den Fehler "Datei nicht gefunden" gefunden (mount / dev / mapper / all-root / mnt).

Irgendwelche Ideen, wie Sie fortfahren oder sie beim Booten aktivieren können? Oder warum sind die Volumes beim Booten plötzlich inaktiv?

Grüße,

Marek

EDIT: Weitere Untersuchungen ergaben, dass dies nichts mit der Größenänderung logischer Volumes zu tun hat. Die Tatsache, dass logische Volumes nach einem fehlgeschlagenen Start und einer möglichen Lösung für dieses Problem manuell in der Ash-Shell aktiviert werden mussten, wird in meiner Antwort unten behandelt.

Also habe ich es irgendwann geschafft, das zu lösen. Es gibt ein Problem (Fehler) beim Erkennen logischer Volumes, was eine Art Race-Bedingung ist (möglicherweise in meinem Fall in Bezug auf die Tatsache, dass dies in KVM geschieht). Dies wird in der folgenden Diskussion behandelt . In meinem speziellen Fall (Debian Squeeze) lautet die Lösung wie folgt:

• Sichern Sie das Skript / usr / share / initramfs-tools / scripts / local-top / lvm2
• Wenden Sie den Patch aus dem genannten Fehlerbericht an
• Führen Sie update-initramfs -u aus

Das hat mir geholfen, hoffe es hilft anderen (seltsamerweise ist dies noch nicht Teil des Mainstreams).

Link zum Patch: _http: //bugs.debian.org/cgi-bin/bugreport.cgi? Msg = 10; Dateiname = lvm2_wait-lvm.patch; att = 1; Fehler = 568838

Unten ist eine Kopie für die Nachwelt.

--- /usr/share/initramfs-tools/scripts/local-top/lvm2 2009-08-17 19:28:09.000000000 +0200
+++ /usr/share/initramfs-tools/scripts/local-top/lvm2 2010-02-19 23:22:14.000000000 +0100
@@ -45,12 +45,30 @@

  eval $(dmsetup splitname --nameprefixes --noheadings --rows "$dev")

- if [ "$DM_VG_NAME" ] && [ "$DM_LV_NAME" ]; then
-   lvm lvchange -aly --ignorelockingfailure "$DM_VG_NAME/$DM_LV_NAME"
-   rc=$?
-   if [ $rc = 5 ]; then
-     echo "Unable to find LVM volume $DM_VG_NAME/$DM_LV_NAME"
-   fi
+ # Make sure that we have non-empty volume group and logical volume
+ if [ -z "$DM_VG_NAME" ] || [ -z "$DM_LV_NAME" ]; then
+   return 1
+ fi
+
+ # If the logical volume hasn't shown up yet, give it a little while
+ # to deal with LVM on removable devices (inspired from scripts/local)
+ fulldev="/dev/$DM_VG_NAME/$DM_LV_NAME"
+ if [ -z "`lvm lvscan -a --ignorelockingfailure |grep $fulldev`" ]; then
+   # Use default root delay
+   slumber=$(( ${ROOTDELAY:-180} * 10 ))
+
+   while [ -z "`lvm lvscan -a --ignorelockingfailure |grep $fulldev`" ]; do
+     /bin/sleep 0.1
+     slumber=$(( ${slumber} - 1 ))
+     [ ${slumber} -gt 0 ] || break
+   done
+ fi
+
+ # Activate logical volume
+ lvm lvchange -aly --ignorelockingfailure "$DM_VG_NAME/$DM_LV_NAME"
+ rc=$?
+ if [ $rc = 5 ]; then
+   echo "Unable to find LVM volume $DM_VG_NAME/$DM_LV_NAME"
  fi
 }

Erstellen Sie ein Startskript /etc/init.d/lvm, das Folgendes enthält:

#!/bin/sh

case "$1" in
 start)
    /sbin/vgscan
    /sbin/vgchange -ay
    ;;
  stop)
    /sbin/vgchange -an
    ;;
  restart|force-reload)
    ;;
esac

exit 0

Führen Sie dann die folgenden Befehle aus:

chmod 0755 /etc/init.d/lvm
update-rc.d lvm start 26 S . stop 82 1 .

Sollte den Trick für Debian-Systeme tun.

Ich hatte auch dieses Problem. Am Ende schien dies das Problem zu beheben:

diff -u /usr/share/initramfs-tools/scripts/local-top/lvm2-backup /usr/share/initramfs-tools/scripts/local-top/lvm2
--- /usr/share/initramfs-tools/scripts/local-top/lvm2-backup    2014-06-06 19:55:19.249857946 -0400
+++ /usr/share/initramfs-tools/scripts/local-top/lvm2   2014-06-21 01:26:01.015289945 -0400
@@ -60,6 +60,7 @@

 modprobe -q dm-mod

+lvm vgchange -ay
 activate_vg "$ROOT"
 activate_vg "$resume"

Andere Dinge, die ich versucht habe:

1. dein Patch
2. diffing /etc/lvm/lvm.conf
3. GRUB_PRELOAD_MODULES="lvm"
4. GRUB_CMDLINE_LINUX="scsi_mod.scan=sync"
5. sudo grub-install /dev/sda && sudo grub-install /dev/sdb && sudo update-grub && sudo update-initramfs -u -k all
6. sudo apt-get install --reinstall lvm2 grub-pc grub-common

Ich ging durch und machte die anderen Änderungen rückgängig, dies ist die einzige, die für mich wichtig war, obwohl es wahrscheinlich die am wenigsten elegante ist.

Wenn vgscanSie die Volumes "finden", sollten Sie sie mit aktivieren könnenvgchange -ay /dev/volumegroupname

$ sudo vgscan
[sudo] password for username: 
  Reading all physical volumes.  This may take a while...
  Found volume group "vg02" using metadata type lvm2
  Found volume group "vg00" using metadata type lvm2

$ sudo vgchange -ay /dev/vg02
  7 logical volume(s) in volume group "vg00" now active

Ich bin mir nicht sicher, was dazu führen würde, dass sie nach einem Neustart inaktiv werden.

Ohne die Konfigurationsdetails oder Fehlermeldungen, die wir benötigen, um eine tatsächliche Antwort zu geben, werde ich grub-mkdevicemapals Lösung einen Stich in die Dunkelheit machen .

Angenommen, Ihr System verwendet initramfs, liegt dort wahrscheinlich ein Konfigurationsproblem vor. Sie sollten Ihr initramfs-Image aktualisieren, das beim Booten von grub gestartet wurde (in Debian tun Sie dies mit update-initramfs, wissen nichts über andere Distributionen).

Sie können dies auch von Hand tun, indem Sie initramfs entpacken und /etc/lvm/lvm.conf (oder ähnliches) in Ihrem initramfs-Image ändern und dann erneut verpacken.

Ich habe das gleiche Problem in meiner Umgebung, in der Red Hat 7.4 als KVM-Gast ausgeführt wird. Ich verwende qemu-kvm-1.5.3-141 und virt-manager 1.4.1. Zuerst habe ich Red Hat 7.2 ohne Probleme als Gast ausgeführt, aber nach dem Upgrade der Nebenversion von 7.2 auf 7.4 und des Kernels auf die neueste Version 3.10.0-693.5.2 ist ein Fehler aufgetreten und meine / var LV-Partition konnte nicht gestartet werden Mehr. Das System ging in den Notfallmodus und fragte nach dem Root-Passwort. Die Eingabe mit root - Passwort und die Befehle ausführen lvm vgchange -ayund systemctl defaultich konnte meine aktivieren /varLV und das System zu booten.

Ich habe herausgefunden, was nicht dieses Problem verursacht, aber meine Abhilfe war die LV enthält /varin /etc/default/grubwie Sie unten sehen:

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=vg_local/root rd.lvm.lv=vg_local/var rd.lvm.lv=vg_local/swap rhgb quiet biosdevname=0 net.ifnames=0 ipv6.disable=1"

Dann musste ich laufen grub2-mkconfig -o /boot/grub2/grub.cfgund prüfen, ob das rd.lvm.lv=vg_local/varin der vmlinuz-Zeile von enthalten war /boot/grub2/grub.cfg. Nach dem Neustart des Systems wurde der Fehler zum Aktivieren meines /varLV nicht mehr angezeigt, und das System schließt den Startvorgang mit Erfolg ab.

Ich habe in meinem Fall herausgefunden, dass die Madenwurzel root = / dev / vgname / root ist

Also der Test in / usr / share / initramfs-tools / scripts / local-top / lvm2

  # Make sure that we have a d-m path
  dev="${dev#/dev/mapper/}"          
  if [ "$dev" = "$1" ]; then         
    return 1                         
  fi      

war immer falsch. und Root-Volume nie aktiviert.

aktualisiert / etc / fstab von

/dev/vgname/root        /

zu

/dev/mapper/vgname-root   /

und tat:

update-grub
grub-install /dev/sda

löste mein Problem

ich lief in dieses Problem und fand , dass das Deaktivieren lvmetaddurch Einstellen use_lvmetad=0in /etc/lvm/lvm.confZwängen der Volumina beim Booten gefunden und mae zugänglich werden.