Unified Extensible Firmware Interface (日本語)

From ArchWiki
Jump to: navigation, search

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end

Unified Extensible Firmware Interface (もしくは省略して UEFI) は新しいタイプのファームウェアで、もともとは Intel によって Itanium を使ったシステム用に設計されました (その時の名前は EFI)。UEFI は BIOS システムで一般的に使われている "MBR ブートコード" メソッドとは異なる新しい OS 起動方法を取り入れています。Intel によって EFI がバージョン 1.x としてリリースされたのに始まり、それから UEFI Forum という業界団体によって開発が引き継がれ、Unified EFI という名前でバージョン 2.0 がリリースされました。2012年5月23日現在、UEFI の仕様は 2.3.1 が一番新しいバージョンです。

Note: EFI 1.x と明記しないかぎり、「EFI」と「UEFI」は相互に UEFI 2.x ファームウェアを意味するものとして使います。また、以下の手順は明白に書かれている部分を除き、一般的なものであり、Mac 特有のものではありません。手順のいくつかは Mac では動かなかったり違っていたりする可能性があります。Apple の EFI 実装は EFI 1.x バージョンでもなく UEFI 2.x バージョンでもなく、両方を混ぜあわせたものです。この種のファームウェアは UEFI の仕様には含まれていません、つまり、規格外の UEFI ファームウェアになります。

BIOS を使って OS を起動する

BIOS、Basic Input-Output System、はシステムの電源が入れられた時に一度だけ起動する一番最初のプログラムです。ハードウェアの初期化と POST 処理が全て完了すると、BIOS はデバイスブートリストの最初のデバイスの最初のブートコードを実行します。

リストが CD/DVD ドライブから始まっている場合、CD/DVD の El-Torito エントリを実行します。これが、ブータブル CD/DVD が動作する仕組みです。リストが HDD から始まっている場合、BIOS は一番最初の 440 バイトの MBR ブートコードを実行します。ブートコードはより巨大でより複雑なブートローダを起動させ、さらにそのブートローダが OS をロードします。

基本的に、BIOS はパーティションテーブルやファイルシステムの読み方を知りません。BIOS がすることは、ハードウェアの初期化と 440 バイトのブートコードのロード・実行だけです。

BIOS でのマルチブート

440 バイトのブートコード領域に収まるプログラムで出来ることはかなり少ないので、BIOS を使ってマルチブートするにはマルチブート対応のブートローダが必要になります(ここで、マルチブートとは複数のオペレーティングシステムを起動することであり、GRUB 開発者によって明示された Multiboot フォーマット内のカーネルを起動することではありません)。そのため普通は GRUB, Syslinux, LILO などの一般的なブートローダが BIOS によってロードされ、それからオペレーティングシステムをロードしたりカーネルを直接ロードします。

UEFI を使って OS を起動する

UEFI ファームウェアは上で述べているような (BIOS によって唯一サポートされている) 方法での起動はサポートしていません。UEFI は分かりやすいファイルシステムとパーティションテーブル、その両方の読み込みをサポートしています。

一般的に使われている UEFI ファームウェアは MBR と GPT 両方のパーティションテーブルをサポートしています。Apple-Intel Mac の EFI は MBR と GPT のほかに Apple Partition Map もサポートしていることが知られています。ほとんどの UEFI ファームウェアは HDD 内の FAT12 (フロッピーディスク)、FAT16 と FAT32 ファイルシステムへのアクセスと CD/DVD 内の ISO9660 (と UDF) へのアクセスをサポートしています。Apple-Intel Mac の EFI はそれらに加えて HFS/HFS+ ファイルシステムへのアクセスができます。

