Volumes lógicos estão inativos no momento da inicialização

Redimensionei meu volume lógico e sistema de arquivos e tudo correu bem. Instalei o novo kernel e, após a reinicialização, não consigo inicializar nem o atual nem o anterior. Eu recebo o erro de grupo de volumes não encontrado após selecionar a opção grub (2). A inspeção da caixa ocupada revela que os volumes não estão registrados no mapeador de dispositivos e que estão inativos. Não consegui montá-los após a ativação, obtive um erro de arquivo não encontrado (mount / dev / mapper / all-root / mnt).

Alguma idéia de como proceder ou ativá-las no momento da inicialização? Ou por que os volumes ficam repentinamente inativos no momento da inicialização?

Saudações,

Marek

EDIT: Uma investigação mais aprofundada revelou que isso não tinha nada a ver com o redimensionamento de volumes lógicos. O fato de que os volumes lógicos precisaram ser ativados manualmente no ash shell após falha na inicialização e possível solução para esse problema é abordado na minha resposta abaixo.

Então, eu consegui resolver isso eventualmente. Há um problema (bug) na detecção de volumes lógicos, que é algum tipo de condição de corrida (talvez no meu caso, com relação ao fato de que isso acontece dentro do KVM). Isso é abordado na discussão a seguir . No meu caso particular (Debian Squeeze), a solução é a seguinte:

• faça backup do script / usr / share / initramfs-tools / scripts / local-top / lvm2
• aplique o patch do relatório de erro mencionado
• execute update-initramfs -u

Isso me ajudou, espero que ajude os outros (estranhamente, isso ainda não faz parte do mainstream).

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

Abaixo está uma cópia para a posteridade.

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

Crie um script de inicialização /etc/init.d/lvmcontendo o seguinte:

#!/bin/sh

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

exit 0

Em seguida, execute os comandos:

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

Deve fazer o truque para os sistemas Debian.

Eu tive esse problema também. No final, foi o que pareceu corrigi-lo:

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"

Outras coisas que tentei:

1. seu 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

Passei e desfiz as outras mudanças, essa é a única que importava para mim, embora seja provavelmente a menos elegante.

Se vgscan"encontrar" os volumes, você poderá ativá-los comvgchange -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

Não sei ao certo o que os levaria a ficar inativos após uma reinicialização.

Sem nenhum dos detalhes de configuração ou mensagens de erro que precisaríamos dar uma resposta real, vou dar uma facada no escuro grub-mkdevicemapcomo uma solução.

Supondo que o seu sistema use initramfs, provavelmente há um problema de configuração. Você deve atualizar sua imagem initramfs iniciada no momento da inicialização pelo grub (no Debian você faz isso com update-initramfs, não conhece outras distros).

Você também pode fazer isso manualmente, descompactando initramfs e alterando /etc/lvm/lvm.conf (ou algo parecido) na sua imagem initramfs e depois reembalando-a novamente.

Eu tenho o mesmo problema no meu ambiente executando o Red Hat 7.4 como convidado da KVM. Estou executando o qemu-kvm-1.5.3-141 e o virt-manager 1.4.1. No começo, eu estava executando o Red Hat 7.2 como convidado sem nenhum problema, mas depois de atualizar a versão secundária do 7.2 para 7.4 e o kernel para a versão mais recente 3.10.0-693.5.2, algo deu errado e não foi possível inicializar minha partição LV / var Mais. O sistema entrou no modo de emergência solicitando senha de root. Entrando com senha de root e executar os comandos lvm vgchange -aye systemctl defaulteu era capaz de ativar meu /varLV e inicializar o sistema.

Não descobri o que causa esse problema, mas minha solução alternativa foi incluir o LV /var, /etc/default/grubcomo você vê abaixo:

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"

Então eu tive que correr grub2-mkconfig -o /boot/grub2/grub.cfge verificar se o rd.lvm.lv=vg_local/varfoi incluído na linha vmlinuz de /boot/grub2/grub.cfg. Depois de reiniciar o sistema, não recebi mais o erro de ativar meu /varLV e o sistema conclui o processo de inicialização com êxito.

descobri no meu caso que a raiz do grub era root = / dev / vgname / root

então o teste em / 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      

sempre foi falso. e volume raiz nunca ativado.

atualizado / etc / fstab de

/dev/vgname/root        /

para

/dev/mapper/vgname-root   /

e fez:

update-grub
grub-install /dev/sda

resolveu meu problema

nós corremos para esse problema e descobriu que a desativação lvmetad, definindo use_lvmetad=0em /etc/lvm/lvm.confforçaram os volumes para ser encontrado e mae acessível em boot.