web-dev-qa-db-ja.com

論理ボリュームは起動時に非アクティブです

論理ボリュームとファイルシステムのサイズを変更したところ、すべてスムーズに進みました。新しいカーネルをインストールしましたが、再起動後、現在のカーネルも以前のカーネルもブートできません。 grub（2）オプションを選択した後、ボリュームグループが見つからないというエラーが表示されます。ビジーボックスから検査すると、ボリュームがデバイスマッパーに登録されておらず、ボリュームが非アクティブであることがわかります。アクティベート後にそれらをマウントできませんでした。ファイルが見つからないというエラーが発生しました（mount/dev/mapper/all-root/mnt）。

起動時にそれらを続行またはアクティブにする方法についてのアイデアはありますか？または、起動時にボリュームが突然非アクティブになるのはなぜですか？

よろしく、

マレク

編集：さらなる調査により、これは論理ボリュームのサイズ変更とは何の関係もないことが明らかになりました。ブートが失敗した後、ash Shellで論理ボリュームを手動でアクティブ化する必要があるという事実と、この問題に対する可能な解決策は、以下の私の回答でカバーされています。

linuxlvminitramfs
10
zeratul021

結局これを解決することができました。論理ボリュームの検出に問題（バグ）があります。これは、ある種の競合状態です（おそらく私の場合、これがKVM内で発生するという事実に関してです）。これについては 以下の説明 で説明しています。私の特定のケース（Debian Squeeze）では、解決策は次のとおりです。

  • スクリプト/ usr/share/initramfs-tools/scripts/local-top/lvm2をバックアップします
  • 上記のバグレポートからパッチを適用する
  • update-initramfs -uを実行します。

これは私を助けました、それが他の人を助けることを願っています（奇妙なことに、これはまだ主流の一部ではありません）。

パッチへのリンク：_http：//bugs.debian.org/cgi-bin/bugreport.cgi？msg = 10; filename = lvm2_wait-lvm.patch; att = 1; bug = 568838

以下は後世のコピーです。

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

以下を含むスタートアップスクリプトを/etc/init.d/lvmに作成します。

#!/bin/sh

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

exit 0

次に、コマンドを実行します。

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

Debianシステムのためのトリックを行う必要があります。

5
Le dude

私もこの問題を抱えていました。結局これはそれを修正するように思われたものです：

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"

私が試した他のこと：

  1. パッチ
  2. 差分/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

私は他の変更を取り消して、やり直しました。これは私にとって重要な唯一の変更ですが、おそらく最もエレガントではありません。

1
isaaclw

vgscanがボリュームを「見つけた」場合、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

再起動後に何が原因で非アクティブになるのかはわかりません。

0
Alex

実際の回答を提供するために必要な構成の詳細やエラーメッセージがなければ、grub-mkdevicemapソリューションとして。

0
BMDan

この問題に遭遇し、use_lvmetad=0を/etc/lvm/lvm.confに設定してlvmetadを無効にすると、ボリュームが強制的に検出され、起動時にアクセスできることがわかりました。

0
eMBee

システムがinitramfsを使用していると仮定すると、おそらくそこに構成の問題があります。ブート時にgrubによって開始されたinitramfsイメージを更新する必要があります（Debianではupdate-initramfsを使用してこれを行いますが、他のディストリビューションについては知りません）。

また、initramfsをアンパックし、initramfsイメージの/etc/lvm/lvm.conf（またはそれに似たもの）を変更して、手動で再パックすることもできます。

0
Jasper

Red Hat 7.4を実行している環境でKVMゲストとして同じ問題を抱えています。qemu-kvm-1.5.3-141およびvirt-manager 1.4.1を実行しています。最初は問題なくゲストとしてRed Hat 7.2を実行していましたが、マイナーリリースを7.2から7.4にアップグレードし、カーネルを最新バージョン3.10.0-693.5.2にアップグレードした後、問題が発生し、/ var LVパーティションを起動できなくなりました。システムはrootパスワードを要求する緊急モードに移行しました。rootパスワードを入力してコマンドlvm vgchange -ayおよびsystemctl defaultを実行すると、/var LVをアクティブにしてシステムを起動できました。

この問題の原因はわかりませんが、私の回避策は、以下のように/varにLV /etc/default/grubを含めることでした。

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"

次に、grub2-mkconfig -o /boot/grub2/grub.cfgを実行し、rd.lvm.lv=vg_local/varが/boot/grub2/grub.cfgのvmlinuz行に含まれているかどうかを確認する必要がありました。システムを再起動した後、/var LVをアクティブにするためのエラーが表示されなくなり、システムは起動プロセスを正常に完了しました。

0
Ricardo Sena

私の場合、GRUBルートがroot =/dev/vgname/rootであることがわかりました

したがって、/ 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

常に偽りでした。ルートボリュームはアクティブ化されません。

/ etc/fstabを更新

/dev/vgname/root        /

に

/dev/mapper/vgname-root   /

そしてしました：

update-grub
grub-install /dev/sda

私の問題を解決しました

0
exeral