MBR にブートコードがあろうとなかろうと UEFI はそれを実行しません。かわりに、UEFI は "EFI SYSTEM PARTITION" という名前のパーティションテーブル内の特別なパーティションを使います、そしてその中にファームウェアによって起動するために必要なファイルが保存されています。各ベンダーは <EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/ フォルダの下にそのファイルを置きます。そしてファームウェアやシェル (UEFI シェル) を使ってブートプログラムを実行できます。EFI システムパーティションは大抵 FAT32 でフォーマットされています。

UEFI では、全てのプログラム (OS ローダ、(メモリテストアプリなどの)ユーティリティ、リカバリーツール) は EFI ファームウェアアーキテクチャに対応する UEFI アプリケーションでなくてはなりません。最近の Apple Mac を含む、市場に出ているほとんどの UEFI ファームウェアは x86_64 EFI ファームウェアを使っています。Only some older macs use i386 EFI firmware while no non-Apple UEFI system is known to use i386 EFI firmware.

64 ビット Linux や Windows とは異なり、x86_64 EFI ファームウェアは 32 ビットの EFI アプリを実行することができません。従ってブートローダがアーキテクチャに正しくコンパイルされている必要があります。

UEFI でのマルチブート

OS やベンダーはそれぞれ自身のファイルを EFI SYSTEM PARTITION に他のファイルと干渉しないように管理することができるので、UEFI を使うマルチブートは実行する UEFI アプリケーションが個々の OS のブートローダに対応しているかどうかという問題になります。このため OS を切り替えるためにブートローダのロード機構に頼る必要はなくなります。

Linux Windows x86_64 UEFI-GPT マルチブート

Windows Vista (SP1+) や 7、8 の x86_64 版は UEFI ファームウェアを使った起動をネイティブでサポートしています。しかしそれをするためには、UEFI ブートに使うディスクが GPT でパーティションされている必要があります。Windows の x86_64 版は UEFI-GPT ブートと BIOS-MBR ブート両方をサポートしています。Windows の 32 ビット版は BIOS-MBR ブートしかサポートしていません。マルチブートをどうやるのかはリファレンスセクション内のフォーラムリンクにある指示に従ってください。詳しくは http://support.microsoft.com/default.aspx?scid=kb;EN-US;2581408 を見て下さい。

Windows のような制限は Linux カーネルには存在しませんが、使用するブートローダによっては制限が存在します。Windows UEFI ブートの手前、同じディスクから起動するときには使用する Linux ブートローダも UEFI-GPT モードでインストールしなくてはなりません。

UEFI でのブートプロセス

  1. システムに電源が入る - Power On Self Test, POST 処理が行われる。
  2. UEFI ファームウェアがロードされる。
  3. ファームウェアはブートマネージャを読み込み、起動する UEFI アプリケーションがどれかを決める。
  4. ファームウェアのブートマネージャのブートエントリで定義されているように、ファームウェアは、FAT32 でフォーマットされた UEFISYS パーティションから UEFI アプリケーションを起動する。
  5. UEFI アプリケーションの設定により、UEFI アプリケーションは他のアプリケーションを起動したり (UEFI シェルや rEFInd などのブートマネージャの場合) またはカーネルや initramfs を起動する (GRUB などのブートローダの場合)。

UEFI ファームウェアアーキテクチャ

If you have a non-mac UEFI system, then you have a x86_64 (aka 64-bit) UEFI 2.x firmware.

知られている x86_64 UEFI 2.x ファームウェアには Phoenix SecureCore Tiano, AMI Aptio, Insyde H2O などがあります。

それらファームウェアを使っているシステムとして知られているものには Asus EZ Mode BIOS (in Sandy Bridge P67 and H67 motherboards), MSI ClickBIOS, HP EliteBooks, Sony Vaio Z series, Intel の多くのサーバー・デスクトップマザーボードなどがあります。


Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi. All macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware.

To find out the arch of the efi firmware in a Mac, boot into Mac OS X and type the following command

ioreg -l -p IODeviceTree | grep firmware-abi

