見出しを読んでくれてありがとう。 それはテストでした。
今日、お気に入りのGentooサーバーでの次の更新と予防的な再起動の後、賢明なカーネルの言葉で突然/ dev / md1から落ちました：sdc1には有効なv0.90スーパーブロックがなく、インポートされていません！
ショック！ パニック！ まあ、それはコアではありません...
実際、問題は何ですか？
まず、問題の本質とその解決方法を理解しやすくするためのサーバー構成について説明します。 そのため、RAID自動検出を有効にしたカーネル3.10.7と2つのRAID1（ミラー）ドライブ。
ルートは、/ dev / md1データベース（Percona）の/ dev / md0にマウントされます。
db13 ~ # cat /etc/fstab | grep md /dev/md0 / ext3 noatime 0 1 /dev/md1 /mnt/db reiser4 noatime 0 0
そして、/ boot / grub / grub.confの一部：
title Gentoo Linux 3.10.7 md0 root (hd0,0) kernel /boot/kernel-3.10.7 root=/dev/md0
したがって、ブート中にカーネルがmdデバイスを正常にアセンブリするには、次の2つの条件を満たしている必要があります。
- RAIDが構築されているパーティションには0xFDと入力します
- mdadmを使用して作成されたデバイス/ dev / mdのスーパーブロックフォーマットバージョン0.90
条項1の場合 私の構成ではすべてが順調でしたが、判明したように、スーパーブロック形式は1.2でした。新しいバージョンのmdadmが到着した後、/ dev / md1を作成したと思われます。 その結果、コアはひどい言葉で誓います：
dmesg | grep md
[0.000000]コマンドライン：root = / dev / md0 raid = / dev / md0 [0.000000]カーネルコマンドライン：ルート= / dev / md0 raid = / dev / md0 [1.063603] md：レベル1に登録されたraid1パーソナリティ [1.266420] md：すべてのデバイスが利用可能になるのを待ってから自動検出する [1.266494] md：raidを使用しない場合は、raid = noautodetectを使用します [1.266781] md：RAIDアレイの自動検出。 [1.293670] md：sdc1の無効なraidスーパーブロックマジック
[1.294210] md：sdc1には有効なv0.90スーパーブロックがなく、インポートされていません！ [1.312482] md：sdd1の無効なraidスーパーブロックマジック [1.312556] md：sdd1には有効なv0.90スーパーブロックがなく、インポートされていません！
[1.312579] md：4つのデバイスをスキャンし、2つのデバイスを追加しました。 [1.312595] md：自動実行... [1.312610] md：sdb3の検討... [1.312626] md：sdb3を追加しています... [1.312641] md：sda3を追加しています... [1.312657] md：md0を作成しました [1.312665] md：バインド<sda3> [1.312754] md：バインド<sdb3> [1.312770] md：実行中：<sdb3> <sda3> [1.313064] md / raid1：md0：2つのミラーのうち2つでアクティブ [1.313166] md0：0から7984840704への容量変化を検出 [1.313262] md：...自動実行が完了しました。 [1.320413] md0：不明なパーティションテーブル [1.338528] EXT3-fs（md0）：順序付けられたデータモードでマウントされたファイルシステム [2.581420] systemd-udevd [861]：バージョン208以降 [3.122748] md：バインド<sdc1> [4.896331] EXT3-fs（md0）：内部ジャーナルを使用
Googleが役に立たないとき
選択肢は非常に少なく、カーネル内の配列の自動検出を無効にするか（grub.confでの再コンパイルと編集）、スーパーブロックの形式を変更します（フルデータバックアップとその後の復元によるミラーキリング）。 どちらのオプションも本質的に破壊的であり、データの損失につながる可能性があるため、「オプションではありません」。多くの時間がかかる場合があります（ソリューションの検索中に判明したため、 カーネルの自動検出は機能が低下しています ）
ところで、sevreraの開始後、/ dev / md1は次のコマンドで正常に開始します。
mdadm --manage / dev / md1 --run。 もちろん、この行をrcスクリプトのどこかに書くことは可能ですが、ご存知のように、これはスポーツではありません。
ユーレカ！
解決策は表面にありましたが、すぐには出ませんでした-必要なのは、/ dev / md1のディスクから0xFDタイプ（0x83に置き換える）を削除することだけです。そうすると、カーネルはこの配列の収集を成功せずに試行し、udevdがその作業を実行できなくなります。 実際、fdiskを使用して両方のミラーのパーティションのタイプを変更し、サーバーを再起動すると、すべてが奇跡的に起動しました。
dmesg | grep md
[0.000000]コマンドライン：root = / dev / md0 raid = / dev / md0 [0.000000]カーネルコマンドライン：ルート= / dev / md0 raid = / dev / md0 [1.063924] md：レベル1に登録されたraid1パーソナリティ [1.248078] md：すべてのデバイスが利用可能になるのを待ってから自動検出する [1.248201] md：raidを使用しない場合は、raid = noautodetectを使用します [1.248504] md：RAIDアレイの自動検出。 [1.265058] md：2つのデバイスをスキャンし、2つのデバイスを追加しました。 [1.265243] md：自動実行... [1.265258] md：sda3の検討... [1.265274] md：sda3を追加しています... [1.265290] md：sdb3の追加... [1.265305] md：md0を作成しました [1.265321] md：バインド<sdb3> [1.265331] md：バインド<sda3> [1.265428] md：実行中：<sda3> <sdb3> [1.265865] md / raid1：md0：2つのミラーのうち2つでアクティブ [1.265891] md0：容量の変化が0から7984840704に検出されました [1.266068] md：...自動実行が完了しました。 [1.276627] md0：不明なパーティションテーブル [1.294892] EXT3-fs（md0）：順序付けられたデータモードでマウントされたファイルシステム
[2.713383] systemd-udevd [860]：バージョン208以降 [3.128295] md：バインド<sdc1> [3.159107] md：バインド<sdd1> [3.170320] md / raid1：md1：2つのミラーのうち2つでアクティブ [3.170333] md1：容量の変更が0から17170300928に検出されました [3.178113] md1：不明なパーティションテーブル [4.911712] EXT3-fs（md0）：内部ジャーナルを使用 [5.027077] reiser4：md1：ディスクフォーマット4.0.0が見つかりました。
このテキストを見つけたGoogleが、同様の状況に陥ったワークショップの同僚にそれを見せてくれたら嬉しいです。