Lenovo IdeaPad S10

IdeaPad SシリーズにMac OS XをGPT構成で導入する

※本稿は2009年12月〜2010年1月にかけて執筆され、Lenovo IdeaPad S10 (4231 米国版, BIOS 14CN96WW)へパーティションをGPT方式で構成したTranscend TS64GSSD25S-M (2.5インチ 64GB SATA SSD)を搭載し、Lenovo S10 Enablerを使用して導入したMac OS X Snow Leopard 10.6 Retailから10.6.2へコンボアップデートした環境に、疑似的なBoot CampパーティションへのMicrosoft Windows XP Professional SP3 日本語版の導入と、Mac OS X上のVMware Fusion Version 3.0.1.215242による仮想化を検証したものです。

※できる限り簡便な言葉を使用して記していますが、UNIXコマンドに関する基本的な知識と、ある程度のHDDのパーティションに関する知識が必要です。

IdeaPad SシリーズにOSX86を導入する場合、MSIWindOSX86やS10Enablerなどをそのまま使用すると、HDDのパーティション形式はMBR構成で導入されるようになっています。

通常はMBR形式でも困りませんが、特にVMware Fusionなどから扱える疑似Boot Campを利用したい場合はGPT構成でないといけません。

また、Mac OS XをいわゆるVanillaな状態で導入したい場合は、bootとExtraディレクトリを扱うために、GPT構成のみで隠し領域として生成されるGPT保護パーティションが重要になります。

※Mac OS X 10.6.2以降からDarwinカーネルがPentium MやAtomプロセッサを認識しなくなったため、パッチ済みのカーネルが必要となり、厳密なVanillaとして動作させることは出来なくなりました。これはSnow Leopardが、Pentium MプロセッサとMac OS X 10.4を搭載していたApple TVをサポートしなくなることを意味していると考えられます。

GPT構成で導入するメリットとしては、EFI規格に準拠するAppleの実機により近い構成となることです。逆に他OSを利用する場合には、そのOSがGPTに対応していない場合において若干の制約が出る場合があります。

GPT構成は本来ならばEFIによってサポートされるもので、BIOSとMBR構成を基本とするX86プロセッサ向けのほとんどのOSは、EFIに対応しないか限定的なサポートしか提供しておらず、GPTにはMBR互換テーブルがあるものの、これはGPTとMBRの完全な互換性を約束するものではないからです(※Intelの提唱したEFI規格は、主にIntel Itaniumプロセッサを搭載するハードウェアとAppleのハードウェアで採用されています)。

GPT構成での導入

GPT構成で導入する場合、Preboot CDを利用してMac OS XのインストールDVDを起動したり、S10Enablerによって起動可能となったMac OS Xインストール用USBメモリなどから起動し、ディスクユーティリティを使用してオプションからパーティション形式を選択します。Mac OS XとWindowsの2パーティション構成を前提としています。

Mac OS X用のパーティションをJournaled HFS+ (case-insensitive)形式で、Windows用のパーティションをFAT形式で用意しておけばいいでしょう(このパーティションをWindowsインストーラ上からNTFS形式へ変換しても大丈夫です)。

ディスクユーティリティの画面上にはパーティションIDがdisk0s1となるGPT保護パーティションは現れず、画面上での上側がdisk0s2、下側がdisk0s3……というIDになります。

Windows Vista以降はdisk0s4などとどこへ導入しても大丈夫ですが、Windows XPは導入先がdisk0s3でないといけません。Mac OS Xは基本的に(先頭の)disk0s2へ導入することとなります。

この後、Mac OS Xを通常どおりインストールします。

ブートローダの処理

Mac OS Xのインストール後、新たにChameleonのようなEFIをエミュレーションするブートローダを導入する際(※S10Enablerでは、Mini Chameleonと呼ばれるカスタマイズされたChameleonブートローダがMac OS Xのインストールされたパーティションに導入されています)は、disk0s1にある200MBほどのGPT保護パーティションを利用します。このパーティションはEFIアプリケーションが使用するために予約されていますが、Appleの実機はこの領域を利用せず、もちろんX86 PCであるIdeaPadでも基本的には利用されません。このため、ブートローダ用に使用するパーティションとしては好都合です。以降の作業では、Chameleon 2.0 RC3 r-658を使用して作業を行っています。この作業はsuperuser権限で行う必要があるため、suコマンドなどで権限を取得してから行ってください。