If the command returns EFI32 then it is i386 EFI 1.x firmware. If it returns EFI64 then it is x86_64 EFI 1.x firmware. Macs do not have UEFI 2.x firmware as Apple's EFI implementation is not fully compliant with UEFI Specification.

Linux カーネルの UEFI サポート

UEFI の Linux カーネル設定オプション

UEFI システムのために必要な Linux カーネル設定オプションは:

CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_RELOCATABLE=y
CONFIG_FB_EFI=y
CONFIG_FRAMEBUFFER_CONSOLE=y

UEFI Runtime Variables/Services Support - 'efivars' kernel module . This option is important as this is required to manipulate UEFI Runtime Variables using tools like efibootmgr.

CONFIG_EFI_VARS=m
Note: Arch の core/testing では、このオプションはモジュールとしてコンパイルされています。
Note: Linux が UEFI Runtime Service にアクセスするには、UEFI ファームウェアのプロセッサーアーキテクチャと Linux カーネルのプロセッサーアーキテクチャが一致している必要があります。これは使用するブートローダとは関係ありません。
Note: If the UEFI Firmware arch and Linux Kernel arch are different, then the "noefi" kernel parameter must be used to avoid the kernel panic and boot successfully. The "noefi" option instructs the kernel not to access the UEFI Runtime Services.

GUID Partition Table GPT config option - mandatory for UEFI support

CONFIG_EFI_PARTITION=y
Note: Linux を UEFI で起動するには上記のオプション全てが必要です。公式リポジトリの Archlinux カーネルでは有効になっています。

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD より。

UEFI 変数サポート

UEFI defines variables through which an operating system can interact with the firmware. UEFI Boot Variables are used by the boot-loader and used by the OS only for early system start-up. UEFI Runtime Variables allow an OS to manage certain settings of the firmware like the UEFI Boot Manager or managing the keys for UEFI Secure Boot Protocol etc.

Note: The below steps will not work if the system has been booted in BIOS mode and will not work if the UEFI processor architecture does not match the kernel one, i.e. x86_64 UEFI + x86 32-bit Kernel and vice-versa config will not work. This is true only for efivars kernel module and efibootmgr step. The other steps (ie. upto setting up <UEFISYS>/EFI/arch/refind/{refindx64.efi,refind.conf} ) can be done even in BIOS/Legacy boot mode.

Access to UEFI Runtime services is provided by "efivars" kernel module which is enabled through the CONFIG_EFI_VAR=m kernel config option. This module once loaded exposes the variables under the directory /sys/firmware/efi/vars. One way to check whether the system has booted in UEFI boot mode is to load the "efivars" kernel module and check for the existence of /sys/firmware/efi/vars directory with contents similar to :

Sample output (x86_64-UEFI 2.3.1 in x86_64 Kernel):

# ls -1 /sys/firmware/efi/vars/
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c/
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c/
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c/
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c/
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c/
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c/
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c/
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/
MTC-eb704011-1402-11d3-8e77-00a0c969723b/
MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa/
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c/
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/
RTC-378d7b65-8da9-4773-b6e4-a47826a833e1/
del_var
new_var

The UEFI Runtime Variables will not be exposed to the OS if you have used "noefi" kernel parameter in the boot-loader menu. This parameter instructs the kernel to completely ignore UEFI Runtime Services.

ユーザースペースツール

UEFI 変数を表示・変更することができるツールがいくつかあります、即ち

  1. efibootmgr - UEFI ブートマネージャのブートエントリを作成・修正するのに使われます - efibootmgrefibootmgr-gitAUR
  2. uefivars - シンプルに変数を出力します - uefivars-gitAUR - efibootmgr ライブラリを使っています
  3. Ubuntu's Firmware Test Suite - fwts - fwts-gitAUR - uefidump コマンド - fwts uefidump

Non-Mac UEFI システム

efibootmgr

