ほとんどのディストリビューションが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を使用するのはなぜですか？
リンク：
編集：私はGRUBサポートを完全に削除することについて話しているのではなく、さまざまな理由でそれを使用したい人に選択肢を提供するために話している。ディストリビューションはパッケージを提供できますgrub-efi UEFIとgrubとパッケージをチェーン化したい人のためにefistub-boot上記のスクリプトが含まれています。
UEFIが2005年に のみ定義されたことを考えると 仕様をサポートしていないレガシー機器がたくさんあります。 UEFIを標準ディストリビューションに追加するには、1つではなく2つのコードパスをテストする必要があり、ブートコードが非常に扱いにくいだけでなく、テストするのに最もイライラするほど時間がかかるコードの1つです。
ディストリビューションのリソースは限られているため、それ以上の理由はないかもしれません。それは合理的にシンプルで安全かもしれませんが、非UEFIシステムの場合のみ、grubオプションを維持する必要があるため、それはより多くのメンテナンス作業が必要になりますです。
誰もがディストリビューションで採用してほしい機能とオプションのリストを持っていると思います（数ページお伝えします笑）。 ……」ただし、それらを実装するために必要な時間は無限ではありません。このような決定に直面した場合（「この機能に他の機能と比較して作業を行いますか？」）主な質問は次のとおりです。
- 必要ですか？ （ここでの答えはノーです）。
- 何人の人々が恩恵を受けますか？ （IMO：少数、多くない）
- ユーザーが何もせずに自分自身に対応できる合理的な代替手段はありますか？ （どうやらあります。）
人々がディストリビューションを使用する理由は、everyoneがリソースの制約を受けているためです（そうでない場合は、チームを雇って、スペースと設備を購入し、彼らはあなたが望むようにあなたのためにすべてを行います）。したがって、実際には、ディストリビューションはユーザーのgeneralizedニーズを反映しているということです。
とはいえ、これはいずれオプションとして採用されると思いますので、質問に賛成しました。
GRUBに加えてUEFIブートローダーをターゲットにすると、品質管理とサポートが複雑になります。ディストリビューションは、UEFI仕様ではなく、GRUBをターゲットにしています。GRUBはフリーソフトウェアであり、ハッキング可能で、柔軟性が高く、高品質であるためです。チュートリアルに従って/bootにUEFIパーティションをマウントすることで、純粋なUEFIブートを取得できます。これを行うと、メンテナンスが必要になります。
本当の問題は、人々がそれがどのように機能するかを理解していないことです。たとえば、あなたの質問では、3つのスクリプトが必要なすべてであり、ここでの答えのほとんどは、それを機能させるために必要となるすべて/追加のメンテナンスに関するものですが、実際にはそれらのスクリプトは必要ありませんまたは追加作業。
必要なのは、ESP-またはカーネルを保持したい場所に-/bootをバインドマウントすることだけです。これは、/etc/fstabの1行で実行できます。そうすれば、現在のカーネル更新スクリプトはすべてそのまま機能します。
私の `/ 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 explicitlyはnotを実行して、ブートメニューのインターフェイスを指定します。それはグラブの問題であり、マシン間で一貫していません。それは迷惑ですが、本当です。
そのため、grubなどのloaderは実際にはmoreの機能のみを提供しますが、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 menu OR UEFIブートメニューOR両方など）.
それは本当に言及された品質管理に関するものです：重要なことに、このコードの問題は大きな影響を与えます：コンピューターが新しいユーザーの起動に失敗した場合、つまりLinuxの潜在的な変換がゴミとして捨てられ、「安全」なものに戻ります。
しかし、私が言ったように、テクノロジーがより採用されるにつれて、それは標準になるでしょう。
ファームウェアのバグを回避するには、追加のコードが必要です
GRUBをチェーンしない場合、ディストリビューションは正しく起動するためにファームウェアに依存しています。どのソフトウェアにも問題があるので、ファームウェアにもその傾向があります。 Linuxディストリビューションは、これらのファームウェアのバグを回避するためにも書き込む必要があります。
例として実際のケース。 Asrock H81プロBTC P1.80マザーボードでは、efibootmgrを使用してブートメニューエントリを作成できます。複数のブートメニューエントリを作成でき、efibootmgr --bootorder XXXX,YYYY,ZZZZを使用してブート順序を変更したり、efibootmgr --bootnext XXXXを使用して一時的な次のブートオプションを設定したりできます。これらのコマンドは両方とも、たとえばBootNext: XXXXのように、起動順序が変更されたか、次回の起動が実行されるという考えを与える出力を返します。ただし、再起動時に頑固なファームウェアは、新しく要求された起動オプションを無視して、以前のBootCurrent:値で再起動します。永続的なブート順序の変更は、ファームウェアセットアップユーティリティからのみ行うことができます。そして、永続的でない変更はまったく利用できません。