小型PCに最新のCentOS 7.5 x64をインストールしようとしています。ASUS EeeボックスEB1037。これはインテル Celeron J1900（Bay Trail）には、オンボードNVIDIA GeForce GT 820Mが付属しています。 Nouveau を最初に無効にしないと、インストールメディアがロックされます。大丈夫です。ただし、インストールと再起動後、EFIパーティションが破損しているようです。
この質問は、ブート方法のトラブルシューティングに関するものではなく、このブート失敗によってEFIパーティションが破損し、GRUB障害が発生する理由を理解することです。
インストールプロセスは次のとおりです。
- CentOS 7.5をUSBに書き込む
- USBインストーラで起動（grubブートローダ）
- "nouveau.modeset = 0"を追加するようにグラップオプションを編集してください。
- タイムゾーンの設定
- ソフトウェア選択：最小インストール（変更なし）
- ネットワークとホスト名：ホスト名の設定
- 手動パーティションを「標準パーティション」(LVMなし)と自動パーティションレイアウトに設定
- インストールが続行されます
- ルートパスワードとユーザーアカウントの設定（管理者権限）
- インストールが完了しました。
- 再起動
- ハードディスクGRUBが表示されます。
GRUB設定（Nouveauを無効にするなど）を変更していません。ここでデフォルト設定を確認してください。
これらのデフォルト値でCentOSを起動しようとしましたが、期待どおりに中断されました（Nouveauを無効にしていないため）。私が見るのは黒い画面だけです。モニターは点灯していますが、キーボードライトとバックライト、光学マウスLEDは消灯しています。キーボードはctrl-alt-delを担当しません。
ハードリセットを実行するには、電源ボタンを押し続けます。システムは2番目に問題なくハードディスクGRUBメニューから起動しました。デフォルトで再起動しようとしましたが、以前と同じようにロックされました（まだNouveauを無効にしていないため、期待どおり）。
CentOS USBインストーラがまだ接続されています。 3回目の再起動時に（最初の2回のインストール後に再起動後）、システムはハードドライブの代わりにUSB GRUBに移動しました。奇妙な。 CentOS USBを取り出し、ctrl-alt-delを使用して再起動します。
GRUBからEFIパーティションを読み取れないというメッセージが画面に点滅していることがわかります。
しばらくするとそれが消えて、私はこれを見ました：
システムはEFIパーティションから起動できなくなりました。
なぜこれが起こるのですか？ EFIパーティションはどのように破損しますか？
追加情報
セキュアブート〜できるようにするBIOSでは無効にすることはできませんが、「その他のオペレーティングシステム」に設定されています。
このデバイスには内部にSATAポートが1つだけあり、Samsung 850 Pro 500GB SSDが含まれています。 AHCIに設定され、SATA1として表示され、システムに接続された唯一のディスクですが、CentOSではsdbUSBsdaインストールメディアをsda。ただし、インストール中にUSBドライブが2番目のディスクとして表示されず、Samsung SSDが唯一表示されるドライブとして表示されます。
接続すると、GRUBは接続されたCentOSインストールUSBメディアを（hd0）、オンボードSATAを（hd1）として認識します。 USB メディアを取り外すと、オンボード SATA が (hd0) として表示されます。興味深いことに、オンボードSATAはsdCentOSインストーラでは見ることができますが、hdGRUBでは見ることができません。
強調する
- システムにNvidiaグラフィックプロセッサ（Optimus？）があります。
- セキュアブートが有効になっています（無効にすることはできません）
- BIOSでUSBディスクを接続されたSATAディスクとして表示しますか？ （
sdaインストール中にhd0GRUBから）
参考にしてください
nouveau.modeset=0USBスティックを取り外した後、GRUBを設定して更新してインストール後にシステムを起動できました/boot/efi/EFI/centos/grub.cfg。
問題は、EFIパーティションが破損した原因を理解することです！
システムスタート写真：
ベストアンサー1
この名前は、\EFI\BOOT\grubx64.efiシステムがCentOSデフォルトUEFIブートパスではなく代替パスを使用することを示します。しかし、代替ブートパス\EFI\BOOT\bootx64.efiは、SecureBoot shimが占めるということです。したがって、shimがロードされているように見えますが、次のステップは不可能です。つまり、バックアップディレクトリから実際のGRUBブートローダをロードします。
私の理論：
- インストールでは、通常の方法でブートローダー
\EFI\CentOS\shimx64.efi（SecureBootシムブートローダーと\EFI\CentOS\grubx64.efi実際のGRUBブートローダー）が設定されます。このパスは\EFI\CentOS\shimx64.efiUEFI NVRAM ブート変数に登録されます。また、インストーラはデフォルトのフォールバック/リムーバブルメディアブートパスでshimを使用して2番目のコピーを設定（試行）\EFI\BOOT\bootx64.efiし、GRUBを\EFI\BOOT\grubx64.efi。 - インストーラによって起動された最初の再起動時に、NVRAM起動変数はそのまま残り、ファームウェアは
\EFI\CentOS\shimx64.efiカーネルを使用して正常に起動する「ウォーム起動」を実行します\EFI\CentOS\grubx64.efi。 Nouveauが無効になっていないため、この起動試行は中断を引き起こします。 - その後、ファームウェアがNVRAMブート変数を忘れてしまい、システムが代替パスからブートしようとします
\EFI\BOOT\bootx64.efi。これは、UEFI に特定のディスクからブートするよう指示しますが、ブートローダパスを指定しない場合に発生します。何らかの理由でSecureBoot shimの代替コピーをロードできますが、ロードは失敗します\EFI\BOOT\grubx64.efi。参考にしてください言わなかったファイルが破損しています：ファイルが存在しないことを示します。
これでefibootmgr -v、既存のUEFIブート変数を見て、現在の設定または少なくともCentOSブートエントリを書き留めて再度失われた場合にそれを再現できるようにする必要があります。この場合、CentOSインストールメディアからリカバリモードで起動し、コマンドを使用してefibootmgrNVRAM変数を変更するか、UEFI起動設定メニューを使用して正しい設定を入力できます（許可されている場合）。 （悲しいことに、私が見たほとんどのUEFI実装はそうではありません。）
また、代替GRUBブートローダが破損していないことを確認する必要があります。ファイルは/boot/efi/EFI/BOOT/grubx64.efiLinuxと同様にアクセス可能でなければなりません。ファイルが存在し/boot/efi/EFI/CentOS/grubx64.efi、 。
最初のリブートと3番目のリブートの間にUEFI NVRAMブート変数が失われる理由は本当にわかりません。さまざまなバグを持つUEFI実装があります。それとも、Nouveauによる中断の問題を解決するためにBIOS設定をリセットしましたか？ UEFI「BIOS設定」をリセットすると、UEFIの実装によっては、NVRAMブート変数がリセットまたはリセットされないことがあります。
時々欠落しているUEFI NVRAMブート変数がファームウェアのバグであることが判明した場合は、BIOSのアップグレード：実行を確認してdmidecode -s bios-version現在のバージョンを確認できます。 ASUSサポートページによると、システムの最新のUEFI BIOSバージョンは1301です。 ASUSは通常、UEFI BIOS自体にアップデート機能を組み込んでいます。システムの場合、アップデートファイルをEFIシステムパーティション（= /boot/efiCentOSのどこにでも）に保存し、BIOS設定に移動してアップデートツールを有効にできます。そこでファイルを更新する場所を教えてください。
NVRAMの破損の考えられる原因の1つはefi-pstoreカーネルモジュールです。有効になっている場合、またはCentOS標準のカーネルに組み込まれていて、カーネルがクラッシュしたときにカーネルログを保存する機能が有効になっているpstore場合は、カーネルログを含む一連の変数でNVRAMを100％まで埋めることができます。これにより、ファームウェアは変数ストアが破損していることを検出し、NVRAMブート変数を自動的に再初期化できます。
代替が/boot/efi/EFI/BOOT/grubx64.efi実際に破損していない場合、代替パスからブートできない理由は、SecureBoot shimのバグまたはHDD代替ブートパスからセキュアブートを過度に適用することによって発生する可能性があります（技術的に文書化されていないUEFIファームウェアのバグ