CentOS を再起動すると、LVM ボリュームは無効になります。

CentOS を再起動すると、LVM ボリュームは無効になります。

CentOS 6から7にLinuxサーバーを再インストールしました。サーバーには3台のドライブ、つまりシステムSSDドライブ(ホストしているドライブを除くすべてをホストします/home)と2台の4TB HDDドライブがあります/home。すべてはLVMを使用します。 2つの4TBドライブがミラー化され(LVM自体のRAIDオプションを使用)、/homeパーティションで完全に埋められました。

問題は、4 TBディスクがよく認識され、LVMでもボリュームが認識されているため、自動的にアクティブにならないことです。他のすべては自動的に有効になります。手動で有効にすると機能します。

/homeに古いシステムドライブのイメージがあります。 LVMボリュームも含まれます。マウントすると、kpartxLVMはそれを選択して有効にします。ただし、これらのボリュームと非アクティブボリュームの間には違いはありません。

ルートファイルシステムもLVMであり、正常に有効になります。

ところで、奇妙な点を発見しました。 Executionは、アクティブlvchange -aayにするドライブを指定する必要があると述べました。この操作も自動的には行われません。私が指定した場合はlvchange -ay lv_home動作します。

この動作を引き起こす可能性がある項目が見つかりません。

次に追加:vgchange -aay --sysinit以前のシステムの起動スクリプト(initを使用)でこれを発見しました。 systemd を初めて使用する場合は、vgchangeスクリプトでその呼び出しを表示できません。しかし、どこに置くべきかわかりません。

2を追加します。systemdを見つけ始めます。私はスクリプトがどこにあるのかを発見し、スクリプトがどのように呼び出されるかを理解し始めました。また、実行されたスクリプトを見ることができることがわかりましたsystemctl -al。これは、起動時に既知のすべてのudevブロックデバイスを呼び出すことlvmetadを意味します。pvscanただし、現在登録されているudevブロックデバイスは、認識されているlvmボリュームの1つだけです。ハードドライブもありますが、パスが異なり、名前が長くなります。ブロックデバイスも同様と認識され8:3、ハードドライブも同様と認識されます/device/something/。私はもうサーバーにいないので正確に書くことはできません(後で修正します)。

私はこれがudevとデバイスの検出/マッピングに関連していると思います。夕方に続けてudevを学びましょう。

他のすべての方法が失敗した場合は、呼び出されたスクリプトを見つけて、pvscan常にすべてのデバイスをスキャンするように変更できることを確認しました。これで問題は解決しましたが、かなり見苦しいハッキングのように見えるので、実際の根本原因を把握するよう努力します。

3個追加:まあ、まだわかりません。なぜこれは起こりますが、少なくとも私はかなりまともな解決策を作りました。pvscan起動直後に一度呼び出される別のシステムサービスを作成しましたlvmetad。特定のデバイスへの別の呼び出しがまだ存在します。私の考えには実際にudev呼び出しているようです(このデバイスを参照した唯一の場所はここです)。なぜ他のハードドライブを呼び出さないのかわかりません。

答え1

私がやった!私がやった!正しく修正しました(私の考えでは)。

物語は次のとおりです。

しばらくすると、サーバーが故障して廃棄する必要がありました。私はディスクを保管し、他の新しいものを手に入れました。その後、SSDにCentOSを再インストールし、HDDを接続しました。 LVM が正常に実行され、ディスクが認識され、構成が変更されていないままです。しかし、同じ問題再発生します。再起動後、ボリュームは無効になります。

しかし、今回は偶然別の点を見つけました。ブートローダは、次のパラメータをカーネルに渡します。

衝突カーネル=自動rd.lvm.lv=centos/root rd.lvm.lv=centos/exchange静かな

さて、ちょっと待って、その表情はおなじみ

クイックGoogleクエリと私たちはそこにいる:

rd.lvm.lv=

指定された名前の論理ボリュームのみをアクティブにします。 rd.lvm.lvはカーネルコマンドラインで複数回指定できます。

今は大丈夫です。それが説明です!

したがって、解決策は次のとおりです(より多くのGoogleクエリから収集)。

  1. /etc/defaults/grubパラメータに追加のボリュームを含めるように変更します。crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swaprd.lvm.lv=vg_home/lv_homerhgb quiet
  2. グラップの再構成grub2-mkconfig -o /boot/grub2/grub.cfg
  3. initramfsの再構成を使用してくださいmkinitrd -f -v /boot/initramfs-3.10.0-327.18.2.el7.x86_64.img 3.10.0-327.18.2.el7.x86_64メモ:あなたの価値は異なる場合があります。uname -rカーネルバージョンを取得するために使用されます。または単に読んでくださいmkinitrd。 (正直なところ、このステップがなぜ必要なのかわかりませんが、はっきりしています。せずに試しましたが、うまくいきませんでした。)
  4. 最後に grub を再インストールしてください。grub2-install /dev/sda
  5. 自然に再起動してください。

ダダイズム!再起動時にボリュームがアクティブになります。それを追加しfstabてお楽しみください! :)

答え2

私にもこの問題がある。私の場合は、iscsi、マルチパス、lvm、セッション作成の順序などの組み合わせでした。/sbin/vgchange -a yペアを追加しました/etc/rc.local

答え3

マイナーアップデート(EFIのRHEL 7用)(非BIOS)機械):

次の手順を実行して成功しました。

  1. /etc/defaults/grubパラメータに追加のボリュームを含めるように変更されました。 (およびrd.lvm.lv=rhel/homeに加えて)rhel/rootrhel/swap
  2. グラップの再構成

    grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
    

    メモ:別の方法! )

  3. initramfsの再構成

    mkinitrd -f -v /boot/initramfs-$(uname -r).img $(uname -r)
    
  4. 飛び越えるgrubを再インストールしてください。 (grub2-install /dev/sda空のディレクトリがあるので/usr/lib/grub/
  5. 自然に再起動してください。

答え4

だから/etc/default/grubでrd.lvm.lv=設定しようとしましたが、うまくいきませんでした。

起動時に有効にするには、ssd_vgボリュームグループの両方の論理ボリュームが必要です。 kubuntu-vgの論理ボリュームhome_lvが有効になっています。

これは/etc/lvm/lvm.confを編集し、ボリュームリストセクションにVolume_list = ["ssd_vg"、"kubuntu-vg/home_lv"]を入力することでした。

再起動後の結果

$ sudo lvscan 非アクティブソース '/dev/kubuntu-vg/root' [50.00 GiB] 継承

inactive          '/dev/kubuntu-vg/swap_1' [7.88 GiB] inherit

ACTIVE            '/dev/kubuntu-vg/home_lv' [1000.00 GiB] inherit

inactive Snapshot '/dev/kubuntu-vg/root_snap11' [50.00 GiB] inherit

inactive Snapshot '/dev/kubuntu-vg/root_snap12' [50.00 GiB] inherit

ACTIVE            '/dev/ssd_vg/root' [224.02 GiB] inherit

ACTIVE            '/dev/ssd_vg/swap_1' [7.88 GiB] inherit

関連情報