Warning: Using efibootmgr in Apple Macs will brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - mactel-bootAUR.
Note: efibootmgr command will work only if you have booted the system in UEFI mode itself, since it requires access to UEFI Runtime Variables which are available only in UEFI boot mode (with "noefi" kernel parameter NOT being used). Otherwise the message Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables is shown.

Initially the user may be required to manually launch the boot-loader from the firmware itself (using maybe the UEFI Shell) if the UEFI boot-loader was installed when the system is booted in BIOS mode. Then efibootmgr should be run to make the UEFI boot-loader entry as the default entry in the UEFI Boot Manager.

efibootmgr を使うには、まず 'efivars' カーネルモジュールをロードします:

# modprobe efivars

If you get no such device found error for this command, that means you have not booted in UEFI mode or due to some reason the kernel is unable to access UEFI Runtime Variables (noefi?).

Verify whether there are files in /sys/firmware/efi/vars/ directory. This directory and its contents are created by "efivars" kernel module and it will exist only if you have booted in UEFI mode, without the "noefi" kernel parameter.

If /sys/firmware/efi/vars/ directory is empty or does not exist, then efibootmgr command will not work. If you are unable to make the ISO/CD/DVD/USB boot in UEFI mode try #Create_UEFI_bootable_USB_from_ISO.

Note: The below commands use gummiboot-efi boot-loader as example.

Assume the boot-loader file to be launched is /boot/efi/EFI/gummiboot/gummibootx64.efi. /boot/efi/EFI/gummiboot/gummibootx64.efi can be split up as /boot/efi and /EFI/gummiboot/gummibootx64.efi, wherein /boot/efi is the mountpoint of the UEFI System Partition, which is assumed to be /dev/sdXY (here X and Y are just placeholders for the actual values - eg:- in /dev/sda1 , X=a Y=1).

To determine the actual device path for the UEFI System Partition (should be in the form /dev/sdXY), try :

# findmnt /boot/efi
TARGET SOURCE  FSTYPE OPTIONS
/boot/efi  /dev/sdXY  vfat         rw,flush,tz=UTC

Then create the boot entry using efibootmgr as follows :

# efibootmgr -c -g -d /dev/sdX -p Y -w -L "Gummiboot" -l '\EFI\gummiboot\gummibootx64.efi'

In the above command /boot/efi/EFI/gummiboot/gummibootx64.efi translates to /boot/efi and /EFI/gummiboot/gummibootx64.efi which in turn translate to drive /dev/sdX -> partition Y -> file /EFI/gummiboot/gummibootx64.efi.

UEFI uses backward slash as path separator (similar to Windows paths).

The 'label' is the name of the menu entry shown in the UEFI boot menu. This name is user's choice and does not affect the booting of the system. More info can be obtained from efibootmgr GIT README .

FAT32 filesystem is case-insensitive since it does not use UTF-8 encoding by default. In that case the firmware uses capital 'EFI' instead of small 'efi', therefore using \EFI\gummiboot\gummibootx64.efi or \efi\gummiboot\gummibootx64.efi does not matter (this will change if the filesystem encoding is UTF-8).

UEFI 用の Linux ブートローダ

UEFI Bootloaders を見て下さい。

Linux で UEFI システムパーティションを作る

Note: UEFISYS パーティションのサイズは FAT32 ファイルシステムでサポートされている範囲で自由に決めることができます。Microsoft のドキュメントによれば、FAT32 の最小パーティション・ボリュームサイズは 512 MiB です。従って UEFISYS パーティションには少なくとも 512 MiB を割り当てることが推奨されます。パーティションのサイズは多いほうが良く、特に複数の UEFI ブートローダを使う場合や UEFI を使って複数の OS をブートする場合がそうで、関連ファイルを全て保存できる十分な容量を確保してください。Linux EFISUTB ブートを使おうと思っているならば、まずカーネルと Initramfs ファイルが UEFISYS パーティションに入れるのに十分な容量があるか確認してください。

GPT でパーティションされたディスク

