☰

mdadm raid6の6つのドライブはすべて正常に動作しますが、システムの更新中にselinuxがアクセスをブロックした後に失敗としてマークされます。

tag-icon • tag-icon linux raid selinux mdadm
mdadm raid6の6つのドライブはすべて正常に動作しますが、システムの更新中にselinuxがアクセスをブロックした後に失敗としてマークされます。

したがって、システムログによると、最近私のシステムでdnfを更新している間、selinuxはある時点で突然カーネルへの書き込みアクセスを無効にし、RAIDドライブを「失敗」としてマークしました。

fstabから問題のあるraidドライブを削除してシステムを再実行しました。 （新しいカーネルがあったので再起動しましたが、raidドライブが突然動作を停止したことを知りませんでした。）

だから、すべてが大丈夫だったが、RAIDドライブが「起動」されていないので

for x in a b c d e f; do 
    mdadm --examine /dev/sd${x}1 > mdstats.$x; 
    done

次に、mdstats.xファイルで各raid要素の状態を確認します。すべてのデバイスが「クリーン」とマークされ、すべてがまったく同じ数の「イベント」を持つため、これは実際には良いニュースです。

コマンドラインでRAIDデバイスの状態を表示するには、次の手順を実行しました。

% cat /proc/mdstat
Personalities : 
md127 : inactive sdf1[3] sde1[0] sda1[6] sdb1[5] sdd1[1] sdc1[4]
      17581198678 blocks super 1.2
       
unused devices: <none>

何かが足りない場合に備えて、mdadm --examine出力をすべて含めます。しかし、すべて似ているようです。

  % mdadm --examine /dev/sda1
/dev/sda1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : e90d6691:7ad14e07:68ee7f2a:f5bbcfbc
           Name : LostCreek:0
  Creation Time : Wed Mar 25 11:56:03 2020
     Raid Level : raid6
   Raid Devices : 6

 Avail Dev Size : 5860399104 sectors (2.73 TiB 3.00 TB)
     Array Size : 11720531968 KiB (10.92 TiB 12.00 TB)
  Used Dev Size : 5860265984 sectors (2.73 TiB 3.00 TB)
    Data Offset : 131072 sectors
   Super Offset : 8 sectors
   Unused Space : before=130992 sectors, after=133120 sectors
          State : clean
    Device UUID : 100e1983:e323daa4:a28faf75:68afde64

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Aug  5 03:45:48 2022
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : f6f4c925 - correct
         Events : 128119

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)

そして比較してみてください：

   % mdadm --examine /dev/sdf1
/dev/sdf1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : e90d6691:7ad14e07:68ee7f2a:f5bbcfbc
           Name : LostCreek:0
  Creation Time : Wed Mar 25 11:56:03 2020
     Raid Level : raid6
   Raid Devices : 6

 Avail Dev Size : 5860400015 sectors (2.73 TiB 3.00 TB)
     Array Size : 11720531968 KiB (10.92 TiB 12.00 TB)
  Used Dev Size : 5860265984 sectors (2.73 TiB 3.00 TB)
    Data Offset : 131072 sectors
   Super Offset : 8 sectors
   Unused Space : before=130992 sectors, after=134031 sectors
          State : clean
    Device UUID : 8a99c085:51469860:99f42094:5dea9904

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Aug  5 03:45:48 2022
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 73871a85 - correct
         Events : 128119

         Layout: left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)

6つのデバイスすべての間の唯一の他のラインは次のとおりです。

 1. /dev/sda1 
 11. Avail Dev Size
 16. Unused Space
 18. Device UUID : 100e1983:e323daa4:a28faf75:68afde64
 23. Checksum : f6f4c925 - correct
 29. Device Role : Active device 3

先行番号は、この記事の上部にあるforループを使用して生成されたファイルの行番号です。

   vimdiff mdstat.?

「更新時間」、「イベント」などがすべて一致します。デバイスロールの行（別の最後の項目）は、0から5まですべて異なります。

これはすべてうまくいくようですが、多くのインターネット検索を実行した後に再び機能を実行するには、次のコマンドを使用する必要があると思います。

mdadm --create /dev/md127 --level=6 --raid-devices=6 --chunk=512 --name=LostCreek:0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 --assume-clean

この部分は、次の質問/回答からのものです。MDADM - 災害復旧または続行..そしてmdadm はディスクをスペアディスクとして追加します。。

私はこれを試してみましたが、私が逃したものがあることを確認したかったです。また、実際に失敗したドライブがない同様の問題を見たことはありませんが、ソフトウェアアタックで書き込みを停止してselinuxを「保存する」ことを許可します。 （私のselinuxは「許可」状態にあり、安全だと思いましたが、今は「無効」状態です）。

これが他の人に役立つことを願っています。特にそれが「働く」ならば、さらにそうです。これらの問題は珍しいように見え、自分の質問に答えたいのですが、実際には1ヶ月のバックアップからアタック全体を復元したくありません。 （はい、いつものように、より頻繁にバックアップする必要がありますが、幸いバックアップを失っても世界が終わるわけではありません。）

乾杯

マイク

答え1

ああ！ 、私の言葉はうふ！

帰ってきた！そしてフロストチュッツ、いつかビールや夕食を買うことができたら喜んでそうします！

状況がどのように進行したか上記のコメントをご覧ください。しかし、Frostshutzの答えとmdadm --examineから得たものを使って、次のことを行い、今戻ってきました！

--sizeを追加し、mdadm --examine出力の「Role」行に指定された順序でデバイスを配置するコマンドは次のとおりです。

mdadm --stop /dev/md127

mdadm --create /dev/md42 --assume-clean \
    --level=6 --chunk=512K --metadata=1.2 --data-offset=131072s \
    --size=2930132992K \
    --raid-devices=6 /dev/sde1 /dev/sdd1 /dev/sdf1 /dev/sda1 /dev/sdb1 /dev/sdc1

エラーメッセージを含むraidはmd127にあります。 /dev/md42 がこのすべてのスピン以前に私が持っていたraidデバイスであってほしいです。 RAIDデバイスは暗号化されたディスクであり、フォーマットされています。私はmdadm --examineビット（同じforループを使用）を見て、以前に持っていたものと比較しましたが、金または金のようです。これで、「役割」、サイズなどが一致します。明らかに「イベント」はありませんが、予想していたように良く見えます。もしそうなら、決定的な瞬間は

cryptsetup luksOpen /dev/md42 woot

見て、私は/dev/mapper/wootデバイスを持っています。それは上がり、世界のすべてが順調に進んだ。

とても感謝しています。そうでなければ、このポイントに到達することは不可能です。 Frostschutzはこれを行う方法を非常に明確に説明しています。。本当に楽しい！新しいバックアップを始めましょう。

関連情報