☰

mdadmルートパーティションraid 1が断続的に失敗する

tag-icon • tag-icon linux mdadm software-raid
mdadmルートパーティションraid 1が断続的に失敗する

しばらくの間、ディスク障害が発生した場合のダウンタイムを最小限に抑えるために、ソフトウェアRAID 1ルートとブートパーティションですべてのサーバーを設定してきました。インストール中に設定しました。

mdadm --create /dev/md0 --metadata 1.0 --raid-devices=2 --level=1 /dev/sd[ab]1
mdadm --create /dev/md1 --raid-devices=2 --level=1 /dev/sd[ab]2
mkfs.fat -F32 /dev/md0
mkfs.ext4 /dev/md1

次に、fstabでそれぞれ/bootと/に設定します。もちろん、EFIはソフトウェアRAID 1パーティションを読み取ることができないため、EFIブートデバイスは/ dev / sda1と/ dev / sdb1です。個別に。 initramfsはmdadmを認識するように設定されているため、/はすぐに/ dev / md1 raidパーティションにマウントされ、/ dev / md0は起動後にミラーリング、メンテナンス、および/dev/sda1同期されます/dev/sdb1。私は長年このようにシステムをセットアップしてきましたが、何の問題もありませんでした。

最近まで、私は26個のHBAディスクでバックアップサーバーを構成しました。 /dev/sdyは、および/dev/sdzに使用するSSDディスクです。ほとんどの場合、システムは正常に起動します。ただし、再起動するとシステムが断続的にクラッシュし、「スーパーブロックが破損しています」 「問題を解決するためにe2fsck -b 8198などを実行しようとしています。」しかし、/ dev / md1のスーパーブロックには問題はありません。 USBメモリからダウンロードできます。スティックが起動してインストールされます。問題はなく、デバイスにエラーが返されません。多数のディスクでこの問題を引き起こす原因がわからない（間欠的なハードウェアの問題または不安定なファームウェアを除く）。 RAIDが組み立てられた方法の組み合わせ（つまり、RAIDスーパーブロックを見つけるためにパーティションをスキャンします）しかし、ディレクティブが/ etc / mdadm.confにあり、それまでは読み取れないことに気づくでしょう。 /がすでにマウントされていましたが、そもそも問題でした。//boot/dev/md1dev/md1e2fsckmdadm

もしこの問題を見た方や解決策をご存知の方ですか？

ベストアンサー1

使っていますシステム起動私のUEFIブートマネージャ（https://wiki.archlinux.org/index.php/Systemd-boot）、systemd-bootでは、以下を提供する必要があります。ローダー構成項目起動するカーネル/initramfsファイルと、カーネル起動パラメータとして渡されたオプションに関する情報を提供します。次のいずれかのオプションはルートデバイスを指定します。

# cat /boot/loader/entries/arch.conf
title   Arch Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=UUID=acf7e0be-5723-478e-aad6-80af6eb82a92 rw ipv6.disable=1

最初はいつものようにルートデバイスを設定しましたが、root=/dev/md1システムに26個のHBAディスクが含まれていて、システムがディスクデバイスの命名と混同しているようです。とにかく root=UUID=acf7e0be-5723-478e-aad6-80af6eb82a92上記のようにルートを変更すると問題が解決し、システムは毎回正しく起動します。

おすすめ記事