Les volumes logiques sont inactifs au démarrage

J'ai redimensionné mon volume logique et mon système de fichiers et tout s'est bien passé. J'ai installé un nouveau noyau et après le redémarrage, je ne peux pas démarrer ni actuel ni ancien. J'obtiens une erreur de groupe de volumes introuvable après avoir sélectionné l'option grub (2). L'inspection de la zone occupée révèle que les volumes ne sont pas enregistrés auprès du mappeur de périphériques et qu'ils sont inactifs. Je n'ai pas pu les monter après l'activation, j'ai eu une erreur de fichier introuvable (mount / dev / mapper / all-root / mnt).

Avez-vous des idées sur la façon de procéder ou de les rendre actifs au démarrage? Ou pourquoi les volumes sont-ils soudainement inactifs au démarrage?

Cordialement,

Marek

EDIT: Une enquête plus approfondie a révélé que cela n'avait rien à voir avec le redimensionnement des volumes logiques. Le fait que les volumes logiques aient dû être activés manuellement dans le shell ash après un échec de démarrage et une solution possible à ce problème est couvert dans ma réponse ci-dessous.

J'ai finalement réussi à résoudre ce problème. Il y a un problème (bogue) avec la détection des volumes logiques, qui est une sorte de condition de concurrence (peut-être dans mon cas concernant le fait que cela se produit à l'intérieur de KVM). Ceci est couvert dans la discussion suivante . Dans mon cas particulier (Debian Squeeze), la solution est la suivante:

• sauvegarder le script / usr / share / initramfs-tools / scripts / local-top / lvm2
• appliquer le patch du rapport de bogue mentionné
• exécutez update-initramfs -u

Cela m'a aidé, j'espère que cela aidera les autres (étrangement, cela ne fait pas encore partie du courant dominant).

Lien vers le correctif: _http: //bugs.debian.org/cgi-bin/bugreport.cgi? Msg = 10; nom de fichier = lvm2_wait-lvm.patch; att = 1; bug = 568838

Ci-dessous, une copie pour la postérité.

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

Créez un script de démarrage /etc/init.d/lvmcontenant les éléments suivants:

#!/bin/sh

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

exit 0

Exécutez ensuite les commandes:

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

Devrait faire l'affaire pour les systèmes Debian.

J'ai eu ce problème également. En fin de compte, c'est ce qui semblait le résoudre:

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"

J'ai essayé d'autres choses:

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

J'ai parcouru et défait les autres changements, c'est le seul qui comptait pour moi, bien que ce soit probablement le moins élégant.

Si vgscan"trouve" les volumes, vous devriez pouvoir les activer avecvgchange -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

Je ne sais pas ce qui pourrait les rendre inactifs après un redémarrage.

Sans aucun des détails de configuration ou des messages d'erreur dont nous aurions besoin pour donner une réponse réelle, je vais essayer dans le noir avec grub-mkdevicemapcomme solution.

En supposant que votre système utilise initramfs, il y a probablement un problème de configuration. Vous devez mettre à jour votre image initramfs qui a démarré au démarrage par grub (dans Debian vous le faites avec update-initramfs, je ne connais pas les autres distributions).

Vous pouvez également le faire à la main en décompactant initramfs et en changeant /etc/lvm/lvm.conf (ou quelque chose comme ça) dans votre image initramfs, puis en la remballant à nouveau.

J'ai le même problème dans mon environnement exécutant Red Hat 7.4 en tant qu'invité KVM. J'utilise qemu-kvm-1.5.3-141 et virt-manager 1.4.1. Au début, j'utilisais Red Hat 7.2 en tant qu'invité sans aucun problème, mais après la mise à niveau d'une version mineure de 7.2 à 7.4 et du noyau vers la dernière version 3.10.0-693.5.2, quelque chose s'est mal passé et n'a pas pu démarrer ma partition LV / var plus. Le système est passé en mode d'urgence pour demander le mot de passe root. Entrer avec le mot de passe root et exécuter les commandes lvm vgchange -ayet systemctl defaultj'ai pu activer mon /varLV et démarrer le système.

Je ne l' ai pas compris ce qui cause ce problème, mais ma solution était d'inclure le LV /vardans /etc/default/grubcomme vous le voyez ci - dessous:

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"

Ensuite, j'ai dû courir grub2-mkconfig -o /boot/grub2/grub.cfget vérifier si le rd.lvm.lv=vg_local/varétait inclus dans la ligne vmlinuz de /boot/grub2/grub.cfg. Après le redémarrage du système, je n'ai plus eu l'erreur d'activer mon /varLV et le système termine le processus de démarrage avec succès.

compris dans mon cas que la racine grub était root = / dev / vgname / root

donc le test dans / 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      

était toujours faux. et le volume racine n'a jamais été activé.

/ etc / fstab mis à jour depuis

/dev/vgname/root        /

à

/dev/mapper/vgname-root   /

et a fait:

update-grub
grub-install /dev/sda

résolu mon problème

nous avons rencontré ce problème et trouvé que la désactivation lvmetadpar la mise use_lvmetad=0en ont /etc/lvm/lvm.confforcé les volumes à trouver et mae accessible au démarrage.