Debian の /boot/efi パーティション用 RAID 1

Debian の /boot/efi パーティション用 RAID 1

CentOSインストーラの自動パーティション化を使用して、パーティション化とRAID 1構成が完了したCentOS 8をインストールしました。出力は次のとおりですlsblk

sda         8:0    0 558.9G  0 disk
├─sda1      8:1    0    50G  0 part
│ └─md127   9:127  0    50G  0 raid1 /
├─sda2      8:2    0    20G  0 part
│ └─md126   9:126  0    20G  0 raid1 [SWAP]
├─sda3      8:3    0     1G  0 part
│ └─md125   9:125  0  1022M  0 raid1 /boot
├─sda4      8:4    0   600M  0 part
│ └─md124   9:124  0   600M  0 raid1 /boot/efi
└─sda5      8:5    0 487.3G  0 part
  └─md123   9:123  0 487.2G  0 raid1 /home
sdb         8:16   0 558.9G  0 disk
├─sdb1      8:17   0    50G  0 part
│ └─md127   9:127  0    50G  0 raid1 /
├─sdb2      8:18   0    20G  0 part
│ └─md126   9:126  0    20G  0 raid1 [SWAP]
├─sdb3      8:19   0     1G  0 part
│ └─md125   9:125  0  1022M  0 raid1 /boot
├─sdb4      8:20   0   600M  0 part
│ └─md124   9:124  0   600M  0 raid1 /boot/efi
└─sdb5      8:21   0 487.3G  0 part
  └─md123   9:123  0 487.2G  0 raid1 /home

ご覧のとおり、/boot/efiパーティションは他のパーティションと同様にRAID 1にミラーリングされています。 Debian のインストール時に同じ設定を再作成しようとしましたが、続行できません。このようにパーティション化とRAID 1を設定すると、grubのインストール中にインストーラに失敗メッセージが表示されます(他のエラーメッセージはなく、一般的な「一部のインストール手順に失敗しました」というメッセージのみが表示されます)。

スクリーンショット:

間違い

ESPパーティションをミラーリングしないと、エラーは消えます。

私はESPパーティションをミラーリングすることが実現可能ではないことを知っています。ただし、CentOSインストーラは何とかこれを行います。

Debian で同じ設定を再生成するにはどうすればよいですか?

答え1

@casのコメントのおかげで、うまく機能しました。

主なステップは次のとおりです。

  1. Debianをインストールしましたが、ESPパーティションのRAIDを設定していません。パーティショニングプロセス中に、ESPパーティションと呼ばれる2つの同じパーティションを作成しました。それぞれに位置してい/dev/sda1ます。/dev/sdb1
  2. /boot/efi他の場所からコンテンツをコピーしました(/boot/eficopy)。
  3. umount /boot/efi
  4. mdadm --create --verbose /dev/md3 --level=1 --raid-devices=2 --metadata=1.0 /dev/sda1 /dev/sdb1。もちろん、すでにアクティブなMDデバイスであれば、/dev/md3他のデバイスに変更してください。/dev/md3
  5. mkfs.vfat /dev/md3
  6. パーティションのUUIDを探す/dev/disk/by-uuid
  7. 新しいUUIDに/boot/efiアイテムを変更する/etc/fstab
  8. mount /boot/efi
  9. バックアップからデータを/boot/efi再コピーしてください。

再起動に成功しました。

編集する:バックアップパーティションの代わりに/boot/efi

grub-install --efi-directory=/boot/efi

内容を復元する操作(上記のステップ9)を実行しましたが、理解できない警告がたくさん表示されました。

編集2:Wikiページによると、人々はおそらく0.9の代わりにメタデータバージョン1.0を使用することを検討する必要があります。mdadmガイド

バージョン1.0では(このユースケースでは)スーパーブロックはデバイスの最後に配置する必要がありますが、1.1および1.2などの一般的なレイアウト形式を使用する「mdadmの最新機能」も含まれています。

答え2

数多くの問題を経験した後GIGABYTEのソリューション、私はあきらめ、全く異なる解決策を発明しました。

質問:

  • ファイルシステムをソートする必要があります。
  • fsck.msdosは実際にSSDのFATに失敗した書き込みを処理しません(書き込みプロセス中の電力損失による)。
  • mdraid1.0のトリックは、書き込み意図を使用しない場合にのみ機能するようですが、これは悪い考えです。
  • Linuxカーネルは順序付けられた書き込みを認識しません。 /boot/efiに書き込むと、途中で電源が切れると起動が無効になることがあります。残念ながら、DOSカーネルは(偶然に)これを正しく行いました。

最後の問題に対する私の解決策は、最終的に実際のミラーを破棄し、アップグレード後に既知の良好な状態で同期EFIのバックアップコピーを持つ2番目のSSDを維持することでした。さまざまな部分で完全なソリューションを組み立てました。

16ビットアセンブリに必要なツールだけがあるため、このソリューションは表示と同じくらい奇妙です。より良いツールがないことを後悔していますが、正直なところ、stackexchangeで評判を得るためにこれらのツールをx64に移植することはありません。とにかく、古いDOSゲームをアーカイブするには16ビットツールが必要です。ここでやっていることは、FreeDOSが最新のシステムでメンテナンス作業を実行することです。これは興味深くて怖いです。

必要になります。

  1. 8086 小さなhttps://github.com/ecm-pushbx/8086tiny

