web-dev-qa-db-ja.com

CentOSの再起動後、LVMボリュームが非アクティブになる

LinuxサーバーをCentOS 6から7に再インストールしました。サーバーには3つのドライブがあります。システムSSDドライブ（/home以外のすべてをホストします）と2つの4TB HDDドライブがホスト/homeです。すべてLVMを使用しています。 2つの4TBドライブはミラーリングされ（LVM自体のraidオプションを使用）、/ homeパーティションで完全に満たされます。

問題は、4TBのディスクは問題なく認識され、LVMは問題なくボリュームを認識しますが、ボリュームを自動的にアクティブ化しないことです。それ以外はすべて自動的にアクティブになります。手動でアクティブ化できます。

/ homeに古いシステムドライブのイメージがあります。これにはLVMボリュームも含まれます。 kpartxでマウントすると、LVMがそれらを取得してアクティブ化します。しかし、これらのボリュームと非アクティブなボリュームの間に違いはありません。

ルートファイルシステムもLVMであり、これは問題なく起動します。

ただし、特異なことがわかります。lvchange -aayを実行すると、アクティブにするドライブを指定する必要があることがわかります。自動的には行われません。 lvchange -ay lv_homeを指定した場合-機能します。

この行動の原因となる可能性のあるものは何も見つかりません。

追加：古いシステム（initを使用していた）の起動スクリプトにvgchange -aay --sysinitがあることに気付きました。新しいものはsystemdを使用しており、スクリプトにvgchange呼び出しがありません。しかし、どこに置くべきかもわかりません。

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

私はそれがudevとデバイスの検出/マッピングに関係していると思います。私は夕方に続き、そのときudevを勉強します。

他のすべてが失敗した場合、pvscanを呼び出すスクリプトを見つけ、それを変更して常にすべてのデバイスをスキャンできることを確認しました。これで問題は解決しましたが、見苦しいハックのように見えるので、本当の根本原因を解明しようと思います。

追加：OK、まだわかりませんなぜこれが発生するのかはわかりますが、少なくともかなり妥当なものにしています回避策。 pvscanを起動した直後に、lvmetadを1回呼び出す別のsystemdサービスを作成しました。特定のデバイスに対するもう1つの呼び出しはまだ存在しており、実際にそれを呼び出すのはudevだと思います（それが私がそれへの参照を見つけた唯一の場所です）。なぜそれが他のハードドライブのためにそれを呼び出さないのですか-私にはわかりません。

centosrhellvm
8
Vilx-

やったよ！やったよ！私はそれを適切に修正しました（私は思う）。

ストーリーは次のとおりです。

しばらくすると、サーバーに障害が発生し、廃棄する必要がありました。私はディスクを保持し、他のすべてを新しいものにしました。次に、CentOSをSSDに再インストールし、HDDを接続しました。 LVMはうまく機能し、ディスクは認識され、構成は保持されました。しかし、同じ問題が再び現れました-再起動後、ボリュームは非アクティブでした。

ただし、今回は別のことに気づきました。ブートローダーは次のパラメーターをカーネルに渡します。

crashkernel = autord.lvm.lv = centos/root rd.lvm.lv = centos/swaprhgb quiet

うーん、ちょっと待ってください、それらは[〜＃〜]おなじみ[〜＃〜]に見えます！

クイック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でGRUBを再構成します
  3. mkinitrd -f -v /boot/initramfs-3.10.0-327.18.2.el7.x86_64.img 3.10.0-327.18.2.el7.x86_64を使用してinitramfsを再構成します。 注：値は異なる場合があります。カーネルバージョンを取得するには、uname -rを使用します。または、mkinitrdを読んでください。 （率直に言って、なぜこの手順が必要なのかはわかりませんが、どうやらそうなのです-私はそれなしで試してみましたが、うまくいきませんでした）
  4. そして最後に、grubを再インストールします：grub2-install /dev/sda
  5. 自然に再起動します。

たーだ！ボリュームは再起動時にアクティブになります。 fstabに追加してお楽しみください。 :)

7
Vilx-

マイナーアップデート（EFI（非BIOS）マシン上のRHEL 7の場合）：

私はこれらのステップを使用して成功する必要があります：

  1. 変更/etc/defaults/grubパラメータに追加のボリュームを含める：rd.lvm.lv=rhel/home （に加えて rhel/rootおよびrhel/swap）

  2. でGRUBを再構成する

    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. 自然に再起動します。
2
jno

私にもこの問題がありました。私の場合、それはiscsi、マルチパス、lvmの組み合わせであり、セッション作成の順序付けなどでした。/sbin/vgchange -a yへの呼び出しを/etc/rc.localに追加することで問題を解決しました。

1
Tom Schuneman

だから私は/ 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 inactive Original '/ dev/kubuntu-vg/root' [50.00 GiB] inherit

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
0
ttguy

私の場合、/ etc/lvm/lvm.confのこの行にコメントを付けました

auto_activation_volume_list = [ "vg00", "vg01" ]

なぜなら、アクティブな場合、ボリュームvg00とvg01のみがブート時にアクティブだからです。

Lvm.confのドキュメント：

If auto_activation_volume_list is defined, each LV that is to be
activated with the autoactivation option (--activate ay/-a ay) is
first checked against the list. There are two scenarios in which
the autoactivation option is used:

  - automatic activation of volumes based on incoming PVs. If all the
    PVs making up a VG are present in the system, the autoactivation
    is triggered. This requires lvmetad (global/use_lvmetad=1) and udev
    to be running. In this case, "pvscan --cache -aay" is called
    automatically without any user intervention while processing
    udev events. Please, make sure you define auto_activation_volume_list
    properly so only the volumes you want and expect are autoactivated.

  - direct activation on command line with the autoactivation option.
    In this case, the user calls "vgchange --activate ay/-a ay" or
    "lvchange --activate ay/-a ay" directly.

By default, the auto_activation_volume_list is not defined and all
volumes will be activated either automatically or by using --activate ay/-a ay.

N.B. The "activation/volume_list" is still honoured in all cases so even
if the VG/LV passes the auto_activation_volume_list, it still needs to
pass the volume_list for it to be activated in the end.

If auto_activation_volume_list is defined but empty, no volumes will be
activated automatically and --activate ay/-a ay will do nothing.

auto_activation_volume_list = []

If auto_activation_volume_list is defined and it's not empty, only matching
volumes will be activated either automatically or by using --activate ay/-a ay.

  "vgname" and "vgname/lvname" are matched exactly.
  "@tag" matches any tag set in the LV or VG.
  "@*" matches if any tag defined on the Host is also set in the LV or VG


Only activate vg00 and vg01 automatically.
auto_activation_volume_list = [ "vg00", "vg01" ]
0
inadget