I volumi logici sono inattivi al momento dell'avvio

Ho ridimensionato il mio volume logico e il mio filesystem e tutto è andato liscio. Ho installato un nuovo kernel e dopo il riavvio non riesco ad avviare né quello attuale né quello precedente. Ottengo l'errore del gruppo di volumi non trovato dopo aver selezionato l'opzione grub (2). L'ispezione dalla casella occupata rivela che i volumi non sono registrati con il mapper del dispositivo e che sono inattivi. Non sono riuscito a montarli dopo l'attivazione, ho riscontrato un errore di file non trovato (mount / dev / mapper / all-root / mnt).

Qualche idea su come procedere o renderli attivi al momento dell'avvio? O perché i volumi sono improvvisamente inattivi all'avvio?

Saluti,

Marek

EDIT: ulteriori indagini hanno rivelato che questo non aveva nulla a che fare con il ridimensionamento dei volumi logici. Il fatto che i volumi logici dovevano essere attivati ​​manualmente nella shell ash dopo l'avvio non riuscito e la possibile soluzione a questo problema è trattato nella mia risposta di seguito.

Quindi alla fine sono riuscito a risolverlo. C'è un problema (bug) nel rilevare i volumi logici, che è una sorta di condizione di competizione (forse nel mio caso per quanto riguarda il fatto che ciò avvenga all'interno di KVM). Questo è trattato nella seguente discussione . Nel mio caso particolare (Debian Squeeze) la soluzione è la seguente:

• eseguire il backup dello script / usr / share / initramfs-tools / script / local-top / lvm2
• applica la patch dal citato bug report
• eseguire update-initramfs -u

Questo mi ha aiutato, spero che possa aiutare gli altri (stranamente, questo non fa ancora parte del mainstream).

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

Di seguito è una copia per i posteri.

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

Creare uno script di avvio /etc/init.d/lvmcontenente quanto segue:

#!/bin/sh

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

exit 0

Quindi eseguire i comandi:

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

Dovrebbe fare il trucco per i sistemi Debian.

Ho avuto anche questo problema. Alla fine questo è ciò che sembrava risolverlo:

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"

Altre cose che ho provato:

1. la tua 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

Ho attraversato e annullato gli altri cambiamenti, questo è l'unico che contava per me, anche se probabilmente è il meno elegante.

Se vgscan"trova" i volumi, dovresti essere in grado di attivarli 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

Non sono sicuro di cosa li renderebbe inattivi dopo un riavvio.

Senza nessuno dei dettagli di configurazione o messaggi di errore di cui avremmo bisogno per dare una risposta effettiva, mi prenderò una pugnalata al buio grub-mkdevicemapcome soluzione.

Supponendo che il tuo sistema usi initramfs, probabilmente c'è un problema di configurazione lì. Dovresti aggiornare l'immagine di initramfs che è stata avviata all'avvio da grub (in Debian lo fai con update-initramfs, non conosci altre distro).

Puoi anche farlo a mano scompattando initramfs e modificando /etc/lvm/lvm.conf (o qualcosa del genere) nell'immagine di initramfs e quindi reimballandolo di nuovo.

Ho lo stesso problema nel mio ambiente con Red Hat 7.4 come guest KVM. Sto eseguendo qemu-kvm-1.5.3-141 e virt-manager 1.4.1. All'inizio stavo eseguendo Red Hat 7.2 come guest senza alcun problema, ma dopo aver aggiornato la versione minore da 7.2 a 7.4 e il kernel all'ultima versione 3.10.0-693.5.2, qualcosa è andato storto e non sono riuscito ad avviare la mia partizione / var LV Di Più. Il sistema è passato in modalità di emergenza chiedendo la password di root. Entrando con la password di root ed eseguendo i comandi lvm vgchange -aye systemctl defaultsono stato in grado di attivare il mio /varLV e avviare il sistema.

Non ho capito che cosa provoca questo problema, ma la mia soluzione era quella di includere il LV /varin /etc/default/grubcome si vede qui sotto:

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"

Quindi ho dovuto eseguire grub2-mkconfig -o /boot/grub2/grub.cfge verificare se rd.lvm.lv=vg_local/varera incluso nella riga vmlinuz di /boot/grub2/grub.cfg. Dopo aver riavviato il sistema, non ho più ricevuto l'errore per l'attivazione di /varLV e il sistema ha completato con successo il processo di avvio.

nel mio caso ho capito che la radice di grub era root = / dev / vgname / root

quindi il 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      

era sempre falso. e il volume di root non è mai stato attivato.

aggiornato / etc / fstab da

/dev/vgname/root        /

per

/dev/mapper/vgname-root   /

e ha fatto:

update-grub
grub-install /dev/sda

risolto il mio problema

ci siamo imbattuti in questo problema e abbiamo trovato che la disattivazione di lvmetadimpostando use_lvmetad=0in /etc/lvm/lvm.confcostrette volumi da trovare e Mae accessibili in fase di boot.