ほとんどのディストリビューションがUEFIとGRUBをチェーンしているのはなぜですか？

ほとんどのディストリビューションは、UEFIシステムに追加のブートローダーをインストールします。UEFI自体はブートローダーであり、異なるオペレーティングシステムまたは個々のカーネルを選択するメニューを提供します。さらに、UEFI設定は、などのユーザースペースツールを使用して簡単に変更できますefibootmgr。

3.3以降のカーネルはEFI_STUBをサポートしています。つまり、カーネルはUEFIから直接ロードできます。ディストリビューションが追加のブートローダーを使用することにした理由は何ですか？Linux / UEFIのほとんどのチュートリアルは、EFI_STUBでLinuxをブートする代わりに、追加のブートローダー（rEFInd、grub2、ELILOなど）をセットアップする方法に主に焦点を当てています。

ディストリビューションに欠けている唯一のものはサポートです。ほとんどのディストリビューションは2番目のブートローダーをチェーンしているため、カーネルはUEFIブートメニューに追加されず、EFIシステムパーティションにもコピーされません。

すべての魔法を実行するには、3つのスクリプトで十分です。initramfsをESPにコピーするもの。2つ目はカーネルをESPにコピーし、UEFIブートメニューに新しいエントリを作成します。3番目のスクリプトは、ESPから古いカーネルとinitramfsを削除し、UEFIブートメニューエントリを削除します。これにより、ユーザーの操作なしで、完全に自動化されたカーネル/ initramfsの更新/パージが可能になります。私はこのアプローチを1年以上使用しており、問題なく機能しています。

ほとんどのディストリビューションがEFI_STUBの代わりにgrubを使用するのはなぜですか？

リンク：

• EFIブートパーティションを再作成する方法は？

編集：私はgrubのサポートを完全に削除するのではなく、さまざまな理由でそれを使用したい人に選択肢を提供することについて話している。ディストリビューションは、grub-efiUEFIとgrubを連鎖させたい人向けのパッケージefistub-bootと、上記のスクリプトを含むパッケージを提供できます。

UEFIが2005年にしか定義されていないことを考えると、仕様をサポートしないレガシー機器がたくさんあります。UEFIを標準ディストリビューションに追加するには、1つではなく2つのコードパスをテストする必要があります。また、ブートコードが非常に厄介であるだけでなく、テストするのに最もイライラする時間がかかるコードの1つです。

ディストリビューションのリソースは限られており、それ以上の理由はまったくないかもしれません。それは合理的でシンプルで安全かもしれませんが、UEFI以外のシステムの場合のみ、grubオプションを維持する必要があるため、それ以上の保守作業が必要になります。

誰もがディストリビューションの採用を希望する機能とオプションのリストを持っていると確信しています（数ページを紹介しますが、笑）。それらの多くは間違いなく「まったく簡単、面倒なし、正直に」 ..」。ただし、それらを実装するための人時間は無限ではありません。このような決定に直面したとき（「この機能に取り組みますか？」）、主な質問は次のとおりです。

• 必要ですか？（ここでの答えはノーです）。
• 何人の人々が利益を得るのでしょうか？（IMO：少数であり、それほど多くない）
• ユーザーが私たちが何もせずに自己に対応できる合理的な代替手段はありますか？（どうやらあります。）

人々がディストリビューションを使用する理由は、誰もがリソースの制約を受けるためです（そうでなければ、単にチームを雇い、スペースと機器を購入し、あなたが望むようにすべてをあなたに代わってもらいます）。したがって、現実には、ディストリビューションはユーザーの一般的なニーズを反映しています。

そうは言っても、私はこれがやがてオプションとして採用されると思うので、質問を支持しました。

grubに加えてUEFIブートローダーをターゲットにすると、品質管理とサポートが複雑になります。grubはフリーソフトウェアであり、ハッキング可能で、柔軟性があり、高品質であるため、ディストリビューションはUEFI仕様ではなくgrubを対象としています。チュートリアルに従ってUEFIパーティションをマウントすると、純粋なUEFIブートを引き続き取得でき/bootます。これを行うと、メンテナンスが行われるためです。

