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

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

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

よろしく、

マレク

編集：さらなる調査により、これは論理ボリュームのサイズ変更とは何の関係もないことが明らかになりました。ブートが失敗した後、論理ボリュームをashシェルで手動でアクティブ化する必要があったという事実と、この問題の考えられる解決策については、以下の返信で説明します。

だから私はこれを最終的に解決することができました。論理ボリュームの検出に問題（バグ）があります。これは、ある種の競合状態です（おそらく私の場合、これが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
 }

/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システムのためのトリックを行う必要があります。

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

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

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

場合は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

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

実際の答えを出すために必要な構成の詳細やエラーメッセージがなければgrub-mkdevicemap、解決策として暗闇の中で試してみましょう。

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

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

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、/varLV をアクティブにしてシステムを起動できました。

私は、この問題の原因を考え出したていないが、私の問題を回避するには、LVを含めるようにした/var中で/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て、がのvmlinuz行に含まれているかどうかを確認する必要がありました/boot/grub2/grub.cfg。システムを再起動した後、/varLV をアクティブ化するためのエラーが表示されなくなり、システムは起動プロセスを正常に完了しました。

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

これでテストを/ usr / share / initramfs-toolsで/スクリプト/ローカル・トップ/ 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

私の問題を解決しました

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