Difference between revisions of "Unified Extensible Firmware Interface (日本語)"

From ArchWiki
Jump to: navigation, search
m (sync)
m (ISO から UEFI ブータブル USB を作成する)
Line 327: Line 327:
 
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.
 
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 {{pkg|refind-efi}}. In the usb's filesystem, overwrite the file {{ic|EFI/boot/bootx64.efi}} with {{ic|/usr/lib/refind/refindx64.efi}}.
+
Install {{pkg|refind-efi}}. In the usb's filesystem, overwrite the file {{ic|EFI/boot/bootx64.efi}} with {{ic|/usr/lib/refind/refind_x64.efi}}.
  
 
Then copy this text to {{ic|EFI/boot/refind.conf}}. Take care that the label in the Arch menu section ({{ic|ARCH_201301}} here) matches that of your usb's.
 
Then copy this text to {{ic|EFI/boot/refind.conf}}. Take care that the label in the Arch menu section ({{ic|ARCH_201301}} here) matches that of your usb's.

Revision as of 07:27, 1 February 2013

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 ファームウェアを使っています。古い mac だけが i386 ファームウェアを使っています、Apple 以外の UEFI システムは i386 EFI ファームウェアを使っていません。

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 ファームウェアアーキテクチャ

mac 以外の UEFI システムの場合、ファームウェアは x86_64 (または 64 ビット) UEFI 2.x です。

知られている 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 の多くのサーバー・デスクトップマザーボードなどがあります。


2008年以前のほとんどの Mac は i386-efi ファームウェアを使っています。一方、2008年移行の Mac のファームウェアはほとんど x86_64-efi です。Mac OS X Snow Leopard を動かすことのできる全ての mac は x86_64 EFI 1.x ファームウェアを使っています。

Mac の efi ファームウェアのアーキテクチャを知るには、Mac OS X を起動して次のコマンドを入力してください

ioreg -l -p IODeviceTree | grep firmware-abi

コマンドの返事が EFI32 なら、i386 EFI 1.x ファームウェアです。EFI64 と返ってくるなら、x86_64 EFI 1.x ファームウェアです。Mac は UEFI 2.x ファームウェアを持っていません、Apple の EFI 実装は UEFI の仕様に完全には準拠していないからです。

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: UEFI ファームウェアのアーキテクチャと Linux カーネルのアーキテクチャが異なっている場合、カーネルパニックを避けて起動するには "noefi" カーネルパラメータを使わなくてはなりません。"noefi" オプションはカーネルを UEFI ランタイムサービスにアクセスしないようにします。

GUID Partition Table GPT コンフィグオプション - UEFI サポートのために必須

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 はオペレーティングシステムとファームウェアが情報を交換できるように変数を定義しています。UEFI ブート変数はブートローダや OS によって初期のシステムスタートアップのためにだけに使われます。UEFI ランタイム変数によって OS が UEFI ブートマネージャなどのファームウェアの設定や UEFI Secure Boot プロトコルなどのキーの管理ができるようになっています。

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.

UEFI ランタイムサービスへのアクセスは "efivars" カーネルモジュールによって提供されています。このモジュールは CONFIG_EFI_VAR=m カーネルコンフィグオプションで有効にします。一度モジュールがロードされると /sys/firmware/efi/vars 下に変数が現れます。システムが UEFI ブートモードで起動したかどうか確認するひとつの方法は、"efivars" カーネルモジュールをロードして /sys/firmware/efi/vars ディレクトリが以下のような内容で存在しているか確認することです:

サンプル出力 (x86_64 カーネルの x86_64-UEFI 2.3.1):

# 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

ブートローダメニューであなたが "noefi" カーネルパラメータを使った場合は UEFI ランタイム変数は現れません。このカーネルパラメータは UEFI ランタイムサービスを完全に無視するようにカーネルに命じるからです。

ユーザースペースツール

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

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

Mac 以外の UEFI システム

efibootmgr

Warning: Apple Mac で efibootmgr を使うとファームウェアが塞がれマザーボード ROM のリセットが必要になる可能性があります。これに関して Ubuntu/Launch バグトラッカーでバグの報告があります。Mac の場合は bless コマンドだけを使って下さい。Fedora による実験的な Linux 用 "bless" ユーティリティがあります - mactel-bootAUR
Note: efibootmgr コマンドはシステムを UEFI モードで起動した時だけ動作します。このコマンドを使うには UEFI ランタイム変数へのアクセスが必要で、もちろんそれは UEFI ブートモードでだけ使うことができるからです (そして "noefi" カーネルパラメータを使っていない状態)。さもなければ Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables メッセージが表示されます。

UEFI ブートローダがインストールされシステムが BIOS モードで起動した場合、最初にユーザーは手動でファームウェアからブートローダを起動する必要があります (UEFI シェルを使います)。それから efibootmgr を実行して UEFI ブートローダエントリを UEFI ブートマネージャのデフォルトエントリにする必要があります。

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