Mac OS XのディスクユーティリティでGPT構成にした場合、このパーティションはHFS+形式でフォーマットされているため、マウントして必要なファイルを書き込みます。

mkdir /Volumes/EFI; mount_hfs /dev/disk0s1 /Volumes/EFI

マウントしようとした際にエラーが発生する場合は、ファイルシステムのチェックが必要な場合があります。

fsck_hfs -f /dev/disk0s1

この後、もう一度マウントを実行してみましょう。

mkdir /Volumes/EFI; mount_hfs /dev/disk0s1 /Volumes/EFI

これでもエラーが出てマウントできない場合、下で述べるようにGPT保護パーティションのファイルシステムを初期化する必要がありますが、IdeaPad上でこのパーティションを初期化しようとするとHDDのパーティションテーブルが壊れてしまい、以降はディスク全体を初期化しない限りMBR互換テーブルの内容が狂ってしまうことがあります。

IdeaPad上でGPT構成のディスクを壊さないために

上記のような状況に陥ると、GPTに完全対応していないWindowsなど他OSのインストーラやブートローダなどからはHDDのパーティション情報が読み取れず、OSのインストールや起動が出来なくなる問題が発生します。

この状況では、GPT構成のパーティション情報を利用するdiskutilコマンドでは正しくパーティション情報が読み取れますが、MBRからの情報を優先するfdiskコマンドでは正しく読み取れず、HDD全体を1パーティション構成のGPT保護パーティションであるかのように扱ってしまいます(※この状態から回復させるためにgptコマンドが存在しますが、このコマンドはまだほとんどの機能が実装されていないため、10.6.2の段階では環境復旧の役には立ちませんでした)。

おそらくこの問題は、Intel 945チップセットがSATA HDDを扱えないという仕様上から、IdeaPadではSATA HDDをPATAへ変換して扱っている(そして、その変換ロジックのローレベルな部分に不具合が潜在している)ことに起因しており、他のSATAネイティブなPCやUSB変換を噛ませた上で編集すれば問題は起こりません(※IdeaPadのように問題が起こる可能性のあるPCもあります。筆者はThinkPad X200s上のMac OS X 10.6.2から編集して問題ありませんでした)。このため、いったんHDDを取り出した上で、他のPCなどでの作業が必要です。

まず、GPT保護パーティションのファイルシステムをHFS+形式で初期化します。

newfs_hfs -v EFI /dev/rdiskXs1

他のPCへ接続した場合はディスク番号が異なる可能性があるため、ここでは rdisk"X"s1 と表記しています。mountコマンドなどで同じディスクの他パーティションがどこに配置されているか確認して、数値を合わせてください。

ファイルシステムが正常に初期化できれば、マウントが実行できるはずです。以降の作業はIdeaPad実機で行っても、初期化に使用したPCで実行しても大丈夫です。

mkdir /Volumes/EFI; mount_hfs /dev/diskXs1 /Volumes/EFI

ここまで来たら、Chameleonのドキュメントにあるとおりに導入を進めればOKです。 boot0 をMBRへ、 boot1h をPBRに書き込みます。その後、ブートローダの実態である boot ファイルをGPT保護パーティションのルートへコピーします。

sudo su
(パスワードの入力)
fdisk -f boot0 -u -y /dev/rdiskX
dd if=boot1h of=/dev/rdiskXs1
cp ./boot /Volumes/EFI/

S10EnablerでSnow Leopardを導入した場合、Mac OS X導入先のパーティションに /Extra/ ディレクトリが存在しますので、これをGPT保護パーティションのルートへコピーします。

