タイトルが示すように、Grubが破損した場合に自動的に回復する方法が必要です。店舗にローカルサーバー（Nginx、PostgreSQLなど）があるコンピュータがあり、この都市では停電が頻繁に発生し、そのようなことが発生するとグラブがクラッシュします。停電時に、次の起動時にエラーが発生した場合の grub リカバリが表示されます。 不明なファイルシステム
ある時点で彼はfsckを強制しようとしましたが失敗しました。これまでの唯一の方法は、実際にライブUbuntuフラッシュドライブがある場所に行き、ブートリカバリをインストールして修正することです。停電が発生したときに常に利用できるわけではなく、必要なくてもブートするたびに問題を解決するソリューションが必要ですが、ブートリカバリで行う作業を調整する方法がわかりません（グラフィック的に）。この状況。
よろしくお願いします。分からない部分があると申し訳ありません。
バージョン：Debian 9.7.0 64ビット
答え1
停電はGRUBを狙うミサイルではありません。 GRUBリカバリモードの起動は、GRUBのコアイメージが実際には大丈夫であることを示します。ただその設定を読み取ることはできません/boot/grub/grub.cfg。
このunknown filesystemエラーを見ると、ある種のファイルシステムの問題があり、boot-repair副作用としてファイルシステムのチェックを実行して問題を解決できる可能性があると思います。
最新のファイルシステムは、突然の停電によるファイルシステムの破損にかなり強力ですが、堅牢性には通常、ファイルシステム構造自体の整合性のみが含まれます。停電が発生する前にアプリケーションに必要なデータがディスクに書き込まれていない場合、問題は発生しません。ファイルシステムが何であるかを確認すると、再構築されます。
システムがビジネス運用にとって重要である場合、これは、そのシステムの障害によって定量化される可能性がある膨大な金銭的損失が発生する可能性があることを意味します。一日の商売を失っても、小額取引の価格よりも安いです。無停電電源装置？いいえ？だから私の最初の提案は次のとおりです。ワンタイムクイックフィックスを適用する代わりに、UPSを使用して問題を完全に排除してください。
あなたのパーティションはこんにちは？ディレクトリ/bootがルートファイルシステムの一部であり、ファイルシステムタイプがXFSの場合、ファイルシステムが完全にマウントされていないと、GRUBの読み取り専用XFSドライバで問題が発生する可能性があります。この場合、より良い解決策は、/bootより単純なファイルシステムタイプ（たとえば）を使用して別々のファイルシステムに分割することです。ほとんどの場合でも、ext3別々のファイルシステムを読み取り専用マウントとして保持することもできます。/bootオペレーティングシステム内にカーネルアップデートをインストールする場合、またはinitramfsファイルをアップデートする場合にのみ必要です。
システムはUEFIファームウェアまたは古いBIOSを使用していますか？これは利用可能な代替ブートローダのタイプに影響します。
システムのカーネル（/boot/vmlinuz-*）ファイルとinitramfs（/boot/initrd.img-*）ファイルとカーネル起動オプションをインポートし、同じオプションで/boot/grub/grub.cfg同じカーネルとinitramfsの組み合わせを起動するUSBスティックを準備することもできます。カーネルが起動し、initramfsの内容と起動オプションを提供することはもはや重要ではありません。どのようにシステムがこのポイントに達しました。これらのUSBメディアからの起動は、システムディスクからの起動とほとんど区別されません。
（以前のBIOSを使用すると、カーネルがどのメディアから起動したかを知ることができません。UEFIを使用すると起動変数が手がかりを提供しますが、オペレーティングシステムは通常これを使用しませんBootCurrent。）
これにより、少なくともシステムがinitramfsに到達します。そこで、実際にどのようなエラーが発生したかについてより良い診断を得ることができます。カーネルによって実行される主要なファイルシステム ファイルシステムエラーが検出された場合、ドライバまたは自動ファイルシステムチェックによって自動ログ回復が実行されます。