Woluminy logiczne są nieaktywne podczas uruchamiania

Zmieniłem rozmiar mojego logicznego woluminu i systemu plików i wszystko poszło gładko. Zainstalowałem nowe jądro i po ponownym uruchomieniu nie mogę uruchomić ani obecnego, ani poprzedniego. Po wybraniu opcji grub (2) pojawia się błąd „Nie znaleziono grupy woluminów”. Inspekcja z zajętego pola ujawnia, że ​​woluminy nie są zarejestrowane w programie mapującym urządzenia i że są nieaktywne. Nie byłem w stanie zamontować ich po aktywacji, dostałem błąd znalezienia pliku (mount / dev / mapper / all-root / mnt).

Jakieś pomysły, jak postępować lub aktywować je podczas uruchamiania? Lub dlaczego woluminy są nagle nieaktywne podczas uruchamiania?

Pozdrowienia,

Marek

EDYCJA: Dalsze dochodzenie ujawniło, że nie miało to nic wspólnego ze zmianą wielkości woluminów logicznych. Fakt, że woluminy logiczne musiały zostać aktywowane ręcznie w powłoce popiołu po nieudanym rozruchu i możliwym rozwiązaniu tego problemu, znajduje się w mojej odpowiedzi poniżej.

W końcu udało mi się to rozwiązać. Wystąpił problem (błąd) w wykrywaniu woluminów logicznych, co jest pewnego rodzaju warunkiem wyścigu (może w moim przypadku w związku z faktem, że dzieje się to w KVM). Jest to omówione w poniższej dyskusji . W moim szczególnym przypadku (Debian Squeeze) rozwiązanie jest następujące:

• wykonaj kopię zapasową skryptu / usr / share / initramfs-tools / scripts / local-top / lvm2
• zastosuj łatkę ze wspomnianego raportu o błędzie
• uruchom update-initramfs -u

Pomogło mi to, mam nadzieję, że pomoże innym (co dziwne, nie jest to jeszcze częścią głównego nurtu).

Link do łatki: _http: //bugs.debian.org/cgi-bin/bugreport.cgi? Msg = 10; nazwa_pliku = lvm2_wait-lvm.patch; att = 1; błąd = 568838

Poniżej znajduje się kopia dla potomności.

--- /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
 }

Utwórz skrypt startowy /etc/init.d/lvmzawierający:

#!/bin/sh

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

exit 0

Następnie wykonaj polecenia:

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

Powinien załatwić sprawę w systemach Debian.

Też miałem ten problem. Ostatecznie wydaje się, że to naprawia:

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"

Inne rzeczy, których próbowałem:

1. twoja łatka
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

Przeszedłem i cofnąłem pozostałe zmiany, to jedyna, która się dla mnie liczyła, choć prawdopodobnie jest najmniej elegancka.

Jeśli vgscan„znajdzie” woluminy, powinieneś być w stanie je aktywowaćvgchange -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

Nie jestem jednak pewien, co spowodowałoby, że staną się nieaktywni po ponownym uruchomieniu.

Bez szczegółów konfiguracji lub komunikatów o błędach, które musielibyśmy udzielić rzeczywistej odpowiedzi, grub-mkdevicemapjako rozwiązanie wezmę dźgnięcie w ciemność .

Zakładając, że Twój system używa initramfs, prawdopodobnie występuje tam problem z konfiguracją. Powinieneś zaktualizować obraz initramfs, który zaczął się w czasie uruchamiania przez grub (w Debianie robisz to z update-initramfs, nie wiem o innych dystrybucjach).

Możesz to również zrobić ręcznie, rozpakowując initramfs i zmieniając /etc/lvm/lvm.conf (lub coś podobnego) na obrazie initramfs, a następnie ponownie go pakując.

Mam ten sam problem w moim środowisku, w którym działa Red Hat 7.4 jako gość KVM. Używam qemu-kvm-1.5.3-141 i virt-manager 1.4.1. Na początku działałem jako Red Hat 7.2 bez problemu, ale po aktualizacji mniejszej wersji z 7.2 do 7.4 i jądra do najnowszej wersji 3.10.0-693.5.2 coś poszło nie tak i nie mogłem uruchomić żadnej partycji LV / var więcej. System przeszedł do trybu awaryjnego z prośbą o hasło roota. Wprowadzanie hasłem root i systemem poleceń lvm vgchange -ayi systemctl defaultbyłem w stanie aktywować /varLV i uruchomić system.

I nie zorientowali się, co powoduje ten problem, ale mój obejście było to LV /varw /etc/default/grubjak widać poniżej:

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"

Następnie musiałem uruchomić grub2-mkconfig -o /boot/grub2/grub.cfgi sprawdzić, czy rd.lvm.lv=vg_local/varzostał uwzględniony w linii vmlinuz /boot/grub2/grub.cfg. Po ponownym uruchomieniu systemu nie dostałem już błędu aktywacji mojego /varLV i system kończy proces rozruchu z powodzeniem.

zorientowałem się w moim przypadku, że grub root to root = / dev / vgname / root

więc test w / 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      

zawsze było fałszywe. i wolumin root nigdy nie został aktywowany.

zaktualizowano / etc / fstab z

/dev/vgname/root        /

do

/dev/mapper/vgname-root   /

I zrobił:

update-grub
grub-install /dev/sda

rozwiązał mój problem

wpadliśmy na ten problem i okazało się, że wyłączenie lvmetadprzez ustawienie use_lvmetad=0w /etc/lvm/lvm.confprzymusowych wielkości można znaleźć i mae dostępny w bagażniku.