他のプラットフォームとの違い - asfdrwe/asahi-linux-translations GitHub Wiki

2023/4/29時点のDifferences with other platformsの翻訳

このページは、基本的にApple Silicon MacでのオープンOSエコシステムのTL;DR(訳注:要約)となります。このページは、他のプラットフォームでのブートプロセスに慣れている一般的なLinuxパワーユーザー向けに書かれています。詳細については対応ページをお読みください。

これは典型的な UEFI プラットフォームではありません

典型的なUEFIシステムでは、UEFIはネイティブブートファームウェアであり、インストールされたあらゆるOSを管理することが想定されています。 **Apple Siliconではそうではありません。**私たちはU-Boot UEFIレイヤーをブリッジレイヤーとしてのみ使用することで、既存の/馴染みのあるブートローダーを使用し、典型的なシステムとの互換性を維持できるようにしています。これにはいくつかの意味があります：

プラットフォームにUEFIを収容できるネイティブ UEFI 対応がないため、UEFI 変数ストレージが存在しない。これは、UEFI ブートを設定できないことを意味する。U-Boot はデフォルトの UEFI 実行ファイル (EFIBOOTBOOTAA64.EFI) から常に起動
UEFIインスタンスは複数持つことができ、各インスタンスは1つのOSのみを起動させることを意図。マルチブートはネイティブ OS インストール層とネイティブブートピッカーで実現し、UEFI 経由ではない。1つのUEFIサブシステムで複数のOSをインストールすることは、複数の理由から未対応で、将来壊れる可能性あり
複数のEFIシステムパーティションを保持できることを意味し、UUID タイプで ESP(訳注: EFIシステムパーティション)を見つけることは信頼できないことを意味する。それを行おうとするツールは、一部のユーザーに対して壊れるはず

Apple SiliconプラットフォームでOSを起動する場合、ESPには2つのコンセプトが存在します:

U-BootにUSBから起動するように指示した場合、OSが起動したESPはUSBドライブにある可能性あり
U-Boot 自体と m1n1 ステージ2 がベンダーファームウェアとともにインストールされているSystem ESP。これは常に内部NVMe上に存在

System ESP は、DeviceTree内の asahi,efi-system-partition という選択された変数を調べることで特定することができ、 /proc/device-tree/chosen/asahi,efi-system-partitionで見つけることができます。この変数には、U-Bootにどこから起動するように指示したかにかかわらず、常にSystem ESPのPARTUUIDが含まれています。

OS ESP は通常 /etc/fstab で UUID または PARTUUID で設定され、/boot/efi または /boot にマウントされます。

標準的な内蔵 NVMe インストールでは、両方の役割を果たす ESP が 1 つあります。

ファームウェアはブート時にロードされて提供されます。

私たちがLinux-firmwareやその他の個別のファームウェアパッケージでネイティブプラットフォームのファームウェアを出荷することはありません。その代わりに、3種類のファームウェアが存在します：

システムグローバルファームウェア、macOSのアップデートと一緒にmacOSによってアップデート。これは（完全なDFU消去をしない限り）バージョンを上げるだけで戻すことはなく、後方互換性があることを意図。iBootによって起動時にロード
OSペアファームウェア、Asahi LinuxインストーラーによってスタブAPFSパーティションにインストールされ、iBootによって直接ロードされる。これは後方互換性がなく、インストールするOSは、使用する特定のファームウェアのバージョンに対応する必要あり。このため、インストーラーでエキスパートモードに入り、（すべての警告にもかかわらず）デフォルト以外のバージョンを選択すると、システムが破損。現在、これをアップグレードする方法はないが、アップグレードする正当な理由があれば、将来的にアップグレードする予定
抽出ベンダファームウェア、 Asahi Linuxのインストーラが収集し、System ESPの vendorfwvendorfw.cpio に配置。これは、（initramfsとして）ブートローダによってメモリにロードされるかまたはinitramfsによってメモリにロードされ、カーネルがそれをロードできるように、起動のたびに/lib/firmware/vendorにマウントされたtmpfsに展開。これはOSとペアになるたファームウェアのバージョンと一致する必要あり。asahi-fwextractパッケージは、Asahi Linuxインストーラと同じ抽出スクリプトを含み、新しい種類のファームウェアが追加されたときにmacOSに戻って Asahi Linuxインストーラを実行しなくてもいいようにするために vendorfw.cpio をアップグレードするために使用

OSはUEFI環境とESPのペアと考えるべきでしょう。

LinuxカーネルにはDeviceTreeが同梱されており、Asahiの有効化スクリプトを使った一般的なセットアップでは、これらのDeviceTreeはm1n1や u-bootと一緒にSystem ESPにインストールされ、カーネルのアップデート時に更新されます。U-Bootとm1n1自体もパッケージとしてインストールされ、そのように更新されます。つまり、System ESPを所有しそこでブートローダを管理するOSは、1つしかインストールできないということです。

例えばリカバリ目的で一時的に USB ドライブにブートすることのように、このような UEFI 環境から他の OS を起動することを止めさせるものではありませんが、 整合しないカーネルが外部のDeviceTreeで動作するという絶対的な保証はありません。過去には、変更によってブートが完全に壊れてしまったこともあります。最近はそのようなことは少なくなりましたが、それでも起こりえます。より可能性が高いのは、機能の欠落やドライバの破損を経験するかもしれないことです。一般的に、すでに上流にあるDeviceTreeのバインディングはすべて後方互換性を保つべきですが、まだ上流にないドライバについては全部賭けです。

それでもなお、同じ UEFI パーティションから複数の OS を起動したい場合 (これは本当に実験や回復を目的とする場合、または長期的なセットアップではなく、すべて自分で手動で管理する場合のみ行うべきで、私たちは対応しない)、Syste ESP を ただ一つの OS が所有し、そこの /m1n1/boot.bin ファイルを更新することを確認しなければいけません。つまり、実行する予定の OS の 1 つを除いたすべての OS で /etc/default/update-m1n1 ファイルを作成・編集し、そこに M1N1_UPDATE_DISABLED=1 変数を追加する必要があります。これにより、標準のm1n1アップデートスクリプトの実行が停止され、m1n1、u-boot、 DeviceTreeのアップデートが無効化されます。

暗号化やシークレットストレージの SEP 対応のような将来の機能は、さらにこのペアリングに依存する可能性があり、1 つの ESP/UEFI コンテナを共有する複数の OS で動作することは期待できません。

一方、常に起動する外部 USB インストールを 1 つだけ用意し（例えば、APFS スタブとSystem ESP のみをセットアップする Asahi Linux インストーラによる『UEFI only』インストールによって）、そのインストールが内部ディスク上のSystem ESP を管理するようにしても全く問題はありません。その場合、 OSツールは、独自のEFIブートローダ（GRUBなど）を更新したいときは/boot/efiまたは/boot（設定による）を使用し、m1n1・u-boot・DeviceTreesの更新やvendorfw.cpioを探したいときは /proc/device-tree/chosen/asahi,efi-system-partition にあるUUIDでSystem ESPを検索しなければなりません。これはasahi-scriptsのリファレンス実装ではすでにそうなっています。