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のコメントのおかげで、うまく機能しました。
主なステップは次のとおりです。
- Debianをインストールしましたが、ESPパーティションのRAIDを設定していません。パーティショニングプロセス中に、ESPパーティションと呼ばれる2つの同じパーティションを作成しました。それぞれに位置してい
/dev/sda1
ます。/dev/sdb1
/boot/efi
他の場所からコンテンツをコピーしました(/boot/eficopy
)。umount /boot/efi
mdadm --create --verbose /dev/md3 --level=1 --raid-devices=2 --metadata=1.0 /dev/sda1 /dev/sdb1
。もちろん、すでにアクティブなMDデバイスであれば、/dev/md3
他のデバイスに変更してください。/dev/md3
mkfs.vfat /dev/md3
- パーティションのUUIDを探す
/dev/disk/by-uuid
- 新しいUUIDに
/boot/efi
アイテムを変更する/etc/fstab
mount /boot/efi
- バックアップからデータを
/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が最新のシステムでメンテナンス作業を実行することです。これは興味深くて怖いです。
必要になります。
(Dosbox-xはSDLコンソールがある場合でも機能しますが、SHUTDOWN.EXEも必要です。)
FreeDOS(実際には8086tinyに含まれているので、もはやパッケージはありません)
私のものSSDFMT、実際にソートされたファイルシステムをエクスポートします。
私のものは
flushbuf
、私が利用できないエミュレータが実際にディスクに強制的に書き込むためです。これを行うには、8086tinyに簡単にパッチを適用できますが、これは一時的な方法です。flushbuf
その主張を開示し、fdatasync
それに訴えなさい。
begin-base64 755 /boot/flushbuf
f0VMRgIBAQMAAAAAAAAAAAIAPgABAAAAeAAgAAAAAABAAAAAAAAAAHgAAAAA
AAAAAAAAAEAAOAABAAAAAAAAAAEAAAAFAAAAAAAAAAAAAAAAACAAAAAAAAAA
AAAAAAAA/gAAAAAAAAD+AAAAAAAAAAAQAAAAAAAAWEiD+AJ1QV9fSDH2uAIA
AAAPBUiFwHwJSJe4SwAAAA8F99h0G1C/AgAAAEiNNCX3ACAAugcAAAC4AQAA
AA8FWJe4PAAAAA8FvwIAAABIjTQl4AAgALoXAAAAuAEAAAAPBb8OAAAA69lV
c2FnZTogZmx1c2hidWYgZGV2aWNlCkVycm9yIQo=
====
(はい、これは完全なLinux x64バイナリです。)
- 問題が発生したときにリムーバブルメディアを起動する機能。
構成
この答えは、/dev/sda1
デバイスを使用して/dev/sda2
書かれました。/dev/sda
中和剤の渋滞が/dev/sdb
安定したシステムがなければ、〜しなければならない代わりに値を使用してください/dev/disk/by-id/...
。/dev/disk/by-uuid
不可能。私を信じてください。また、/dev/disk/by-id/...
デバイスに入力するたびに薬が投与されるため、すべてをスクリプトで作成する必要があります。スクリプトを保存するために私が見つけた最高の場所です/boot
。
SSDFMT.COMを8086tinyにロードします
fd.img
(mtools
またはmount -o loop
次のものを使用できます)。ルートがそうであるように
(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
SSDFMTで、SSDの実際のセクタサイズであるディスク1(唯一見えるディスク)を選択し、互換性5を選択します。強制LBAは8086tinyには適用されません。
将来のウェッジコンソールを回避するには、ハードドライブにFreeDOSをインストールする必要があります。
QUITEMU
./8086tiny bios.bin fd.img hd.img
SYS C:
XCOPY /e *.* C:\
QUITEMU
/boot/flushbuf /dev/sda1
stty `$STTY_SAVE`
- これはインストールされますが、
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
- これでEFIを復元する時間です。
(cd /boot/efi && tar -zxf /boot/efi-bak.tgz)
- アップグレードと再起動後にミラーを同期するスクリプトを作成する(起動が正常であることを確認するため)
#!/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
- リバーススクリプトの生成(ファイルシステムを回復できない場合)
#!/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
- 手順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パーティションにコピーして後で実行します。