起動時にGrub2のデバッグ中にgrubシェルにも到達できません。

起動時にGrub2のデバッグ中にgrubシェルにも到達できません。

uefi grub2からの起動に問題があります。つまり、Linuxはもちろん、システムはgrubコンソールにもアクセスできません。

代わりに起動プロセスを繰り返します。

同様のオペレーティングシステムからuefiパーティションをコピーしてgrub.cfgを修正して問題を「修正」しましたが、まだこれらの問題をデバッグする方法を知りたいです。

コンソールにアクセスできない場合、grubのデバッグに関する情報は表示されず、grub.cfgファイル以外のファイルの内容に関する情報も見つかりません。

私はどのファイルが存在するのかを説明する多くの情報を見ましたが、ファイルの内容がgrubのインストールごとに異なるかどうかについては何も見ませんでした。

これがgrubデバッグの問題だと思うべきですか?これはUEFIデバッグの問題に近いですか?

明らかに言えば、この質問は診断さまざまな候補ソリューションを試すのではなく、問題を分析するアプローチです。このウェブサイトには豊富な情報があります。

ベストアンサー1

さまざまなLinuxディストリビューションは、GRUB2とUEFIをさまざまな方法で使用します。 Debian / Ubuntuには、EFIシステムパーティション(ESP)にGRUB2が他のファイルシステムの実際の設定ファイルをgrub.cfg指すミニ設定があるようです。/bootRedHatは実際のGRUB構成をESPに入れているようです。

実際のファイルの内容は、grubx64.efi使用しているディストリビューションによって異なりますgrub-mkimage

  • GRUBコアイメージ
  • 多くのGRUBモジュール:少なくとも/boot/grub/x86_64-efi他のGRUBモジュールが保存されているファイルシステム(通常Debian)にアクセスするために必要なモジュールですが、UEFIシステムではすべてのモジュールをgrubx64.efiファイルに含めることができます。
  • 初期の GRUB ルートファイルシステムprefix(つまり、GRUB が GRUB モジュールディレクトリと設定ファイルを探す場所)に関する情報。 UEFI GRUBでは、これは通常/EFI/<name of distribution>ESP GRUBがインストールされているディレクトリを表します。
  • オプションの組み込み GRUB 構成ファイル
  • オプション、memdisk イメージファイル
  • オプション、GRUBモジュール、およびその他のファイルの署名を検証するために使用される公開鍵/証明書ファイル

GRUBのモジュール性はMBRスタイルのブートを使用するPCで始まったため、GRUBはMBRと最初のパーティションの先頭の間の未使用スペースに合わせる必要がありました。パーティションによっては、このスペースは非常に小さい場合があります。 UEFIでは、サイズ制限ははるかに厳しくありませんが、必要に応じてモジュールメカニズムを引き続き使用できます。

セキュアブートは、GRUBが正しく署名されず、Windows PE32バイナリ形式を使用するファイルから実行コードをロードするのを防ぎます。 GRUBモジュールはUnixスタイルのELFバイナリ形式を使用しているため、Secure Bootを使用するときに必要なすべてのモジュールをデフォルトファイルにパッケージする必要があるため、別々grubx64.efiの実行モジュールをロードする必要はありません。 LinuxカーネルにはEFIスタブが組み込まれており、実際にPE32バイナリになる可能性があるため、正しく署名するとこの問題は発生しません。

Secure Boot shimブートローダshimx64.efiはMicrosoftによって署名されているため、デフォルトですべてのSecure Boot実装はデフォルトで許可され、ロードされると、Secure Bootホワイトリストに1つまたは2つの公開キー(配布キーとオプションでMOK)が追加されます。システム所有者用に生成されたキー。これにより、システムベンダーがセキュアブート実装にLinuxディストリビューションの公開鍵を含めず、ファームウェアでユーザーが許可されたセキュアブートキーのファームウェアベースのリストを編集できない場合でも、Linuxおよびカスタムカーネルを使用できます。 。

(shimは実行のために完全に署名されていないバイナリを許可しないでください。そうしないと、「セキュアブートバイパスデバイス」になり、Microsoftおよびその他のセキュアブート署名者は署名を拒否する必要があります。)

一部のセキュアブートシステムは、有効なセキュアブート署名なしでブートローダを使用しようとすると、ブートプロセスを停止して警告メッセージを表示します。他の人は間違ったブートローダを無視し、次の起動オプションに進みます。システムにセキュアブートが有効で他の有効なブートソースがない場合、これが表示されるループの原因である可能性があります。セキュアブートが無効になっていると、UEFI用のGRUBバージョンをロードしようとする可能性があります。

使用しているLinuxディストリビューションの名前とバージョン、システムやマザーボードのメーカーとモデルがわからない場合は、より詳細な回答を提供するのは困難です。

おすすめ記事