また、 /System/Library/Extensions/ ディレクトリに "_" (半角アンダースコア)で始まるファイル名のkextがいくつか書き込まれていて、これらがS10Enablerによって導入されたものです。Vanillaな状態にしたい場合は、これらをGPT保護パーティションの /Extra/Extensions/ ディレクトリへ移動するといいでしょう。テーマなどを導入する場合も適宜 /Extra/ ディレクトリ内を編集します。

一連の処理が終わったら、fdiskコマンドでGPT保護パーティションをアクティブにします。

fdisk /dev/rdiskX
flag 1
write
(書き込み確認のプロンプト) y
quit

これでIdeaPadをリブートして、Chameleonのブートローダ画面が表示されれば成功です。

Windowsの導入

先ほど用意したパーティションにWindowsを導入する場合、Windowsのバージョンによってはパーティションをアクティブにしておく必要がある場合があります。あらかじめアクティブにせずにインストーラを起動してパーティションが見えなかった場合、Mac OS X上などからアクティブパーティションを切り替えて再実行してください。なお、先述のとおりですが、Windows XPはパーティション番号がdisk0s3でないと導入できません。

インストールが終わったらアクティブパーティションをdisk0s1に戻す必要がありますが、Windowsのディスクの管理からはこれができないことがあります。

この場合は、Mac OS XのインストールDVDなどから起動してfdiskコマンドを使用したり、Windowsの回復コンソールからdiskpartコマンドを使用して修復する必要があります(※Windows XPのdiskpartコマンドにはパーティションをアクティブにする機能がないため、別のOSを利用する必要があるかもしれません)。

また、WindowsのバージョンによってはMBRの内容も書き換えてしまうため、この場合は何らかの形でChameleonのブートローダを書き込み直す必要があります。

疑似Boot Campとして活用するための処理

元々は単一OSしか起動できず、EFIが起動OSを選択する機能を持ったことで複数のOSを切り替えられるようになったAppleの実機と違い、一般的なPCの起動時に複数のOSを選択する場合は、BIOSではなくブートローダであるntldrやChameleonのようなプログラムが行うため、MBR構成からGPT構成に変更しても複数のOSが起動できるという実態は同じで、恩恵はほとんど感じられません。

PCにおけるBoot Campパーティションの疑似Boot Campとしての利用価値はむしろ、Mac OS X上から仮想化して扱う場合にあります。ここではVMware Fusionを使用して仮想化を行いますが、Parallels Desktopなどでも同様のことが実行できるはずです。

Mac OS X上からVMware Fusionを起動すると、両OSが正しくGPT構成で導入できていれば、自動的にBoot Campパーティションが認識されて構成の初期化を開始します。ただし、この処理は途中でエラーを起こして終了してしまいます。VMwareを終了させて、起動させるために必要なファイルを編集しましょう。

この状態で ~/Library/Application Support/VMware Fusion/Virtual Machines/ ディレクトリを開くと、 Boot Camp ディレクトリが生成されています。

この中身である %2Fdev%2Fdisk0 ディレクトリを開くと Boot Camp partition.vmwarevm というパッケージが作成されていますので、コンテキストメニューから中身を表示してみましょう。

この中にあるファイルとして重要なものが、Boot Camp partition-pt.vmdk、Boot Camp partition.vmdk、Boot Camp partition.vmxの3つです。前のふたつは仮想マシンのディスク情報を司っていて、 "-pt" のほうは仮想マシンのMBRやパーティション構成が記録される擬似的な先頭セクタとなります。 ".vmx" のファイルは仮想マシンの構成情報を保存しています。

疑似Boot Campとして扱うために、 Boot Camp partition.vmdk ファイルの以下の部分を編集してディスク情報をごまかします。

# Extent description
RW 1 FLAT "Boot Camp partition-pt.vmdk" 0
RW 409639 ZERO 
RW 93750000 ZERO 
RW 263400 ZERO 
RW 30781440 FLAT "/dev/disk0s3" 0
RW 2048 ZERO 

"#" で始まる行はコメントで、上記の2行目からがディスクの構成情報です。最初に疑似的な先頭セクタの書き込み先となる Boot Camp partition-pt.vmdk ファイルが記されています。また、実機ではGPT保護パーティションやMac OS Xパーティション、飛び領域となる3ヶ所が ZERO として記され、これらの領域へ書き込み命令があってもVMware側で無視するようになっています。その次に "/dev/disk0s3" としてBoot Camp領域が記されています。VMwareはこのパーティションと疑似先頭セクタ以外のHDD領域に書き込みません。