(Dosbox-xはSDLコンソールがある場合でも機能しますが、SHUTDOWN.EXEも必要です。)

  1. FreeDOS(実際には8086tinyに含まれているので、もはやパッケージはありません)

  2. 私のものSSDFMT、実際にソートされたファイルシステムをエクスポートします。

  3. 私のものはflushbuf、私が利用できないエミュレータが実際にディスクに強制的に書き込むためです。これを行うには、8086tinyに簡単にパッチを適用できますが、これは一時的な方法です。flushbufその主張を開示し、fdatasyncそれに訴えなさい。

begin-base64 755 /boot/flushbuf
f0VMRgIBAQMAAAAAAAAAAAIAPgABAAAAeAAgAAAAAABAAAAAAAAAAHgAAAAA
AAAAAAAAAEAAOAABAAAAAAAAAAEAAAAFAAAAAAAAAAAAAAAAACAAAAAAAAAA
AAAAAAAA/gAAAAAAAAD+AAAAAAAAAAAQAAAAAAAAWEiD+AJ1QV9fSDH2uAIA
AAAPBUiFwHwJSJe4SwAAAA8F99h0G1C/AgAAAEiNNCX3ACAAugcAAAC4AQAA
AA8FWJe4PAAAAA8FvwIAAABIjTQl4AAgALoXAAAAuAEAAAAPBb8OAAAA69lV
c2FnZTogZmx1c2hidWYgZGV2aWNlCkVycm9yIQo=
====

(はい、これは完全なLinux x64バイナリです。)

  1. 問題が発生したときにリムーバブルメディアを起動する機能。

構成

この答えは、/dev/sda1デバイスを使用して/dev/sda2書かれました。/dev/sda中和剤の渋滞が/dev/sdb安定したシステムがなければ、〜しなければならない代わりに値を使用してください/dev/disk/by-id/.../dev/disk/by-uuid不可能。私を信じてください。また、/dev/disk/by-id/...デバイスに入力するたびに薬が投与されるため、すべてをスクリプトで作成する必要があります。スクリプトを保存するために私が見つけた最高の場所です/boot

  1. SSDFMT.COMを8086tinyにロードしますfd.imgmtoolsまたはmount -o loop次のものを使用できます)。

  2. ルートがそうであるように

   (cd /boot/efi && tar -zcf /boot/efi-bak.tgz *)
   umount /boot/efi
   STTY_SAVE=`stty -g` 
   stty cols 80 rows 25
   ./8086tiny bios.bin fd.img hd.img
   SSDFMT
  1. SSDFMTで、SSDの実際のセクタサイズであるディスク1(唯一見えるディスク)を選択し、互換性5を選択します。強制LBAは8086tinyには適用されません。

  2. 将来のウェッジコンソールを回避するには、ハードドライブにFreeDOSをインストールする必要があります。

    QUITEMU
   ./8086tiny bios.bin fd.img hd.img
    SYS C:
    XCOPY /e *.* C:\
    QUITEMU
    /boot/flushbuf /dev/sda1
    stty `$STTY_SAVE`
  1. これはインストールされますが、CONFIG.SYSそれでもAUTOEXEC.BATフロッピーディスク上のファイルを指します。この問題を解決しましょう。
    mount /boot/efi
    sed -i 's/A:\\/C:\\/g' /boot/efi/CONFIG.SYS
    sed -i 's/A:\\/C:\\/g' /boot/efi/AUTOEXEC.BAT
  1. これでEFIを復元する時間です。
    (cd /boot/efi && tar -zxf /boot/efi-bak.tgz)
  1. アップグレードと再起動後にミラーを同期するスクリプトを作成する(起動が正常であることを確認するため)
#!/bin/sh -x
umount /boot/efi
/boot/flushbuf /dev/sda1 # replace sda1 and sdb1 with your devices
cat /dev/sda1 > /dev/sdb1
/boot/flushbuf /dev/sdb1
mount /boot/efi
  1. リバーススクリプトの生成(ファイルシステムを回復できない場合)
#!/bin/sh -x
[ -d /boot/efi/EFI ] && umount /boot/efi # probably won't be mounted
/boot/flushbuf /dev/sda2 # replace sda1 and sdb1 with your devices
cat /dev/sdb1 > /dev/sda1
/boot/flushbuf /dev/sda1
mount /boot/efi
  1. 手順7で提供されたスクリプトを実行します。

2番目のディスクは、EFIディスクから起動するためにまだ完全に登録されていません。私はオペレーティングシステムではなくBIOS設定でこの問題を解決したと確信しています。

起動時にエラーが検出された場合、fsck.msdosそれを修正できない可能性があります。重大なエラーが見つかった場合は、SSDFMTのTear Write Fixを最初に実行する必要があります。どのように?エミュレータからEFIパーティション(!)を起動します。

実行プログラムスクリプトは次のように保存する必要があります。

#!/bin/sh -x
umount /boot/efi # making sure
./8086tiny bios.bin /dev/null @/dev/sda1
fsck.msdos /dev/sda1
/boot/flushbuf /dev/sda1
mount /boot/efi

このスクリプトを実行すると、破損した書き込み確認/修復プロセスを実行した後にDOSプロンプトが表示されます。 QUITEMUを実行して戻ることができます。私はCHDKSKエミュレータで実行するかどうかについて率直な意見の違いがあると確信しています。経験が足りないので、どちらが良いかわかりません。

ボーナス:メインのDebianアップデート後にEFIパーティションを最適化すると、起動速度がはるかに速くなることがわかりました。 (私が知っている限り、これは起動ロゴによるものです。)DEFRAG.EXEをgrepすることができます。サージEFIパーティションにコピーして後で実行します。

関連情報