本当の問題は、人々がそれがどのように機能するか理解していないことです。たとえば、あなたの質問では、3つのスクリプトがすべて必要であり、ここでの答えのほとんどは、それを機能させるために必要なすべて/追加のメンテナンスに関するものですが、真実はあなたがそれらのスクリプトを必要としないということですまたは追加の作業。

必要なのは、ESPをバインドマウントするか、カーネルオーバーを維持したい場所であればどこでも/boot、1行で実行できます/etc/fstab。それを行うと、現在のカーネル更新スクリプトのすべてが単純に機能し続けます。

私の `/ etc / fstab 'は次のようになります。

LABEL=ESP /esp vfat defaults 0 2
#
#^ i like a separate mount point - not necessary though
#
/esp/EFI/arch_root /boot none bind,defaults 0 2
#
#^ i keep separate installations in separate directories
#

ただし、ここではメーカー固有の設定について良い点があります。UEFI は、ブートメニューのインターフェイスを明示的に指定しません。それは手間がかかるため、マシン間で一貫性がなくなります。迷惑ですが、本当です。

一方、それで、ローダーなどgrub実際のみがになり、より作業、メニューアプリケーション-などREFind関数としては-の違いを均等化し、すべてを簡素化します。

一時的な実装ソリューションとしてUEFIとGRUBをチェーンします。

UEFIサポートおよび付随する問題（セキュアブートなど）が解決されると、ますます多くのディストリビューションが直接使用します。それまでの間、これはまだ非常に新しいものです。Googleトレンドでは、採用がかなり制限されています：http : //www.google.com/trends/explore?q= cannot+boot+uefi#q=uefi%2C%20%20efi%2C ％20％20bios＆cmpt = q

他の人はすべて、純粋なUEFIソリューションを採用すること、および/または非UEFIシステムと純粋なUEFIシステムの両方を同時にサポートすることの潜在的な落とし穴について言及しています。UEFIカーネルは非UEFYシステムで動作する可能性がありますが、カーネル更新ツールはGRUBメニューまたはUEFIブートメニュー、あるいはその両方などを更新する必要があります。

前述のように、品質管理に関するものです。重要なことは、このコードの問題は大きな影響を及ぼします。コンピューターが新しいユーザー、つまり潜在的なLinux変換の起動に失敗すると、それをゴミとして捨てて「安全」なものに戻ります。

しかし、私が言ったように、テクノロジーがより多く採用されると、それが標準になります。

ファームウェアのバグを回避するには追加のコードが必要です

GRUBをチェーン化していない場合、ディストリビューションは正しく起動するためにより多くのファームウェアに依存しています。ソフトウェアには問題があるため、ファームウェアもその傾向があります。これで、Linuxディストリビューションは、これらのファームウェアのバグを回避するために作成する必要があります。

例としての実際のケース。Asrock H81 pro BTC P1.80マザーボードでは、でブートメニューエントリを作成できますefibootmgr。複数のブートメニューエントリを作成し、を使用してブート順序を変更しefibootmgr --bootorder XXXX,YYYY,ZZZZたり、を使用して一時的な次回ブートオプションを設定したりできますefibootmgr --bootnext XXXX。これらのコマンドは両方とも出力を返します。これにより、ブート順序が変更されたか、次回のブートが実行されるなどのアイデアが得られますBootNext: XXXX。ただし、リブートすると、頑固なファームウェアは新しく要求されたブートオプションを無視し、以前のBootCurrent:値でリブートします。永続的な起動順序の変更は、ファームウェアセットアップユーティリティからのみ行うことができます。そして、非永続的な変更はまったく利用できません。

ブートがEFIのみによって行われ、ブートローダーを削除すると、HWベンダーとオペレーティングシステムメーカーの両方にとって困難になると思います。HWベンダーはテストするカーネルを増やしますが、OSを製造する企業にとっては、カーネルが異なるFWによってロードされるかどうかに似ています。

さらに、EFIからカーネルを直接起動する場合、スタックのどこにセキュアブートが収まりますか？現在のシナリオでは、制御がOSブートローダーに移ると、ブートローダーはカーネルが正しく署名されているかどうかを確認します。カーネルをEFIから直接ロードする場合、スタック全体が乱れたときにのみ混乱が生じると思います。私の理解からの意見です。