ここで、 "/dev/disk0s3" の末尾にパーティションのUUIDが記されていることが問題となる場合がありますので、それを削除します。

RW 30781440 FLAT "/dev/disk0s3" 0

編集した後は、このように " 0" で終了する状態となります。

仮想マシンの構成ファイルである Boot Camp partition.vmx も編集が必要です。VMware Fusionは標準で、ネットワークアダプタとしてAMD製のネットワークアダプタをエミュレーションしますが、これがWindowsを起動する妨げとなる場合があります。この場合は、Intelのネットワークアダプタをエミュレーションするように以下の行を適当な場所( "ethernet0" を定義している付近など)へ書き加えます(※この設定は、少なくとも筆者のIdeaPad S10では必要ありませんでした)。

ethernet0.virtualDev = "e1000"

この状態でVMware Fusionを起動させ、Boot Camp partitionの仮想マシンを起動すると、boot0の読み込みエラーが表示されると思います。これは、先ほど示した Boot Camp partition-pt.vmdk ファイルには実機から読み取ったMBR(とパーティション構成)が書き込まれていますが、実機での(アクティブパーティションである)disk0s1が存在しないためにboot0からboot1hへの受け渡しが出来ないからです。

通常は仮想マシン上で起動OSの切り替えは行わないため、MBR(およびPBR)をWindowsのもので置き換え、アクティブパーティションをdisk0s3へ変更してしまうのがいちばん簡単な解決策です。これらの作業はすべて仮想マシンにのみ反映されます(すべてがBoot Camp partition-pt.vmdkへ書き込まれる内容のため)。

MBRとPBRをWindowsのものに変更するには、仮想マシンをWindowsのインストールCD/DVDから起動して、修復コンソールからfixmbrコマンドとfixbootコマンドを使用すればいいでしょう。

fixmbr
(確認のプロンプト) y
fixboot c:
(確認のプロンプト) y

Windows XPを利用している場合、GPT構成のアクティブパーティションを切り替える方法が存在しないため、アクティブパーティションの切り替えが少しやっかいかもしれません。実際にインストールしていなくても、Windows VistaやWindows 7のインストールDVDがあれば、これらで起動してから回復コンソールでdiskpartコマンドを使用すると、比較的簡単にアクティブパーティションを切り替えることが出来ます。

diskpart
select disk 0
select partition 3
active
(確認のプロンプト) y
exit

この方法が難しい場合、GPT構成のパーティションを認識できるLinuxディストリビューションのLive CDや、Preboot CDなどを使用してLeopard/Snow LeopardのインストールDVDを起動させ、ターミナルからfdiskコマンドを利用する方法もあります。

fdisk /dev/rdisk0
flag 3
write
(確認のプロンプト) y
quit

ここまでの処理が完了していれば、仮想マシンとしてBoot Campパーティションを起動させることが出来るはずです。仮想化したWindowsなどの起動後はVMwareのメニューからVMware Toolsを導入すると、Mac OS X側との親和性が向上します。

(GPTと関係のない)IdeaPad S10上での設定

ディープスリープ(ハイバネーション)周りにいくつか制約があるようです。

起動時に〝hibernate fileが古い〟という旨のエラーが出る場合、Chameleon上から "ForceWake=y" と起動オプションを指定すると、ディープスリープ時に使用される /var/vm/sleepimage ファイルが初期化されます。

ディープスリープに失敗する場合は、システム環境設定のセキュリティから、セキュアな仮想メモリオプションを使用しないようにするとうまく行くようです。

そもそものディープスリープを無効にする場合は、superuser状態でpmsetコマンドを利用して hibernatemode を 0 に設定するといいでしょう(デフォルト値は3)。

sudo pmset -u hibernatemode 0

この状態に設定すると、通常の(オンメモリな)スリープしか実行されなくなります。