# modprobe efivars

もしこのコマンドで no such device found エラーが表示されるなら、それはシステムが UEFI モードで起動してないか、なんらかの理由でカーネルが UEFI ランタイム変数にアクセスできないことを意味しています (noefi?)。

/sys/firmware/efi/vars/ ディレクトリにファイルがあるかどうか確認してください。このディレクトリとその中身は "efivars" カーネルモジュールによって作成されます、そして UEFI モードで起動し、"noefi" カーネルパラメータが使われていないときだけ存在しているはずです。

/sys/firmware/efi/vars/ ディレクトリが空だったり存在しない場合、efibootmgr コマンドは動作しません。UEFI モードで ISO/CD/DVD/USB の起動ができない場合は #ISO から UEFI ブータブル USB を作成する を試して下さい。

Note: 以下のコマンドでは例として gummiboot-efi ブートローダを使っています。

起動するブートローダファイルが /boot/efi/EFI/gummiboot/gummibootx64.efi だと仮定します。/boot/efi/EFI/gummiboot/gummibootx64.efi/boot/efi/EFI/gummiboot/gummibootx64.efi とに分割できますが、そこで /boot/efi は UEFI システムパーティションのマウントポイントで、それは /dev/sdXY と仮定します (この X と Y は本当の値の代替値です - 例:- /dev/sda1 , X=a Y=1)。

実際の UEFI システムパーティションの (/dev/sdXY という形式の) デバイスパスを調べるには、次を実行してください:

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

それから efibootmgr を使って以下のようにブートエントリを作成します:

# 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 はパスの区切り記号としてバックスラッシュを使います (Windows のパスと似ています)。

'label' は UEFI ブートメニューで表示されるメニューエントリの名前です。この名前はユーザーが選ぶことができシステムのブートには影響がありません。詳しくは efibootmgr GIT README を見て下さい。

FAT32 ファイルシステムは UTF-8 エンコードを使わないのでデフォルトで大文字・小文字を区別しません。上の場合ではファームウェアは小文字の 'efi' の代わりに大文字の 'EFI' を使っていますが、\EFI\gummiboot\gummibootx64.efi\efi\gummiboot\gummibootx64.efi に違いはありません (ファイルシステムのエンコードが 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 は UEFI 2.3+ システム上でだけ動作します。UEFI 2.3+ システムでは Shell 1.0 より 2.0 を使うことが推奨されます。Shell 1.0 はスペックに関係なく全ての UEFI システムで動作するはずです。詳しくは ShellPkgthis mail を見て下さい。

UEFI シェルの起動

Asus や AMI Aptio のマザーボード (Sandy Bridge 以上) ベースの x86_64 UEFI ファームウェアには "Launch EFI Shell from filesystem device" という名前のオプションが提供されていることがあります。そういったマザーボードでは、x86_64 UEFI シェルをダウンロードして UEFI SYSTEM PARTITION に <UEFI_SYSTEM_PARTITION>/shellx64.efi としてコピーしてください (ほとんどの場合 /boot/efi/shellx64.efi)。

Phoenix SecureCore Tiano UEFI ファームウェアを使っているシステムには UEFI シェルが組み込まれていることが知られており F6, F11, F12 キーのどれかで起動できます。

Note: 上記のメソッドを使って直接ファームウェアから UEFI シェルを起動できない場合、(USB)/efi/boot/bootx64.efi としてコピーされた Shell.efi で FAT32 USB ペンドライブを作成してください。この USB はファームウェアブートメニューを表示するはずです。このオプションを起動することで UEFI シェルが起動されます。

重要な UEFI シェルコマンド

UEFI シェルコマンドはそれぞれのページの出力ごとにポーズを入れる -b オプションをサポートしています。map は認識したファイルシステム (fs0, ...) やストレージデバイス (blk0, ...) をリストアップします。利用できるコマンドを表示するには help -b を実行してください。

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

bcfg

BCFG コマンドは UEFI NVRAM エントリを修正して、ブートエントリやドライバオプションを変更できるようにするために使われます。このコマンドについては "UEFI Shell Specification 2.0" pdf ドキュメントの 83 ページ (Section 5.3) で詳しく説明されています。

Note: Users are recommended to try bcfg only if efibootmgr fails to create working boot entries in their system.
Note: UEFI Shell 1.0 は bcfg コマンドをサポートしていません。

現在のブートエントリのリストを出力するには -

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 コマンドは nano テキストエディタに似たベーシックなテキストエディタを提供します、ただし機能は少なくなっています。EDIT コマンドのテキストエディタは UTF-8 エンコードや LF と CRLF の改行コードを扱うことができます。

例として、UEFI システムパーティションの rEFInd の refind.conf を編集するには (fs0: ファームウェア内)

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

ヘルプを出すには Ctrl-E を押して下さい。

ハードウェアの互換性

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/refind_x64.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