コンテキスト:ルートボリュームのRAID1を含むLVM設定を使用してArch Linuxをインストールしようとしたときに説明した問題が発生しました。Arch Linuxフォーラムで。この問題に対する解決策が見つかりませんでしたが、スワップファイル(スワップパーティションを作成)を除いて、システム全体を最初から再インストールした後に消えて忘れました。
システムの一時停止中に誤ってシステムの電源を切った後(上記の「最初からシステムを再インストール」して数ヶ月使用)、システムを再起動しましたが、同じエラーが再び発生しました。
問題は上記のリンクで詳しく説明されています。 Stack Exchangeを独自に改善した知識ベースにするための努力の一環として、ここに投稿の内容を含めます。
LVMを使用してArch Linuxをインストールしています。これはArchを3番目または4番目にインストールすることですが、LVMを初めて試すことです。私のディスクレイアウトは次のとおりです。
物理記憶媒体には、/dev/sda(SSD、約100GB容量)と/dev/sdb(HDD、約1TB容量)があります。
LVMを使用して、以下を含むボリュームグループVolumegroup0を作成しました。
- raid1を使用してSSDとHDD間でシステムボリュームをミラーリングし、SSD容量(volumegroup0 / systemvolume_raid1)の大部分を占め、ext4ファイルシステム(16GBスワップファイルを含む)を使用します。
- btrfs ファイルシステムを使用する SSD のブートボリューム ~500MB(volumegroup0/boot)
- HDDのメインボリューム、高速アクセスのためのSSDの10GBキャッシュプール(volumegroup0 / home)、btrfsファイルシステム
- HDDのvarボリューム(volumegroup0/var)、SSDの2GBキャッシュプール、基本ボリュームと同じ、ext4ファイルシステムを含む
- システムボリュームのバックアップに使用されるスナップショットボリュームは、Volumegroup0 / systemvolume_snapshotと呼ばれます。
今、昨夜システムが起動し、インストールが正常に完了したと思いました。しかし、今朝起動すると、システムはルートボリュームをマウントできず、緊急シェルに陥りました。
デフォルトのGRUBパラメータ(私はGRUBを使用しています)、「quiet」で起動して終了します。起動失敗後の画面は次のとおりです。
:: 初期フック実行 [udev] バージョン 242.29-2-arch 開始 :: 初期フック実行 [lmv2] :: フック実行 [udev] :: uevents トリガー...
このメッセージは、次の内容が表示されるまで約30秒間画面に残ります。
デバイス/dev/mapper/volumegroup0-systemvolume_raid1 10秒間待ちます...
そして10秒後:
エラー: '/dev/mappervolumegroup0-systemvolume_raid1'デバイスが見つかりません。 fsckをスキップします。 ::実際のルートマウントに '/dev/mappervolumegroup0-systemvolume_raid1' マウント: /new_root: 指定されたファイルシステムタイプがありません。これで緊急シェルに配置されました。 sh:ジョブ制御にアクセスできません。 [ルートファイルシステム]#
Archiso Live USBで起動し、問題の解決策を探していたときに奇妙なことがわかりました。始めるとすぐ
ls /dev/マッパー
または
ls /dev/volumegroup0
、出力には、systemvolume_raid1を除いて、私が期待しているすべての論理ボリュームが含まれています。 /dev/mapper に Volumegroup0-systemvolume_raid1_rimage0 と 1、Volumegroup0-systemvolume_raid1_rmeta0 と 1 が存在しても、ルートボリューム自体は存在しません。しかし、私が走ったら
スキャナー
(--mknodesを使用または使用せずにディレクトリの1つを再リストすると、systemvolume_raid1が存在し、問題がないかのように正確です。問題なくインストールできます。必要なモジュールを確認して再構築しようとしました。initramfsのフックmkinitcpio.confにあり(はい)、/ etc / fstabはスワップファイルなしで(genfstab -Uを使用して)再生成されます(/ etc / fstabが自動的に有効なスワップを含むように再生成されるため)。 1日)。
[[の内容は/etc/fstab
元のフォーラム投稿に含まれていますが、まったく同じではありません。正しいバージョンについては下記をご覧ください。]
修正する:
走れば
lvs-a
systemvolume_raid1が表示されない場合は、lvs -aの正しい出力を含むテーブルの上に次の出力の複数行が表示されます。
RAIDセグメントタイプを予想しましたが、結果はNULLでした。
メモ:
Arch WikiのLVM記事では、カーネルパラメータ"root"が"/dev/[italic]vg-name[/italic]/[italic]lv-name[/など"マッピングされたデバイスを指していることを確認する必要があることが示されています。 .イタリック体]」。私の場合、パラメータは/dev/mapper/volumegroup0-systemvolume_raid1を指していますが、それをWikiが推奨する形式に変更しても、起動時にエラーメッセージに表示されるデバイス名(予想どおり)以外は何も変わりません。 「根」)。
私はGRUBを使用しており、grub-mkconfigを介して設定を作成しています(該当する場合)。
私の問題は次のようなものです。UnixとLinux Stack Exchangeに関する一般的な質問です。。
以下は/etc/fstabの正しい内容です。上記のフォーラム投稿のバージョンとは異なります。:
#/dev/mapper/volumegroup0-systemvolume_raid1
UUID=... / ext4 rw,relatime 0 1
#/dev/mapper/volumegroup0-var
UUID=... /var ext4 rw,relatime,stripe=16 0 2
#/dev/mapper/volumegroup0-boot
UUID=... /boot btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0
#/dev/mapper/volumegroup0-home
UUID=... /home btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0
#/dev/mapper/volumegroup0-swap
UUID=... none swap defaults 0 0
問題は、システムが起動時にルートボリュームを「アクティブ化」できない、またはルートボリュームをまったく確認できないことに関連していると確信していますが、どのような方法なのかわかりません。
lvscan
関連事項は、ライブUSBから起動した後の出力が次のようになることです。
ACTIVE '/dev/volumegroup0/home' [500.00 GiB] inherit
ACTIVE '/dev/volumegroup0/var' [50.00 GiB] inherit
ACTIVE Original '/dev/volumegroup0/systemvolume_raid1' [83.50 GiB] inherit
inactive '/dev/volumegroup0/boot' [500.00 MiB] inherit
ACTIVE Snapshot '/dev/volumegroup0/systemvolume_snapshot' [40.00 GiB] inherit
inactive '/dev/volumegroup0/swap' [16.00 GiB] inherit
inactive Snapshot '/dev/volumegroup0/systemvolume_pre_dwarf' [3.00 GiB] inherit
pvscan
あるいは、同じコマンドを実行した後vgscan
(他のコマンドも同じ効果を持つ可能性がありますが、可能なすべてのLVMコマンドをテストしていないため、「たとえば」と言います)、上記のすべてのボリュームはこの仮説を裏付けるようですinactive
。active
起動時に何かが正しく有効になっていませんが、確かに言うことはできません。
システムが起動しないのはなぜですか?この問題をどのように解決できますか?
ベストアンサー1
raid 1を削除すると、この問題を解決できます。
lvconvert -m 0 lv /dev/to/remove
起動中にRAID 1ボリュームがアクティブにならない理由は不明です。起動後に有効にできます。問題ありません。ボリュームを手動でアクティブにするためにinitcpioカスタムフックを追加しようとしましたが、そのように問題を解決することはできませんでした。それはおそらく、フックが走っているかどうかわからないからです。