選択肢がふたつあります:

  • GNU Parted/GParted を使う: FAT32 パーティションを作成して、そのパーティションに "boot" フラグを設定してください。
  • GPT fdisk (または gdisk) を使う: gdisk タイプコード "EF00" のパーティションを作成して、mkfs.vfat -F32 /dev/<THAT_PARTITION> を使ってパーティションを FAT32 でフォーマットしてください。
Note: Setting "boot" flag in parted in a MBR partition marks that partition as active, while the same "boot" flag in a GPT partition marks that partition as "UEFI System Partition".
Warning: GPT ディスクのタイプコードを変更するのに util-linux の fdisk, cfdisk, sfdisk を使わないで下さい。同じく MBR ディスクで gptfdisk の gdisk, cgdisk, sgdisk を使わないで下さい、自動で GPT に変換されてしまいます (データ消失はありませんが、システムが起動に失敗するようになります)。

MBR でパーティションされたディスク

選択肢がふたつあります:

  • GNU Parted/GParted を使う: FAT32 パーティションを作成してください。それから fdisk, cfdisk, sfdisk を使ってパーティションのタイプコードを 0xEF に変更してください。
  • fdisk を使う: パーティションタイプ 0xEF でパーティションを作成し mkfs.vfat -F32 /dev/<THAT_PARTITION> を使ってパーティションを FAT32 としてフォーマットしてください。
Note: いくつかの UEFI ファームウェアは UEFI-MBR ブートができないので UEFI ブートにはいつも GPT を使うことが推奨されます。

UEFI シェル

UEFI シェルは、uefi ブートローダを含む、uefi アプリケーションを起動するためのファームウェア用のシェル/ターミナルです。それとは別に、シェルは、システムやファームウェアのメモリーマップ (memmap) などの様々な情報を取得したり、ブートマネージャ変数を変更したり (bcfg)、パーティションプログラムを実行したり (diskpart)、uefi ドライバをロードしたり、テキストファイルを編集したり (edit) するのにも使われます。

UEFI シェルダウンロードリンク

Intel の Tianocore UDK/EDK2 Sourceforge.net プロジェクトから BSD ライセンスの UEFI シェルをダウンロードできます。

Shell 2.0 works only in UEFI 2.3+ systems and is recommended over Shell 1.0 in those systems. Shell 1.0 should work in all UEFI systems irrespective of the spec. version the firmware follows. More info at ShellPkg and this mail

UEFI シェルの起動

Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called "Launch EFI Shell from filesystem device" . For those motherboards, download the x86_64 UEFI Shell and copy it to your UEFI SYSTEM PARTITION as <UEFI_SYSTEM_PARTITION>/shellx64.efi (mostly /boot/efi/shellx64.efi) .

Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either F6, F11 or F12 key.

Note: If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with Shell.efi copied as (USB)/efi/boot/bootx64.efi . This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.

重要な UEFI シェルコマンド

詳しい情報は http://software.intel.com/en-us/articles/efi-shells-and-scripting/

bcfg

BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" pdf document.

Note: Users are recommended to try bcfg only if efibootmgr fails to create working boot entries in their system.
Note: UEFI Shell 1.0 does not support bcfg command.

To dump a list of current boot entries -

Shell> bcfg boot dump -v

To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu

Shell> bcfg boot add 3 fs0:\EFI\arch\refind\refindx64.efi "Arch Linux (rEFInd)"

where fs0: is the mapping corresponding to the UEFI System Partition and \EFI\arch\refind\refindx64.efi is the file to be launched.

To remove the 4th boot option

Shell> bcfg boot rm 3

To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu)

Shell> bcfg boot mv 3 0

For bcfg help text

Shell> help bcfg -v -b

or

Shell> bcfg -? -v -b

edit

EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.

To edit, for example rEFInd's refind.conf in the UEFI System Partition (fs0: in the firmware)

