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

Question

Eu redimensionei meu volume lógico e sistema de arquivos e tudo correu bem. Eu instalei o novo kernel e após a reinicialização não consigo inicializar nem o atual nem o anterior. Eu recebo erro de grupo de volume 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. Eu não fui capaz de montá-los depois de ativar, eu tenho 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 porque os volumes estão inativos no momento da inicialização?

Atenciosamente,

Marek

EDIT: Mais investigações revelaram que isso não tinha nada a ver com o redimensionamento de volumes lógicos. O fato de que os volumes lógicos tiveram que ser ativados manualmente no shell cinza após falha na inicialização e possível solução para esse problema é abordado na minha resposta abaixo.

    

Answer 1

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 em relação ao fato de isso acontecer dentro do KVM). Isso é abordado na discussão a seguir . No meu caso particular (Debian Squeeze) a solução é a seguinte:

• faça o backup do script / usr / share / initramfs-tools / scripts / local-top / lvm2
• aplica o patch do relatório de bug 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
 }

    

Answer 2

Crie um script de inicialização em /etc/init.d/lvm contendo 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 sistemas Debian.

    

Answer 3

Eu também tive esse problema. No final, isso foi o que pareceu resolver:

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 eu tentei:

1. seu patch
2. diff /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

Eu passei por e desfiz as outras alterações, essa é a única que importava para mim, embora seja provavelmente a menos elegante.

    

Answer 4

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

Não sei ao certo o que faria com que ficassem inativos depois de uma reinicialização.

    

Answer 5

Sem nenhum dos detalhes de configuração ou mensagens de erro, precisaríamos dar uma resposta real, eu vou dar uma punhalada no escuro com grub-mkdevicemap como uma solução.

    

Answer 6

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

Você também pode fazer isso manualmente descompactando o initramfs e alterando /etc/lvm/lvm.conf (ou algo parecido) na sua imagem initramfs e, em seguida, empacotando novamente.

    

Answer 7

Eu tenho o mesmo problema no meu ambiente executando o Red Hat 7.4 como convidado KVM. Estou executando o qemu-kvm-1.5.3-141 e o virt-manager 1.4.1. No começo eu estava rodando o Red Hat 7.2 como convidado sem nenhum problema, mas depois de atualizar o release menor de 7.2 para 7.4 e do kernel para a última versão 3.10.0-693.5.2, algo deu errado e não pude inicializar minha partição / var LV Mais. O sistema foi para o modo de emergência pedindo senha de root. Entrando com a senha do root e executando os comandos lvm vgchange -ay e systemctl default , consegui ativar meu /var LV e inicializar o sistema.

Ainda não descobri o que causa esse problema, mas minha solução foi incluir o LV /var em /etc/default/grub , como 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"

Em seguida, tive de executar grub2-mkconfig -o /boot/grub2/grub.cfg e verificar se o rd.lvm.lv=vg_local/var estava incluído na linha vmlinuz de /boot/grub2/grub.cfg . Depois de reiniciar o sistema, não recebi mais o erro de ativar meu /var LV e o sistema concluiu o processo de inicialização com sucesso.

    

Answer 8

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

para o teste em /usr/share/invramfs-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 de raiz nunca ativado.

atualizou o / etc / fstab de

/dev/vgname/root        /

para

/dev/mapper/vgname-root   /

e fez:

update-grub
grub-install /dev/sda

resolvi meu problema