複数のLVM論理ボリュームを持つサーバー（Ubuntu 18.04）があります。日常的な再起動後、そのうちの1つは再び戻りません。いくつかの調査を終えた後、私は次の場所にいます。
物理ディスクはiSCSIデバイスであり、カーネルはそれを/ dev / sdcとして認識します（エラーがなくサイズが正確です）。
lvmdiskscan -vは/ dev / sdcでPVをチェックします。
> lvmdiskscan -v ... /dev/sdc [72.76TiB] LVM 物理ボリューム
- blkid は、LVM 構成でも見つけることができる UUID を返します。
... /dev/sdc: UUID="fvUXXf-pVOF-EPnn-c8eg-tZ5S-iMVW-wsSFDy" TYPE="LVM2_member"
このエントリには、システムの他のLVにあるPARTUUIDエントリはありません。これは手がかりですか？私はこの情報を私に役立つものに関連付けることはできません。
pvscanは/dev/sdcを報告しません。
pvdisplayがこのPVを知らないようです。
> PVディスプレイ /dev/sdc 物理ボリューム「/dev/sdc」が見つかりません。
誰もが正しい方向に私を指すことができますか？
Pvck -tの出力を追加するように編集されました。
pvck -t /dev/sdc テストモード：メタデータは更新されず、ボリュームは（非）アクティブになりません。 / dev / sdc、セクタ1、タイプ= LVM2 001でラベルが見つかりました。 テキストメタデータ領域を探す：オフセット=4096、サイズ=1044480
また、このLVはもともとUbuntu 14.04で作成され、Ubuntu 18.04で非常にうまく動作することも役立ちます。
以下は、lvmdiskscanの追加出力です。この出力はシステムの他のVG出力と変わりません。 LVは最初に隔離されているように見え、次にVGに接続して使用可能になります。しかし、r3vgではこれは起こりません。
lvm[7852]: /dev/sdc デバイスからタグを読み取る lvm[7852]: /dev/sdc RO O_DIRECT を開く lvm[7852]: /dev/sdc: ブロックサイズは 4096 バイトです。 lvm[7852]: /dev/sdc: 物理ブロックサイズは 512 バイトです。 lvm[7852]: /dev/sdc: セクタ 1 で lvm2 ラベルが検出されました。 lvm[7852]: lvmcache /dev/sdc: VG #orphans_lvm2(#orphans_lvm2) では、mda は 0 です。 lvm[7852]: /dev/sdc: PV ヘッダー拡張バージョン 2 が見つかりました lvm [7852]：/ dev / sdc：5632サイズ1015（地域4096サイズ1044480）でr3vg（Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00）のメタデータが見つかりました。 lvm [7852]：lvmcacheには、VGIDがRpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00のvgname "r3vg"に関する情報がありません。 lvm [7852]：lvmcacheにvgname "r3vg"に関する情報がありません。 lvm[7852]: lvmcache /dev/sdc: 1mda がある VG r3vg にあります。 lvm[7852]: lvmcache /dev/sdc: VG r3vg: VGID を Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00 に設定します。 lvm[7852]: lvmcache /dev/sdc: VG r3vg: ホスト生成を leitrim に設定します。 lvm[7852]: lvmcache /dev/sdc: VG r3vg: 保存されたメタデータチェックサム 0x54affad5, サイズ 1015。 lvm[7852]: /dev/sdc 閉じる lvm[7852]: /dev/sdc: キャッシュサイズ 156250918912 セクタの使用 lvm[7852]:/dev/sdc [72.76TiB] LVM 物理ボリューム lvm[7852]: ディスク 7 個 lvm[7852]: パーティション 3 個 lvm[7852]: 1 LVM 物理ボリュームフルディスク lvm[7852]: LVM 物理ボリューム 2 個 lvm[7852]: global/notify_dbus を 1 に設定 lvm[7852]: 完了: lvmdiskscan -dddddd
ベストアンサー1
sudo vgscanと作業を行ったら、LVをインストールできますかsudo vgchange -ay？これらのコマンドでエラーが発生した場合は他の問題が発生する可能性があるため、これらのエラーメッセージを元の投稿に追加する必要があります。
ただし、このコマンドの後にLVをインストールする準備ができたら、次の内容をお読みください。
LVM論理ボリュームパス名（たとえば/dev/mapper/vgNAME-lvNAME）だけでは、/etc/fstabネットワークとiSCSIが有効になるまでこの特定のファイルシステムをマウントできないという手がかりをシステムに提供しません。
このような手がかりがなければ、システムはファイルシステムがローカルディスクにあると仮定し、できるだけ早くマウントを試みます。通常、ネットワークを有効にする前にマウントを試みます。これは明らかにiSCSI LUNに失敗します。したがって、何とかその手がかりを提供する必要があります。
_netdev1つの方法は、ファイルシステムにマウントオプションを追加することです/etc/fstab。 ~からこのUbuntuのヘルプページUbuntuはそれをサポートしているようです。実際にvgscanラベルがついたものをマウントしようとするとき_netdev。
別のアプローチは、システム固有のマウントオプションを使用することですx-systemd.requires=<iSCSI initiator unit name>。 iSCSIイニシエータが正常にアクティブになるまでファイルシステムのマウント試行を延期すると、同じ効果が得られます。
iSCSIイニシエータが有効になると、設定されたすべてのLUNが自動的に有効になり、LVMは利用可能なすべてのVGを自動的に有効にする必要があります。したがって、マウント試行を延期すれば十分です。
欠落しているPARTUUIDは、ディスク/ LUNにGPTパーティションテーブルがないことを示します。実際にはパーティションテーブルがまったくないからです/dev/sdc。TYPE="LVM2_member"理論的にはLinuxでは問題は発生しませんが、iSCSIストレージを含むUbuntu 18.04システムを個人的にテストしていないため、完全にはわかりません。
パーティションテーブルがないディスク/ LUNの問題は、他のオペレーティングシステムがLinux LVMヘッダーをディスクが使用中であるという信号として認識しておらず、メッセージをほとんど表示せず上書きすることです。これは、iSCSI Storage Managerが誤ってそのストレージLUNを他のシステムに提供した場合に/dev/sdc発生する可能性があります。
欠落しているVGに対応するディレクトリでLVM構成バックアップファイルを見つけて/etc/lvm/backup読み取り、欠落しているPVの予想UUIDを見つける必要があります。レポートと一致する場合は、blkidストレージ管理者に上記のエラーに関する最近の操作を再確認するよう依頼してください。他のシステムがPVを上書きしたことが判明した場合は、LUNに残っているデータが多少破損している可能性があるため、バックアップから復元するのが最善です。新しいデータを取得した後、衝突なし保証iSCSIマネージャのLUN。
実際のUUIDが予想と異なると判明した場合、/dev/sdc誰かが誤ってpvcreate -f /dev/sdcUUIDを実行した可能性があります。それが完了した唯一のものであれば、比較的簡単に修正できます。 （メモ:man vgcfgrestore章を確認してください物理ボリュームの交換アップデートに関する注意事項 - あなたのLVMツールは私のツールよりも最新のものかもしれません。 ）まずUUIDを復元します。
pvcreate --restorefile /etc/lvm/backup/<your VG backup file> --uuid <the old UUID of /dev/sdc from the backup file> /dev/sdc
その後、VG設定を復元します。
vgcfgrestore --file /etc/lvm/backup/<your VG backup file> <name of the missing VG>
その後、VGを有効にして他の破損が発生しない場合は、ファイルシステムをマウントできる必要があります。