Los volúmenes lógicos están inactivos al momento del arranque

Cambié el tamaño de mi volumen lógico y sistema de archivos y todo salió bien. Instalé un nuevo kernel y después de reiniciar no puedo arrancar ni el actual ni el anterior. Obtengo un error de grupo de volumen no encontrado después de seleccionar la opción grub (2). La inspección desde el cuadro ocupado muestra que los volúmenes no están registrados con el mapeador de dispositivos y que están inactivos. No pude montarlos después de la activación, recibí un error de archivo no encontrado (mount / dev / mapper / all-root / mnt).

¿Alguna idea de cómo proceder o activarlos en el momento del arranque? ¿O por qué los volúmenes están repentinamente inactivos en el momento del arranque?

Saludos,

Marek

EDITAR: Una investigación adicional reveló que esto no tenía nada que ver con el cambio de tamaño de los volúmenes lógicos. El hecho de que los volúmenes lógicos tuvieron que activarse manualmente en el shell de ceniza después del arranque fallido y la posible solución a este problema se cubre en mi respuesta a continuación.

Entonces logré resolver esto eventualmente. Hay un problema (error) con la detección de volúmenes lógicos, que es una especie de condición de carrera (tal vez en mi caso con respecto al hecho de que esto sucede dentro de KVM). Esto se trata en la siguiente discusión . En mi caso particular (Debian Squeeze) la solución es la siguiente:

• copia de seguridad del script / usr / share / initramfs-tools / scripts / local-top / lvm2
• aplicar el parche del informe de error mencionado
• ejecutar update-initramfs -u

Esto me ayudó, espero que ayude a otros (curiosamente, esto todavía no es parte de la corriente principal).

Enlace al parche: _http: //bugs.debian.org/cgi-bin/bugreport.cgi? Msg = 10; filename = lvm2_wait-lvm.patch; att = 1; bug = 568838

A continuación hay una copia para la posteridad.

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

Cree un script de inicio que /etc/init.d/lvmcontenga lo siguiente:

#!/bin/sh

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

exit 0

Luego ejecute los comandos:

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

Debería hacer el truco para los sistemas Debian.

Yo tuve este problema también. Al final, esto es lo que pareció solucionarlo:

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"

Otras cosas que probé:

1. tu parche
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

Pasé y deshice los otros cambios, este es el único que me importó, aunque probablemente sea el menos elegante.

Si vgscan"encuentra" los volúmenes, debería poder activarlos convgchange -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

Sin embargo, no estoy seguro de qué los haría quedar inactivos después de un reinicio.

Sin ninguno de los detalles de configuración o mensajes de error que necesitaríamos para dar una respuesta real, tomaré una puñalada en la oscuridad con grub-mkdevicemapuna solución.

Suponiendo que su sistema usa initramfs, probablemente haya un problema de configuración allí. Debe actualizar su imagen initramfs que se inicia en el momento del arranque mediante grub (en Debian lo hace con update-initramfs, no conoce otras distribuciones).

También puede hacer esto a mano desempacando initramfs y cambiando /etc/lvm/lvm.conf (o algo así) en su imagen initramfs y luego vuelva a embalarlo.

Tengo el mismo problema en mi entorno al ejecutar Red Hat 7.4 como invitado KVM. Estoy ejecutando qemu-kvm-1.5.3-141 y virt-manager 1.4.1. Al principio estaba ejecutando Red Hat 7.2 como invitado sin ningún problema, pero después de actualizar una versión menor de 7.2 a 7.4 y kernel a la última versión 3.10.0-693.5.2, algo salió mal y no pude iniciar mi partición / var LV. más. El sistema pasó al modo de emergencia solicitando la contraseña de root. Entrando con contraseña de root y ejecutar los comandos lvm vgchange -ayy systemctl defaultyo era capaz de activar mi /varLV y arranque el sistema.

No he descubierto lo que causa este problema, pero mi solución era incluir la LV /varen /etc/default/grublo que sigue a continuación:

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"

Luego tuve que correr grub2-mkconfig -o /boot/grub2/grub.cfgy comprobar si rd.lvm.lv=vg_local/varestaba incluido en la línea vmlinuz de /boot/grub2/grub.cfg. Después de reiniciar el sistema, ya no recibí el error para activar mi /varLV y el sistema completa el proceso de inicio con éxito.

descubrí en mi caso que la raíz de grub era root = / dev / vgname / root

entonces la prueba en / 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      

Siempre fue falso. y el volumen raíz nunca se activó.

actualizado / etc / fstab desde

/dev/vgname/root        /

a

/dev/mapper/vgname-root   /

y lo hizo:

update-grub
grub-install /dev/sda

resuelto mi problema

nos encontramos con este problema y encontramos que la desactivación lvmetadmediante el establecimiento use_lvmetad=0de /etc/lvm/lvm.confforzados los volúmenes que se encuentran Mae y accesible en el arranque.