Shell> fs0:
FS0:\> cd \EFI\arch\refind
FS0:\EFI\arch\refind\> edit refind.conf

ハードウェアの互換性

Main page HCL/Firmwares/UEFI


ISO から UEFI ブータブル USB を作成する

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: Standards-compliant UEFI implementations don't care about partition type on removable media; MBR in particular; see UEFI Specification Version 2.3.1 § 3.4.1.1 and § 12.3.2 and § 12.3.4.1 (Discuss in Talk:Unified Extensible Firmware Interface (日本語)#)
Note: The instructions below are specifically for Archiso/official media; Archboot preparation is identical, without the filesystem label requirement.
Note: The USB can use either MBR or GPT partition table. The filesystem can be FAT32, FAT16, or FAT12. The MBR fdisk type code should be 0x0C (preferred) or 0x0B.

First create a MBR partition table in the USB using fdisk. Mount the USB partition and create a FAT32 filesystem with LABEL as used in the Archiso configuration.

# mkdir -p /mnt/{usb,iso}
# mount -o loop archlinux-2012.12.01-dual.iso /mnt/iso

Obtain the label from /mnt/iso/loader/entries/archiso-x86_64.conf; this is used by the archiso hook in initramfs to identify the udev path to the installation media.

# awk 'BEGIN {FS="="} /archisolabel/ {print $3}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat /dev/sdXY -n

Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.

# mount /dev/sdXY /mnt/usb
# cp -r /mnt/iso/* /mnt/usb
# umount /mnt/{usb,iso}
# sync

If you find the error: "No loader found. Configuration files in /loader/entries/*.conf are needed." A possible fix is to use a different uefi bootloader to the included one, gummiboot.

Install refind-efi. In the usb's filesystem, overwrite the file EFI/boot/bootx64.efi with /usr/lib/refind/refindx64.efi.

Then copy this text to EFI/boot/refind.conf. Take care that the label in the Arch menu section (ARCH_201301 here) matches that of your usb's.

refind.conf
timeout 5
textonly

showtools about,reboot,shutdown,exit
# scan_driver_dirs EFI/tools/drivers_x64
scanfor manual,internal,external,optical

scan_delay 1
dont_scan_dirs EFI/boot

max_tags 0
default_selection "Arch Linux Archiso x86_64 UEFI USB"

menuentry "Arch Linux Archiso x86_64 UEFI USB" {
  loader /arch/boot/x86_64/vmlinuz
  initrd /arch/boot/x86_64/archiso.img
  ostype Linux
  graphics off
  options "pci=nocrs add_efi_memmap archisobasedir=arch archisolabel=ARCH_201301"
}

menuentry "UEFI x86_64 Shell v2" {
  loader /EFI/shellx64_v2.efi
  graphics off
}

menuentry "UEFI x86_64 Shell v1" {
  loader /EFI/shellx64_v1.efi
  graphics off
}

You should now be able to successfully boot, and you can choose which EFI you'd like to load.

ISO から UEFI ブートサポートを削除する

Warning: In the event that UEFI+isohybrid El Torito/MBR really causes problems, it would be better to just UEFI boot using the USB stick instructions in the previous section

Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD. If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first.

Mount the official installation media and obtain the archisolabel as shown in the previous section.

Rebuild the ISO using xorriso from libisoburn:

$ xorriso -as mkisofs -iso-level 3 \
    -full-iso9660-filenames\
    -volid "ARCH_201212" \
    -appid "Arch Linux CD" \
    -publisher "Arch Linux <https://www.archlinux.org>" \
    -preparer "prepared like a BAWSE" \
    -eltorito-boot isolinux/isolinux.bin \
    -eltorito-catalog isolinux/boot.cat \
    -no-emul-boot -boot-load-size 4 -boot-info-table \
    -isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \
    -output "~/archiso.iso" "/mnt/iso/"

Burn ~/archiso.iso to optical media and proceed with installation normally.

See also