忍者ブログ
PCメモ
PC関係のメモ、気付いたこと。 simhとChromium OSをいじって遊んでいます。 Chromium OSのカスタムビルドを配布しています。(http://chromiumosde.gozaru.jp) twitter: @zui22904336 PGP fingerprint: 45FC 0E47 A68A FA06 02FE 2BEF B72C C6E6 F9FF 1C19
Admin / Write
2014/05/11 (Sun) 12:10
Windows XPのサポート停止で古いXPマシンをどうしようか悩んでいる方も多いと思いますが、そのなかでも厄介なのはPentium MやCeleron Mマシンです。ネット閲覧程度ならまだ十分使えるのに選択肢が結構狭まってしまっています。

XPからの引っ越し先でLinuxを思い浮かべる方も多いと思いますが、最近のメジャーなLinuxディストリビューションではPentium MやCeleron Mマシンでブートすると以下のようなエラーがでて動かないことが多かったと思います。


(簡単に再現するためVirtualBoxを使っていますが、実機でも同じエラーになるはずです。)

そのため、Puppy LinuxやZolin OSといったいわゆる軽量Linuxを使うのが普通だったのかなと思います。

しかし、最新のlubuntu 14.04(これも軽量Linuxに分類されると思いますがw)ではこの問題への回避策がとられ、Pentium Mマシンでもブートできるようになりました。たぶんCeleron MもOKだと思いますが実機がないので試していません。

Ubuntuも同じかもしれませんが、非力なPentium Mマシンに入れる気はしないので試していません。

lubuntu14.04 をPentium Mマシンでブートする


とりあえず技術的な話は置いておいて、まずはCDからのブート方法だけを書いておきます。
今回は手持ちのPentium MマシンであるThinkPad T42でためしています。

lubuntuのダウンロード方法やCD-ROMへの焼き方などはここでは触れません。CDからブートした後のメニューでの操作方法についてのみ書きます。

  1. CDからブートします。
  2. 言語選択メニューが表示されるので日本語を選びます
  3. メニュー画面が出ます。
  4. F6を押すと以下の画面になります。
  5. ESCをおして選択肢を消します。画面下に起動オプションという欄があります。
  6. forcepaeと打ち込みます
  7. RETURNキーを押すとブートが始まります。forcepaeの指定が効いた場合は以下のような表示が出ます。WARNINGと出ていますが、これはforcepae自体がちょっと無理やりな機能だという意味で出ています。基本的に気にしなくて大丈夫ですが、Pentium Mなら100%ブートできるというわけではなく、もしかしたら動かないかもしれません、ということです。この点については後述します。
  8. しばらくするとおなじみのスプラッシュ画面がでますが、うちのThinkPadでは色がおかしくなってますww
  9. 無事起動しました。
この後はあとは左上のアイコンから普通にインストールできます。

HDDへのインストール手順はメニューに従うだけですしPentium Mマシンだからといって変わることはありませんので割愛します。

CDからのブート時にforcepaeを指定して起動した場合、HDDにインストールするとgrub.cfgにforcepaeの指定がちゃんと反映されるようになっていますので、以降は何もしなくても普通にブートします。

なお、この方法がつかえるのはPentium Mのみです。Celeron Mも可能だと思うのですが試してはいません。

結局forcepaeって何?


結局このforcepaeは何をやっているのか、というと、物理アドレス拡張(PAE)というCPUの機能が今起動しようとしているCPUにあるかどうかのチェックをバイパスし、PAEが使えるCPUとみなして強引に起動をかけてしまおうというものです。

Linuxカーネルは、起動時にCPUがどんな機能をサポートしているかを確認します。このときPentium MはPAEをサポートしている、という情報を返してきません。そのため、PAEを必要とする方法でビルドされた最近のLinuxカーネルは、Pentium MはPAEが使えないのでだめだ、というエラーを返してきます。

しかし、実はPentium Mは問い合わせにしかとするだけで、実際にはPAEが使えるようなのです。いわば隠し機能というやつです。意図的に隠し機能にしたのか単なるバグでCPU FlagからPAEが抜け落ちているのかはわかりません。

なので、今回の修正ではPentium M(またはCeleron M)の場合だけforcepaeが指定されたならPAEのチェックをバイパスし、PAEが使えるものとみなしてしまう、という機能を追加してPentium Mでも動けるようにしたわけです。

今回の修正ではCPUの種類をチェックしているので、Pentium M/Celeron M以外で本当にPAE機能がないCPUや、VirutalBoxなどの仮想環境でPAEをオフにした場合などはたとえforcepaeを指定しても以前と同様のエラーになります。これらについては上に書いたPuppy LinuxやZolin OSなどのnon PAEカーネルを使っているディストリビューションでないと動きません。

今回のPentium M向け修正でのカーネルパッチの内容は以下の場所で見ることができます。

[PATCH] x86: set Pentium M as PAE capable

このパッチを見れば、forcepaeが有効になるCPUのタイプもわかります。引用するとこんな感じです。

+	} else if (err == 0x01 &&
+		   !(err_flags[0] & ~(1 << X86_FEATURE_PAE)) &&
+		   is_intel() && cpu.level == 6 &&
+		   (cpu.model == 9 || cpu.model == 13)) {

いわゆるFamily6、model9または13のCPUでだけforcepaeが効くようになっています。これはPentium MとCeleron Mに相当しますがPentium MやCeleron Mという名前の付いたCPUがすべてこれに当てはまるかは把握していません。逆に、Family6 model9/13なCPUならみんなPAEを隠し持っているかというとそれも100%断言できるかは定かではありません。上でWARNINGを出していたのはその辺をふまえて「ちょっと無理やりなんだぜ?」と言っているんだと思います。

なお、PAEフラグが立っていない時、という条件がand条件で付いているので、PAEフラグをちゃんと返してくる一部のPentium Mにはこの修正の影響が出ないようになっています。

当初カーネルパラメータはforcepaeと言っていたようですが、もっと新しい記事ではカーネルパラメータの名前がpaeに変わっています。
lubuntuには、forcepaeと言っていた当時のパッチが取り込まれたようですね。

Chromium OSへの応用


このブログでは主にChromium OSを扱っていますが、このカーネルパッチをChromium OSのカーネルソースに適用してあげると(それだけではだめで別途SSE3対策が必要)一応うちのThinkPad T42でもブートまでは持っていくことができています。



ただ、CPU周りよりも周辺機器を動かすのが大変です。

まだ無線LANが動きません。有線でつなげば一応つかうことはできます。
トラックポイントは認識しますがタッチパッドは認識しません。
他にも起動時のスプラッシュ画面が出なかったり、起動直後は画面がピンク色でいったんターミナルに切り替えて戻すとちゃんと表示されたりします。他にもいろいろ問題がありそうです。

こんな感じでこちらのThinkPad T42は苦戦していますが、今のところ、CPU周りの問題だけはクリアになっていて、ブートだけなら問題なくできます。

ほかのPentium Mマシン向けにビルドする際でもCPU周りのカスタマイズ方法は参考になるかもしれませんので、この辺の話はまた別途書きたいと思います。

15.09.08 追記: ThinkPad T42で動作するChromium OSのカスタムビルドを公開しました。興味がありましたらお試しいただければと思います。

17.04.24 追記: 「本当にPAE機能がないPentiumⅢ以前のCPU」という記載がありましたが誤りであるというご指摘をいただきましたので訂正いたしました。






ランキングに参加してみました。クリックしていただければ嬉しいです。

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

パソコン ブログランキングへ

拍手[10回]

PR


2014/05/01 (Thu) 23:14
今回はDev Serverを使ったChromium OSのアップデートやパッケージの追加を試してみようと思います。

今回は公式サイト"The Chromium Project"の"Dev server"のページをほとんどそのまま試していますので正確なことが知りたい方はそちらを参照してください。

Dev serverはChromium OSのビルド環境上で起動することのできるHTTPベースのサーバで、以下のような機能があります。

  • オートアップデートができる
  • 手動での更新も可能
  • パッケージ単位でのダウンロード・インストールができる。
    このとき、ビルドしていないものであればサーバでパッケージをビルドさせてからそれをダウンロード・インストールすることができる。

USBを使ったインストールだとディスクの中身がすべて消えてしまいますが、Dev serverを導入すると更新を行ってもホームディレクトリは消えないのでそれまでの設定を残しつつChromium OSの更新ができるようになりますのでかなり便利です。

Dev serverの起動



Dev serverはChromium OSのSDKの一部ですので、起動するにはChromium OSのSDKが必要です。また、一度は自分でChromium OSのビルドを行っていることが必要です。Chromium OSのビルドの手順はこちらの記事にまとめていますので参考にしていただければと思います。

ビルド環境があるならDev serverの起動は非常に簡単です。cros_sdkでchroot環境を立ち上げてstart_devserverコマンドを実行するだけです。

chromium@Ubuntu12:~/chromiumR35$ ./chromite/bin/cros_sdk
[sudo] password for chromium: 
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ export BOARD=x86-generic
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ start_devserver 
[01/May/2014:20:48:50] DEVSERVER Using cache directory /var/lib/devserver/static/cache
[01/May/2014:20:48:50] DEVSERVER Serving from /var/lib/devserver/static
[01/May/2014:20:48:50] XBUDDY Using shadow config file stored at /mnt/host/source/src/platform/dev/shadow_xbuddy_config.ini
[01/May/2014:20:48:50] ENGINE Listening for SIGHUP.
[01/May/2014:20:48:50] ENGINE Listening for SIGTERM.
[01/May/2014:20:48:50] ENGINE Listening for SIGUSR1.
[01/May/2014:20:48:50] ENGINE Bus STARTING
[01/May/2014:20:48:50] ENGINE Started monitor thread 'Autoreloader'.
[01/May/2014:20:48:50] ENGINE Started monitor thread '_TimeoutMonitor'.
[01/May/2014:20:48:50] ENGINE Serving on :::8080
[01/May/2014:20:48:50] ENGINE Bus STARTED
 

Dev serverはデフォルトではビルドマシンのTCPポート8080を使用します。変更する場合は--portオプションで変更できます。
Dev serverの標準出力にはログがどんどん出力されますので、Chromium OSの実機から接続があればすぐにわかります。

Chromium OS 実機側の設定


Chromium OSインストールマシン側でDev serverに接続しに行くための設定は/etc/lsb-releaseというファイルに記述されています。このファイルの下2行に以下のような記述があります。

CHROMEOS_AUSERVER=http://devserverのアドレス:ポート番号/update
CHROMEOS_DEVSERVER=http://devserverのアドレス:ポート番号/

このdevserverのアドレスには、ビルド環境上でhostname -fを実行して得られる値がChromium OSのビルド時に自動で格納されています。なので、DNSの設定をきちんと行っているなどでChromium OSの実機からビルドマシンのホスト名がきちんと認識できているなら、何も設定しなくてもビルドマシン上でDev serverを起動すればすぐ使えるようになります。
うちはその辺の設定は手を抜いているので、該当箇所をIPアドレスに書き換えて認識させましたww

Dev serverによるChromium OSの更新


Dev serverが立ち上がっており、かつ実機側の/etc/lsb-releaseが正しく設定されているなら、Chromium OSの実機でChromiumブラウザを起動して[設定]-[ヘルプ]を開けば、勝手に接続してバージョン確認を行い、今インストールされているバージョンよりDev server上のビルドイメージのほうが新しければ勝手に更新が始まります。


更新が始まってしばらくすれば以下のように再起動を促す画面が表示されます。



この状態で再起動すれば、以下のように更新されたOSが起動します。



この例では35.0.1902から35.0.1916に更新されています。

私はChromebookは持っていませんので推測ですが、おおむねChromebookと変わらないような感じで更新できているのではないでしょうか。少なくともいちいちUSBに焼いて再インストールするよりははるかにましです。

ただ、厄介といえば厄介なのが、このヘルプページを開くと「勝手に更新が始まってしまう」という点です。
メーカーがビルドしたOSならともかく自分で適当にビルドしたものだと、ふとしたはずみで勝手に更新されてしまうのはちょっと困るという場合もあります。
勝手に更新されるのが嫌なら、/etc/lsb-releaseにはあえてでたらめなアドレスを書いておき、コマンドラインから手動で更新する、という方法があります。

手動で更新を行う場合は、Chromium OSの実機上でCtrl+Alt+F2でターミナルを開き、以下のコマンドを実行します。

chronos@localhost / $ sudo update_engine_client --omaha_url=http://Devserverのアドレス:ポート番号/update --update
Password: 
[0501/220512:INFO:update_engine_client.cc(529)] Forcing an update by setting app_version to ForcedUpdate.
[0501/220512:INFO:update_engine_client.cc(531)] Initiating update check and install.
[0501/220512:INFO:update_engine_client.cc(555)] Waiting for update to complete.
LAST_CHECKED_TIME=1398949512
PROGRESS=0.000005
CURRENT_OP=UPDATE_STATUS_DOWNLOADING
NEW_VERSION=9999.0.0
NEW_SIZE=302343638
(略)
LAST_CHECKED_TIME=1398949512
PROGRESS=0.000000
CURRENT_OP=UPDATE_STATUS_UPDATED_NEED_REBOOT
NEW_VERSION=9999.0.0
NEW_SIZE=302343638
[0501/222043:INFO:update_engine_client.cc(384)] Update succeeded -- reboot needed.
chronos@localhost / $  

このコマンドを実行すると、--omaha_urlで指定したDev server上にある最新のビルドイメージに更新されます。--omaha_urlを省略した場合は/etc/lsb-releaseのCHROMEOS_AUSERVERの値が使われます。
このコマンドを実行すると現在実機にインストールされているバージョンよりDev serverのほうが古くても更新がかかります。
ただ、あくまでも更新対象はDev server上の一番新しいイメージのようです。これをコマンドラインから選択する方法はまだわかっていません。chroot環境を複数持っていれば、古いほうのchroot環境でDev serverを起動することで古いイメージに戻すことができますが、同一chroot環境でいくつもビルドイメージを持っている場合は、今のところサーバ側で細工しない限り古いバージョンへ戻す方法がわかっていません。

なお、この方法ではROOTパーティションが丸ごと新しいイメージに書き換わります。そのため、更新前の環境でROOTパーティションに対して何らかの変更を行っているとその内容がすべて消えます。
一番影響が大きいのは後付けでPDFやFlashなどのプラグインをインストールしているケースだと思いますが、基本的には再度入れなおしになります。

もしかしたらビルド時にlibpepflashplayer.soやlibpdf.soをSTATEパーティションへのシンボリックリンクにしたイメージを作っておいてこれらのプラグインをSTATEパーティションに入れるようにすれば更新時に消えないようにできるかもしれませんが、そもそもこれでちゃんと動くかどうかはまだ試してはいません。
個人で使うだけならビルド時にプラグインを含めてイメージを作っちゃうのが一番楽かもしれませんが、これもまだ試してはいません。

STATEパーティションの更新


上記の方法で更新されるのはROOTパーティションのみです。/usr/localなどが置かれているSTATEパーティションを更新する場合は、ターミナルからstateful_updateというコマンドを実行する必要があるということです。が、

chronos@localhost / $ sudo stateful_update 
Downloading stateful payload from http://xx.xx.xx.xx:8080/static/stateful.tgz
  HTTP/1.1 404 Not Found
  Date: Thu, 01 May 2014 13:29:20 GMT
  Content-Length: 1070
  Content-Type: text/html
  Server: CherryPy/3.1.2

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Successfully downloaded update.
Missing var or dev_image in stateful payload.
 

404エラーが出てしまいました。stateful_updateは

http://devserver_host:8080/static/stateful.tgz

というファイルをダウンロードしに行くようですが、devserverのstatic配下にはstateful.tgzがありません。
Dev server上のstaticディレクトリは、ビルドマシンのchroot環境では/usr/lib/devserver/staticにあたります。この下を見ると以下のようになっています。

(cr) chromium@Ubuntu12 /usr/lib/devserver/static $ ls -F
cache/  pkgroot@  x86-generic/  xbuddy_UpdateTimestamps/
 

ビルドイメージはこのディレクトリのx86-genericの下にシンボリックリンクの形で準備されます。
(cr) chromium@Ubuntu12 /usr/lib/devserver/static $ cd x86-generic/
(cr) chromium@Ubuntu12 /usr/lib/devserver/static/x86-generic $ ls -F
R35-5712.32.2014_04_20_0902-a1@  R35-5712.32.2014_04_20_2104-a1@  R35-5712.32.2014_04_28_2223-a1@
 

stateful.tgzはこのバージョン名のシンボリックリンクの下に作られています。

(cr) chromium@Ubuntu12 /usr/lib/devserver/static/x86-generic/R35-5712.32.2014_04_28_2223-a1 $ ls -F
boot.config  chromiumos_image.bin  esp/             pack_partitions.sh*  rootfs_dir/  stateful.tgz@  umount_image.sh*       update.gz@
boot.desc    config.txt            mount_image.sh*  rootfs/              stateful/    stateful_dir/  unpack_partitions.sh*  update.meta@
 

なので、以下のようにstaticディレクトリ配下に最新ビルドのstateful.tgzへのシンボリックリンクを作ります。

(cr) chromium@Ubuntu12 /usr/lib/devserver/static/x86-generic/R35-5712.32.2014_04_28_2223-a1 $ cd ../..
(cr) chromium@Ubuntu12 /usr/lib/devserver/static $ ln -s x86-generic/R35-5712.32.2014_04_28_2223-a1/stateful.tgz .
(cr) chromium@Ubuntu12 /usr/lib/devserver/static $ ls -F
cache/  pkgroot@  stateful.tgz@  x86-generic/  xbuddy_UpdateTimestamps/
 

この状態で実機上でstateful_updateを実行してみます。

chronos@localhost / $ sudo stateful_update 
Downloading stateful payload from http://xx.xx.xx.xx:8080/static/stateful.tgz
  HTTP/1.1 200 OK
  Content-Length: 59005337
  Accept-Ranges: bytes
  Server: CherryPy/3.1.2
  Last-Modified: Wed, 30 Apr 2014 09:31:20 GMT
  Date: Thu, 01 May 2014 13:30:47 GMT
  Content-Type: application/x-gtar-compressed
Successfully downloaded update.
Performing standard stateful update.
chronos@localhost / $ 
 

今度はうまくいきました。公式サイトの解説ページにはこんな作業が必要とは書いてありません。なんでこうなってしまうのかはよくわかっていません。
なお、STATEパーティションの更新はコマンド実行終了時点ではまだ行われていません。ここでダウンロードした内容は/mnt/stateful_partition/の下のdev_image_newおよびvar_newというディレクトリに格納され、リブート時に本来のディレクトリであるdev_imageおよびvar_overlayと置換されます。

なお、stateful_updateコマンド実行時に接続しに行くDev serverは、/etc/lsb-releaseのCHROMEOS_DEVSERVERで指定したアドレスになります。

また、STATEパーティションの更新では/home配下は変更されないのでユーザ固有のデータは更新後でも引き継がれます。

Dev serverから実機にパッケージをインストールする


Dev serverを使うと、OS自体の更新だけでなく、個別にパッケージを指定して実機に取り込むこともできるようになります。パッケージを個別でインストールするには以下のコマンドを実行します。

$ sudo gmerege [-n] パッケージ名 [--accept_stable]

gmergeコマンドを実行すると、デフォルトではROOTパーティションの/usr/binや/usr/libなどにバイナリがインストールされるようです。インストール先を変更できるかどうかはまだ調べていません。
ここで、-nオプションはDev server上でそのパッケージがすでにビルド済みなら改めてビルドせずにバイナリをダウンロードするように指示します。

また、--accept_stableオプションはビルド環境上の~/trunk/src/third_party/chromiumos-overlay配下にあるパッケージの一部をインストールするときに指定する必要が出てくることがあります。
chromiumos_overlay配下の一部のパッケージをインストールしようとすると以下のようなエラーが出ることがあります。

chronos@localhost / $ sudo gmerge -n binutils
Sending build request to http://xx.xx.xx.xx:8080
Package is not cros_workon'd on the devserver machine.
Either start working on the package or pass --accept_stable to gmerge
 

このエラーが出たときは--accept_stableオプションを指定して再実行するとパッケージのインストールができます。
このエラーがでるのは、chromiumos_overlay配下にあるパッケージで、ebuildファイルのinheritパラメータにcros_workonの記述があるパッケージです。
あまりこの辺の意味はよくわかっていませんが、この辺のパッケージは基本的にOSインストール時にまとめてインストールされるものですので、あらためて、パッケージ単体でインストールするものではない、ということなのでしょう。
cros_workonはそれらのパッケージに対して修正を加える際に実行するコマンドで、それが実行されているならそのパッケージはカスタマイズされていると判断されて実機に追加インストールできるようになっているが、それ以外はガードがかかっており、ガードを外すのが--accept_stableオプション、ということなのだろうと理解しています。

なお、前回の記事ではbinutilsをChromium OSのイメージに導入するのに非常にてこずりましたが、Dev serverからのインストールなら非常に簡単にできました。Chromium OSをいじるうえではDev serverは欠かせないツールになりそうです。


[関連記事]

[悲報] Chrome R44でffmpegsumoが消えた
Chromium OSにパッケージを追加する
最近のChromium OS R35がVAIO Type Pで動かない件への対策
安定版ソースを使ってChromium OSをビルドする
勝手ビルド版Chromium OSとGoogleドライブの連携
Chromium OSをKVMで動かす
勝手ビルド版Chromium OSをVirtualBoxで動くようにする
Chromium OSのカーネルをVAIO Type P向けに再構築する
Chromium OSのビルド環境を作る
Hexxeh版Chromium OSをVAIO Type Pにインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ




ランキングに参加してみました。クリックしていただければ嬉しいです。

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

パソコン ブログランキングへ

拍手[0回]



2014/04/28 (Mon) 23:38
今回はChromium OSにもともとインストールされていないソフトウェアを後から組み込む方法を試してみます。

今回追加するのはgnu binutilsとp7zipです。

binutilsに含まれているarコマンドとp7zipに含まれる7zコマンドがChromium OSに入っているとUbuntuなどのDebian系で使われているパッケージ形式であるdebファイルをChromium OS上で直接展開できるようになります。
これができるようになると、Chromeブラウザの最新版をgoogleから直接Chromium OS上にダウンロードして、そこからFlashとPDFのプラグインを抜き出してインストールすることができるようになります。

・・・まあ、スクリプトが公開されているんでそれ使ったほうが早いですがw

Flashの話はとりあえず今回はおいておいてパッケージの追加の話だけ書きます。

組み込む方法といっても方法はいくつか考えられます。
一番手っ取り早いのは普通にソースをダウンロードしてきてconfigureしてmakeする、という方法です。
もう一つはChromium OSのSDKにパッケージを追加してSDKの流儀で組み込む方法です。
このほかにDev Serverを使う方法があります。Dev serverについてはこちらの記事でまとめています。

今回はbinutilsを最初の方法、p7zipを2番目の方法でインストールしていきます。ただ、前者の方法は軽く触れるだけにして、後者をメインに書いていきます。

なお、今回も既にChromium OSのビルド環境が手元にあることを前提にして書いていきます。ビルド環境の構築方法はこちらの記事で書いています。
また、パッケージの追加・置換は手順を間違えると最悪ビルド環境が壊れてしまうので、バックアップやVMを使っているならスナップショットの作成を行って作業前に戻せるようにしておくことをお勧めします。

Configure/makeする


実はx86アーキテクチャ用のarコマンドは

/build/x86-generic/usr/i686-pc-linux-gnu/binutils-bin/2.22/ar

においてあります。なので、別にビルドしなくてもこれをコピーすれば終わりだったりしますが、物は試しということでbinutilsのmakeをやってみます。

といっても、基本的には普通にconfigureしてmakeするだけですのであまり難しいことはありません。ただ、Chromium OS用バイナリをビルドする際の注意点はいくつかあるのでそれを書いておきます。

Chromium OSのビルド環境はUbuntu12.04 LTS 64bitですので、普通にビルドするとビルド環境であるUbuntu 64bit用のバイナリができてしまいます。このブログでターゲットにしているのはx86なのでそれだと困ります。
Chromium OS用のバイナリをビルドするにはターゲットアーキテクチャ向けにクロスコンパイルを行う必要があるので、Configureなどでビルドの設定をする際にはx86用のクロスコンパイラが使われるように指定してあげる必要があります。
そのため、普通にConfigure/makeする場合でも、やはりcros_sdkを使ってchroot環境に移行して、そのchroot環境の中で作業する必要があります。

そのうえでx86用のコンパイラである
  • i686-pc-linux-gnu-gcc
  • i686-pc-linux-gnu-g++

が使われるように設定します。
gnu binutilsを手動でビルドする場合は、configureを実行する際に以下のように指定します。

./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu

p7zipのようにconfigureがないようなソフトの場合は、makefileを開いてCXXやCCなどのコンパイラ名を指定している変数を探して、該当箇所を上に書いたコンパイラ名に書き換えます。

このあと普通にmakeすれば、うまくいけばx86アーキテクチャのChromium OS用バイナリが出来上がります。

もう一点注意すべきことは、当然ですが

make installしてはいけない

ということです。特にbinutilsのようなビルド処理に直接かかわるツールをmake installすると最悪ビルド環境が壊れてしまいます。

手動でビルドした場合、バイナリはChromium OSのイメージには取り込まれませんので手動でバイナリをChromium OSがインストールされている実機にコピーする必要があります。ただし、コピー先にも注意があります。
Chromium OSではホームディレクトリに置いたバイナリは実行できないようにガードがかかっています。Chromium OSはルートパーティションがリードオンリーでマウントされているので、バイナリはSTATEパーティションにある/usr/local/binに置くのが簡単です。単に

sudo cp ~ /usr/local/bin

とすればOKです。

ここまでの内容を踏まえて、x86アーキテクチャ向けのChromium OS用binutilsのビルド手順は以下のような感じになります。

chromium@Ubuntu12:~/chromiumR35$ ./chromite/bin/cros_sdk
[sudo] password for chromium: 
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd ..
(cr) chromium@Ubuntu12 ~/trunk/src $ mkdir mypackage
(cr) chromium@Ubuntu12 ~/trunk/src $ cd mypackage
(cr) chromium@Ubuntu12 ~/trunk/src/mypackage $ wget http://ftp.gnu.org/gnu/binutils/binutils-2.24.tar.gz
(cr) chromium@Ubuntu12 ~/trunk/src/mypackage $ tar zxvf binutils-2.24.tar.gz
(cr) chromium@Ubuntu12 ~/trunk/src/mypackage $ cd binutils-2.24
(cr) chromium@Ubuntu12 ~/trunk/src/mypackage/binutils-2.24 $ ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
(cr) chromium@Ubuntu12 ~/trunk/src/mypackage/binutils-2.24 $ make
 

あとは、Chromium OSインストールマシンからscpなどでarをコピーし、/usr/local/binにコピーすればOKです。

Chromium OSのパッケージシステム


今回の内容は本家サイト"The Chromium Project"以下の各ページを参考にしています。

Chromium OSの情報源は英語ばかりなのでまた間違って理解している可能性があります。詳しいことはこれらの本家サイトをご覧ください。 
 
Chromium OSのパッケージシステムはGentoo Linuxというディストリビューションで使われているPortageというものです。Portageでは各ソフトのダウンロード・ビルド方法を拡張子がebuildのファイルに書いておき、これを実行することでソフトウェアのインストールを行います。debやrpmと違ってバイナリパッケージではなく、基本的にはソースアーカイブをネット経由でダウンロードしてから逐次ビルドするところに特徴があります(バイナリパッケージもあるようですが)。

Chromium OSのSDKでは、このebuildファイルが置かれている場所が大きく分けて以下の2つあります。 

~/trunk/src/third_party/chromiumos_overlay
~/trunk/src/third_party/portage_stable

前者はChromium OSの中核をなすパッケージや、Chromium OSに取り込むにあたってカスタマイズが施されているようなソフトのパッケージが置かれているようです。なので、ここにパッケージがあるときは下手に置き換えないほうが得策です。
こっちにおいてあるパッケージでChromium OSに取り込まれていないものはあまり多くないと思いますが、binutilsはこちらにパッケージがあるけどデフォルトではChromium OSに取り込まれないものの1つです。

これに対して、一般に配布されているオープンソースソフトウェアをそのまま取り込むようなケースではportage_stableにあるパッケージが使われます。ここにはGentoo Linuxのパッケージツリーからそのまま持ってきただけと思われるものが多数置いてありますが、必ずしも最新のパッケージになっているというわけではありません。
また、portage_stableには、実際にはChromium OSのイメージに取り込まれないようなパッケージもいくつかおいてあったりします。今回扱うものでは、p7zipがこちらに当てはまります。

上記2つのディレクトリの下には、ソフトウェアのカテゴリを表すサブディレクトリがたくさん作られています。これらのカテゴリを表すサブディレクトリのさらに下に各ソフトウェアのディレクトリが作られ、その中にebuildファイルをはじめとするパッケージの構成ファイルが入っています。

このカテゴリとソフトウェアの対応は、Gentoo Linuxの構成がそのまま踏襲されています。

今回インストールするプログラムはgnu binuitlsとp7zipですが、"binutils ebuild"とか"p7zip ebuild"などでググればGentoo Linuxのパッケージツリーが置いてあるサイトが真っ先に引っかかるので、これらのソフトのパッケージがどこに置かれるべきかはすぐわかります。

結論から言うと、p7zipはapp-archというアーカイバ関係のカテゴリ、binutilsはsys-develという開発ツール関係のカテゴリに含まれます。

p7zipとbinutilsが現状のChromium OS SDKでどこに置かれているかを一応確認しておきます。まずportage_stable配下の現状を見るとこのようになっています。

(cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable $ cd app-arch/
(cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch $ ls
bzip2       cpio  libarchive  makeself      p7zip   pigz       sharutils  tar    unzip     zip
cabextract  gzip  lzop        metadata.xml  pbzip2  rpm2targz  snappy     unrar  xz-utils
(cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch $ ls p7zip
Manifest  files  metadata.xml  p7zip-9.13.ebuild
(cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch $ cd ../sys-devel/
(cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/sys-devel $ ls
autoconf          automake          bc     binutils-config  crossdev  flex        gettext    libperl  m4    metadata.xml  smatch
autoconf-wrapper  automake-wrapper  bin86  bison            dev86     gcc-config  gnuconfig  libtool  make  patch



p7zipのほうは既にパッケージが存在していますが、バージョンが9.13とちょっと古いようです(記事作成時点では9.20が最新)。現状Chromium OSにはp7zipは含まれていませんので使われていないにも関わらずパッケージだけは置いてあるようです。
binutilsのほうはパッケージがありません。
一方、chromiumos-overlayのほうは結論だけ書きますが、p7zipについてはp7zip自体も、その上位カテゴリのapp-archもありません。それに対してbinutilsのほうはsys-develカテゴリの中にパッケージが存在しています。

これらをふまえてパッケージの追加を行っていきます。

p7zipのChromium OSへの追加


p7zipは既にパッケージが存在していますが、バージョンが古いです。この古いバージョンでビルドを試みましたがコンパイルエラーになりました。
p7zipはchromiumos-overlaysのほうにパッケージがないので、思い切ってバージョンをあげてしまいます。
Chromium OS SDKにはパッケージの更新を行うための専用のコマンドが用意されているので、そのコマンドで更新をかけます。

一応、Chromium SDKを起動するところから手順を書いてきます。

chromium@Ubuntu12:~$ cd ~/chromiumR35
chromium@Ubuntu12:~/chromiumR35$ ./chromite/bin/cros_sdk
[sudo] password for chromium: 
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ export BOARD=x86-generic
 

今回は~/trank/src/third_party/portage_stableで作業をするので、ここにブランチを作ります。

(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd ~/trunk/src/third_party/portage-stable/
(cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable $ repo start my-portage .
(cr) (release-R35-5712.B/my-portage) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable $ 
 

続けてcros_portage_upgradeというコマンドを実行します。これが上流サイトから最新のパッケージをダウンロードして置き換えるためのコマンドです。

(cr) (release-R35-5712.B/my-portage) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable $ cros_portage_upgrade --board=${BOARD} --upgrade p7zip
You have selected boards for archs ['x86'], which does not cover all standard archs ['amd64', 'arm', 'x86']
If you continue with this upgrade you may break builds for architectures not covered by your
boards.  Continue only if you have a reason to limit this upgrade to these specific architectures.


Do you want to continue anyway? (yes/No)? yes
 

黄色い文字で警告が表示されます。これは、--boardオプションでx86-genericだけを指定したためです。--boardオプションは:で区切って複数のアーキテクチャを指定できますが、私が使っている環境がx86しかセットアップしていないので1つだけ指定しています。 この警告ではパッケージの置換は他のアーキテクチャにも影響を与えるため、1つだけ指定すると他のアーキテクチャでビルドできなくなるかもしれないよ、というようなことを言っているようです。ここはとりあえずyesを入力して先に進みます。

Cloning origin/gentoo at /tmp/portage as upstream reference.
Cloning into 'portage'...
remote: Sending approximately 1.04 GiB ...
(略)

Running with board x86-generic.
Resolved "p7zip" to "app-arch/p7zip-9.13" (local) and "app-arch/p7zip-9.20.1-r4" (upstream).
Copying app-arch/p7zip-9.20.1-r4 from upstream.
Editing u'/mnt/host/source/src/third_party/portage-stable/app-arch/p7zip/p7zip-9.20.1-r4.ebuild' to mark it stable for everyone
Confirmed that all upgraded packages can be emerged on x86-generic after upgrade.
Keeping upstream cache at /tmp/portage.
[my-portage fbe5285] p7zip: upgraded package to upstream
 9 files changed, 119 insertions(+), 150 deletions(-)
 delete mode 100644 app-arch/p7zip/files/9.04-kde4.patch
 rename app-arch/p7zip/files/{p7zip-9.13-QA.patch => p7zip-9.20.1-QA.patch} (91%)
 create mode 100644 app-arch/p7zip/files/p7zip-9.20.1-execstack.patch
 create mode 100644 app-arch/p7zip/files/p7zip-9.20.1-long_rar_pwd.patch
 rename app-arch/p7zip/{p7zip-9.13.ebuild => p7zip-9.20.1-r4.ebuild} (56%)
 delete mode 100644 metadata/md5-cache/app-arch/p7zip-9.13
 create mode 100644 metadata/md5-cache/app-arch/p7zip-9.20.1-r4

Upgrade changes committed (see above), but message needs edit BY YOU:
 cd /mnt/host/source/src/third_party/portage-stable; git commit --amend; cd -

To remove any individual file above from commit do:
 cd /mnt/host/source/src/third_party/portage-stable; git reset HEAD~ <filepath>; rm <filepath>; git commit --amend -C HEAD; cd -

If you wish to undo all the changes to portage-stable:
 cd /mnt/host/source/src/third_party/portage-stable; git reset --hard HEAD~; cd -
 


冒頭に

Cloning origin/gentoo at /tmp/portage as upstream reference.

と表示されていますが、要するにリモートのパッケージツリーからパッケージをダウンロードしてきて/tmp/potargeに一旦置いた後に、依存関係などをチェックしながら最終的に~/trunk/src/third_party/portage_stableの下のパッケージを置き換えています。
出力内容からp7zipが9.13から9.20.1-r4に置き換わったことが分かります。
ちなみにChromium OS SDKでは上流のパッケージサイトのURLは
 https://chromium.googlesource.com/chromiumos/overlays/portage
になります。

このcros_portage_upgradeコマンドは、コマンド名こそupgradeですが、portage_stableにないパッケージでも上流サイトにあれば持ってくることができます。

一度実行すると/tmp/portageに上流サイトのパッケージツリーのクローンができるので、ここにできるパッケージはとりあえず持ってきてビルドにチャレンジすることはできると思います。うまくいくかどうかはやってみないとわかりませんが。

コンパイルできるかチェックする


持ってきたパッケージがそのままコンパイルできるとは限りません。とくにGUI系のツールは多分無理だと思います。今回はコマンドラインツールなので十分期待できます。
コンパイルだけを実行する場合はebuild-${BOARD}というコマンドに引数としてebuildファイル名とオプション"compile"を指定して実行します。
${BOARD}はターゲットアーキテクチャを表す文字列です。今回の場合はx86-genericなのでコマンドはebuild-x86-genericです。GentooLinuxで使われているのebuildコマンドを直接使うことは基本的にはありません。

(cr) (release-R35-5712.B/my-portage) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch/p7zip $ ebuild-x86-generic p7zip-9.20.1-r4.ebuild compile
>>> Downloading 'https://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/p7zip_9.20.1_src_all.tar.bz2'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404 Not Found
>>> Downloading 'https://commondatastorage.googleapis.com/chromeos-mirror/gentoo/distfiles/p7zip_9.20.1_src_all.tar.bz2'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 3745k  100 3745k    0     0  2190k      0  0:00:01  0:00:01 --:--:-- 2195k
 * p7zip_9.20.1_src_all.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                 [ ok ]
 * Running stacked hooks for pre_pkg_setup
 *    sysroot_build_bin_dir ...                                                                                                      [ ok ]
 * Running stacked hooks for pre_src_unpack
 *    python_multilib_setup ...                                                                                                      [ ok ]
>>> Unpacking source...
>>> Unpacking p7zip_9.20.1_src_all.tar.bz2 to /build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work
>>> Source unpacked in /build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work
>>> Preparing source in /build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work/p7zip_9.20.1 ...
 * Applying p7zip-9.20.1-execstack.patch ...                                                                                         [ ok ]
 * Applying p7zip-9.20.1-QA.patch ...                                                                                                [ ok ]
 * Applying 9.04-makefile.patch ...                                                                                                  [ ok ]
>>> Source prepared.
>>> Configuring source in /build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work/p7zip_9.20.1 ...
>>> Source configured.
>>> Compiling source in /build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work/p7zip_9.20.1 ...
(略)
make[1]: Leaving directory `/build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work/p7zip_9.20.1/CPP/7zip/UI/Console'
>>> Source compiled.
(cr) (release-R35-5712.B/my-portage) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch/p7zip $ 
 

うまくコンパイルできたようです。
ちなみにパッケージそのものにはソースコードは含まれておらず、ビルド時にリモートからダウンロードするようになっています。ダウンロードしたソースコードは
/build/${BOARD}/tmp/portage/の下に置かれます。

ビルドしたp7zipをChromium OSに組み込む


ここまででp7zipのパッケージをコンパイルしましたが、これだけではChromium OSにビルド結果が取り込まれません。取り込まれるようにするためには、~/trunk/src/third_party/chromiumos_overlay/chromeos-baseの下にある以下のいずれかのパッケージのebuildファイルを編集して、追加するパッケージ名を依存関係の一覧に追記する必要があります。
  • chromeos
  • chromeos-dev

前者に追加した場合、バイナリはChromium OSの/usr/binや/usr/libにインストールされます。後者に追加した場合は/usr/local配下にバイナリが置かれます。
特段の必要がなければ基本的にはchromeos-devのほうにパッケージを追加したほうが簡単です。
chromeosのほうに追加する場合は、以下の2点に気を使う必要があります。

a. ルートパーティションの容量

b. シェアードライブラリの依存関係

まずパーティションの容量ですが、/usr/binはルートパーティションに置かれます。Chromium OSのルートパーティションはデフォルトで1.2GB程度しか確保されていません。そのためあまりこちらにものを入れすぎるとルートパーティションが足りなくなる可能性があります。/usr/localが置かれるSTATEパーティションは他のパーティションを確保した後の残容量全部が割り当てられるため、あまり容量の心配をする必要はありません。

次のシェアードライブラリの依存関係ですが、ルートパーティションにインストールするパッケージは、build_imageでディスクイメージを作成する時にシェアードライブラリの依存関係がチェックされます。このチェックで依存する.soファイルが見つからないとエラーでイメージ作成が失敗してしまいます。

で、このチェックには厄介な問題があります。

シェアードライブラリはプログラムローダーが認識できるようにld.so.confに書かれているパスのいずれかに配置されるのが普通ですが、一部のプログラムではそこにはシンボリックリンクを置いておき、実体をほかの場所に置くことがあります。このシンボリックリンクのリンク先が絶対パス表記になっているとこの依存関係チェックがうまくできずにエラーになってしまうのです。

実はbinutilsのパッケージを/usr/binにインストールしようとするとこの条件に引っかかってエラーになってしまうという問題があります。chromeos-devに依存関係を足して/usr/localにインストールすることは可能ですが、binutilsのパッケージはシンボリックリンクを絶対パスで/usr/binや/usr/libに作るためリンク切れが起きてしまいます。

今回パッケージでインストールするp7zipの場合はどちらでもいいですが、今回はchromeos-devの方に追加してみます。

chromiumos_overlayの方も編集に先立ってrepo startでブランチを作っておく必要があります。
それからchromiumos_overlay/chromeos-base/chromeos-devに移動して、そこにある ebuildファイルに依存関係を追加します。追加するのはRDEPENDという変数です。
(cr) (release-R35-5712.B/my-portage) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch/p7zip $ cd ../../../chromiumos-overlay
(cr) (release-R35-5712.B/(49baa0f...)) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay $ repo start my-overlay .
(cr) (release-R35-5712.B/my-overlay) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay $ cd chromeos-base/chromeos-dev
(cr) (release-R35-5712.B/my-overlay) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay/chromeos-base/chromeos-dev $ ls
chromeos-dev-0.1.0-r94.ebuild  chromeos-dev-0.1.0.ebuild
(cr) (release-R35-5712.B/my-overlay) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay/chromeos-base/chromeos-dev $ vi chromeos-dev-0.1.0-r94.ebuild 

(略)
RDEPEND="${RDEPEND}
    pam? ( app-admin/sudo )
    app-admin/sysstat
    app-arch/gzip
    app-arch/tar
    app-arch/p7zip  ←追加
    profile? (
(略)
 

ここで、chromeosの下には
chromeos-0.1.0-r94.ebuild
chromeos-0.1.0.ebuild
の2つのファイルがあり、前者は後者へのシンボリックリンクになっています。
編集を加えた後は、ビルドシステムが変更を認識できるようにシンボリックのリビジョン番号をカウントアップします。

(cr) (release-R35-5712.B/my-overlay) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay/chromeos-base/chromeos-dev $ mv chromeos-dev-0.1.0-r94.ebuild chromeos-dev-0.1.0-r95.ebuild
 
これでChromium OSに取り込まれるはずなので、build_packagesします。

(cr) (release-R35-5712.B/my-overlay) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay/chromeos-base/chromeos-dev $ cd ../../../../scripts/
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./build_packages --board=${BOARD}
ChromeOS version information:
    CHROME_BRANCH=35
    CHROME_VERSION=
    CHROMEOS_VERSION_STRING=5712.32.2014_04_28_2221
    CHROME_BASE=
INFO    : Elapsed time (run_chroot_version_hooks): 0m0s
(略)
Calculating deps...
Deps calculated in 0m18.5s
[ebuild  N     ] app-arch/p7zip-9.20.1-r4 to /build/x86-generic/ USE="pch -doc -kde -rar -static -wxwidgets" 0 kB
[ebuild     U  ] chromeos-base/chromeos-dev-0.1.0-r95::chromiumos [0.1.0-r94::chromiumos] to /build/x86-generic/ USE="X opengl pam profile usb -cras -tpm" 0 kB

Total: 2 packages (1 upgrade, 1 new), Size of downloads: 0 kB
(略)

Merge complete
Done
Builds complete
INFO    : Elapsed time (build_packages): 1m27s
Done


ビルドがうまくいったようなので、続けてbuild_imageします。

(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./build_image --board=${BOARD} --noenable_rootfs_verification dev
ChromeOS version information:
    CHROME_BRANCH=35
    CHROME_VERSION=
    CHROMEOS_VERSION_STRING=5712.32.2014_04_28_2223
    CHROME_BASE=
(略) 
INFO    : Elapsed time (build_image): 8m21s
To copy the image to a USB key, use:
  ./image_to_usb.sh --from=../build/images/x86-generic/R35-5712.32.2014_04_27_2201-a1
To convert it to a VMWare image, use:
  ./image_to_vm.sh --from=../build/images/x86-generic/R35-5712.32.2014_04_27_2201-a1 --board=x86-generic
 
 

build_packagesでビルドを行うと、各パッケージのバイナリは

/build/${BOARD}/package/パッケージカテゴリ名

の下にtbz2形式で圧縮されて格納されます。この中から必要なものがbuild_imageの実行時に展開されてディスクイメージの中にコピーされるようになっています。

終わったらイメージをマウントして中を確認し、追加したコマンドが含まれているか確認します。作成したビルドイメージのルートパーティションは/tmp/mにマウントされるので、確認する場所は/tmp/m/usr/local/binになります。ここに7*で始まるファイルがあるかチェックします。

(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./mount_gpt_image.sh --board=${BOARD} -f $(./get_latest_image.sh --board=${BOARD})
1+0 レコード入力
1+0 レコード出力
1 バイト (1 B) コピーされました、 0.000261486 秒、 3.8 kB/秒
Setting up symlinks for /usr/local for /tmp/s/dev_image
INFO    : Image specified by /mnt/host/source/src/build/images/x86-generic/R35-5712.32.2014_04_28_2223-a1 mounted at /tmp/m successfully.
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ls /tmp/m/usr/local/bin/7*
/tmp/m/usr/local/bin/7z  /tmp/m/usr/local/bin/7za  /tmp/m/usr/local/bin/7zr
 

うまくできていたようです。確認が終わったらイメージはアンマウントします。

(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./mount_gpt_image.sh --board=${BOARD} -u
INFO    : Unmounting image from /tmp/s and /tmp/m
Cleaning up /usr/local symlinks for /tmp/s/dev_image
 
もしうまく取り込まれないようであれば、/build/${BOARD}/package/Packageファイルを開いて、
CPV: chromeos-base/chromeos-dev-0.1.0-rXX
という文字列を検索します。XXはebuildファイルをリネームしたときに指定したリビジョン番号です。すると以下のような内容が見つかるはずです。

CPV: chromeos-base/chromeos-dev-0.1.0-r95
DEFINED_PHASES: -
DEPEND: app-benchmarks/i7z dev-util/turbostat sys-apps/dmidecode sys-apps/pciutils (略)
 

このDEPEND:の後に取り込まれるパッケージがずらずら書いてありますので、この中に自分が追加したパッケージが確かに含まれていることを確認します。含まれていない場合はどこかにミスがあります。
うまくいかないケースではリビジョンをあげ忘れて前のリビジョンしかヒットしない場合が多いのではないかと思います。

binutilsはパッケージを使ったインストールを避けたほうが良い


binutilsはp7zipと違って~/trunk/src/third_party/portage_stableの下にパッケージが置かれていませんが、chromiumos_overlaysの中にはパッケージが存在しています。
このbinutilsパッケージはChromium OSにインストールするためにあるものではなく、SDKのビルド環境を作成するために存在しています。なので、このbinutilsパッケージに対して細工を加えると正しくChromium OSがビルドできなくなります。

emerge-x86-generic binutils --unmerge

などとしてパッケージを削除してしまうと、ビルドに使うldコマンドが消えてしまってバイナリが作れなくなります。上で書いたcros_portage_upgradeコマンドを実行して更新をかけるのも避けるべきです。

どうしてもbinutilsパッケージをChromium OSのイメージに取り込みたいときは、以下のようにbuiild_imageコマンドで引数にdevではなくtestを指定するするのが簡単です。

./build_image --board=${BOARD} --noenable_rootfs_verification test

こうするとビルド環境で使われているbinutilsパッケージがChromium OSに取り込まれます。ただ、この方法ではchromiumos-overlay/chromeos-base/chromeos-testというパッケージに書かれているすべてのパッケージがChromium OSに取り込まれます。いろいろ有益なツールもあるのでこれでもいいかと思います。
この方法で追加されるパッケージはchromeos-devに依存関係を追記したときと同じで/usr/local配下にインストールされます。上でも書いたように/usr/local配下にbinutilsをインストールするとシンボリックリンクが壊れるので後で手作業で直さないといけません。 ということで、binutilsについては今のところスマートにインストールする方法はないみたいです。


[関連記事]

[悲報] Chrome R44でffmpegsumoが消えた
Dev serverによるChromium OSのアップデート
最近のChromium OS R35がVAIO Type Pで動かない件への対策
安定版ソースを使ってChromium OSをビルドする
勝手ビルド版Chromium OSとGoogleドライブの連携
Chromium OSをKVMで動かす
勝手ビルド版Chromium OSをVirtualBoxで動くようにする
Chromium OSのカーネルをVAIO Type P向けに再構築する
Chromium OSのビルド環境を作る
Hexxeh版Chromium OSをVAIO Type Pにインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ




ランキングに参加してみました。クリックしていただければ嬉しいです。

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

パソコン ブログランキングへ

拍手[0回]



2014/04/19 (Sat) 20:38
もうそろそろ、来月あたりにはChromium OSのStable ChannelがR34からR35に切り替わるんじゃないかなとおもってR35の最新(release-R35-5712.B)をビルドしてみたのですが、これがVAIO Type Pで動きませんでした。

ブートするとChromiumのロゴが出た後にマシンがリブートしてしまい、OSが立ち上がってくれません。

以前こちらの記事でビルドしたときのChromium OS R35はPlatform versionが5682というものでしたが、今時点では5712に上がっています。おそらく何かが変わったのだろうとおもいログを調べたところ、/var/log/chromeの下に大量にログが出ていました。
そのログはどれも以下のようなメッセージを出力して終わっていました。

[12328:12328:0419/030144:ERROR:gpu_process_transport_factory.cc(436)] Failed to establish GPU channel.
[12328:12328:0419/030144:FATAL:gpu_process_transport_factory.cc(211)] Failed to create UI context, but can't use software compositing with browser threaded compositing. Aborting.
  

落ちているのはカーネルではなくChromiumです。どうやらGPU関係で何かエラーが出ていてGUIが起動できないみたいです。ログが大量に出ているのは何度もリトライしてその都度落ちたからっぽい。
とはいえ、最初のロゴは出ているので、全然グラフィックが使えていないわけではないっぽい。

いままでトラブルは全部カーネルでChromiumのトラブルは初だったので、どこをどう調べたらよいかよくわからなかったのですが、ログを見る限りでは/sbin/session_manage_setup.shからChromiumを起動するタイミングで落ちているっぽいので/sbin/session_manager_setup.shが動いていた時と何か変わってないか比べてみると、以下のような差がありました。

chromium@Ubuntu12:~$ diff -u chromiumos/chroot/build/x86-generic/sbin/session_manager_setup.sh chromiumR35-stable-5712/chroot/build/x86-generic/sbin/session_manager_setup.sh 
--- chromiumos/chroot/build/x86-generic/sbin/session_manager_setup.sh	2014-03-21 07:38:52.000000000 +0900
+++ chromiumR35-stable-5712/chroot/build/x86-generic/sbin/session_manager_setup.sh	2014-04-19 10:36:23.604701439 +0900
@@ -382,11 +382,15 @@
   HANG_DETECTION_FLAG="--enable-hang-detection=5"  # And do it FASTER!
 fi
 
-GPU_FLAGS="--gpu-sandbox-failures-fatal=no"
+GPU_FLAGS="--gpu-sandbox-failures-fatal=yes"
 if use_flag_is_set gpu_sandbox_allow_sysv_shm; then
   GPU_FLAGS="$GPU_FLAGS --gpu-sandbox-allow-sysv-shm"
 fi
 
+if use_flag_is_set gpu_sandbox_start_after_initialization; then
+  GPU_FLAGS="$GPU_FLAGS --gpu-sandbox-start-after-initialization"
+fi
+
 VIDEO_FLAGS=
 if is_board peach_pit || is_board peach_pi; then
   VIDEO_FLAGS="--enable-webrtc-hw-vp8-encoding"


GPU_FLAGSの設定で--gpu-sandbox-failures-fatalがnoだったのがyesに変わっています。ものすごくにおいます。さっそくここをnoに書き換えてブートしてみたらあっさり起動しました。

session_manager_setup.shをビルド時に書き換える方法はこちらの記事で触れていますので参考にしてください。
とりあえず解説なしで手順だけ書き連ねると以下のような感じになります。

(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cros_workon --board=${BOARD} start chromeos-login
INFO    : Started working on 'chromeos-base/chromeos-login' for 'x86-generic'
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd ../platform/login_manager/
(cr) (release-R35-5712.B/(eb046e1...)) chromium@Ubuntu12 ~/trunk/src/platform/login_manager $ repo start my_login_manager .
(cr) (release-R35-5712.B/my_login_manager) chromium@Ubuntu12 ~/trunk/src/platform/login_manager $ vi session_manager_setup.sh 

GPU_FLAGS="--gpu-sandbox-failures-fatal=no ← yesをnoに書き換え

(cr) (release-R35-5712.B/my_login_manager) chromium@Ubuntu12 ~/trunk/src/platform/login_manager $ cd ../../scripts/
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ FEATURES="noclean" cros_workon_make --board=${BOARD} chromeos-login --install
WARNING : Cleaning up stale workdir: /build/x86-generic/tmp/portage/chromeos-base/chromeos-login-9999/work/chromeos-login-9999
(略)
  

上記手順と以前書いたPATAドライバの組み込みを行い、後はbuild_imageスクリプトでイメージを作ればOKです。

なお、この辺の修正については以下のURLでアナウンスされていました。

Re: PSA: Chrome GPU sandbox failures are now fatal

日付を見たら3月25日で、まさに私が以前ビルドに成功した翌日でした。一日遅かったらビルドしたものが動かなかった可能性が高いです。 私の以前の記事を参考にしてビルドしてくださった方がコメントで動かないとおっしゃっていましたが、コメントでいただいた現象から見ても多分この問題だと思います。

あの記事を見て試してみた人がことごとく失敗していたのかもしれないと思うと申し訳ない思いです。

今回調べる気になったのも動いた実績があったからです。もし動いた実績がなく今回の現象が起きていたらVAIO Type Pでは動かないんだとあきらめていたでしょうね。そういう意味では運がよかったなぁと思います。
 
 ※現時点で最新のChromium OSはR36になっていますが、R36はこちらではまだ確認していません。
 
[関連記事]

[悲報] Chrome R44でffmpegsumoが消えた
Dev serverによるChromium OSのアップデート
Chromium OSにパッケージを追加する
安定版ソースを使ってChromium OSをビルドする
勝手ビルド版Chromium OSとGoogleドライブの連携
Chromium OSをKVMで動かす
勝手ビルド版Chromium OSをVirtualBoxで動くようにする
Chromium OSのカーネルをVAIO Type P向けに再構築する
Chromium OSのビルド環境を作る
Hexxeh版Chromium OSをVAIO Type Pにインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ




ランキングに参加してみました。クリックしていただければ嬉しいです。

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

パソコン ブログランキングへ

拍手[1回]



2014/04/13 (Sun) 23:04
以前の記事でChromium OSのビルド手順について書きましたが、あの手順に従ってビルドした場合、使用されるソースはその時点での最新の開発版ソースになります。

Chromium OSのリリースにはDev Channel(開発中バージョン), Beta Channel(ベータバージョン), Stable Channel(安定版:Chromebookで実際に動いているもの)という3つのチャンネルがあるのですが、あの手順でチェックアウトされるのはDev Channelのものよりもさらに新しい本当に最新のものです。

開発中なので評価が十分に行われたものではなく、リビジョンもガンガン上がっていくようです。前回ビルド環境の記事を書いた時のリビジョンはR35でしたが今日の時点ではR36になっていました。今日時点でのDev ChannelのリビジョンはChrome Releaseの記事によればまだR35のはずです。

で、Google側のリポジトリのリビジョンが上がったあとにこっちでrepo syncしてビルドするとエラーになってビルドできない、という問題が起きました。setup_boardスクリプトを起動して再度ビルドをかけたらエラーはなくなったようですが、自分で入れた修正はいつの間にか消えていました。
スナップショットを使って簡単に復旧できたのでこのあたりのことはまだよく調べていません。単にどこかでオペミスがあっただけかもしれません。

こちらはChromium OSの開発に参加しているわけではなく(そんなスキルないです)、単に自分で使いたいからビルドしているだけなので、あまり頻繁にリビジョンが上がってそのたびにビルドできなくなるようなトラブルが起きるとついていけなくなってしまいます。それに、どうせ使うなら十分に評価されている安定版のソースコードを使ってビルドしたほうがいいかな、と思うわけです。

あと、安定版ソースを使うと、品質面だけでなく後でFlashやPDFなどのプラグインを仕込む際にも成功する確率が高くなるだろうと予想しています。
というのも、いろいろなサイトでプラグインの組み込み方法の記事を見てみると、これらのプラグインをChromium OSに仕込む際はGoogleのサイトからダウンロードできるChromeブラウザからプラグインを抜き出して仕込む、という方法になるようです。安定版ソースは今出回っているChromeブラウザとバージョンが一致しているので、この辺でも失敗しにくいだろうと予想しています。

ということで、今回は今時点のStable Channelと同じバージョンのソースコードを使ってChromium OSをビルドしてみます。
今回の記事は公式サイトの"Working on a Branch"を参考にしていますので、正確な内容が知りたい方はそちらを見てみることをお勧めします。

安定版のバージョン番号の調べ方


安定版ソースでビルドしようと思ったら当然安定版のバージョンがわかっていないといけません。Chromebookを持っていればそこで見ればわかるんでしょうが、持っていないので別の方法で調べる必要があります。

Chromium OSなどのプロダクトのリリース通知は上にもちょっと書きましたがGoogleの"Chrome Release"というブログにリリースがあるたびに掲載されています。なのでここにアクセスして"Stable Channel Update for Chrome OS"というタイトルの記事を探してそこに書いてあるバージョンを見ればOKです。今日時点で最新のStable Channel Updateは4/8にあったようで、その時の記事には以下のように書いてあります。

The Stable channel has been updated to 34.0.1847.118 (Platform version: 5500.100.0) for all ChromeOS devices.

このバージョン番号、特にPlatform versionの後の5500.100という数字を覚えておきます。

チェックアウトするブランチの名前を調べる


続いて、ビルドに使うソースをどこから引っ張ってくるかを調べる必要があります。
Chromium OSのソースのブランチ名一覧は以下のURLで確認することができます。

https://chromium.googlesource.com/chromiumos/manifest/+refs

ここで一覧をずっと見ていくとstabilize-で始まるものがあるので、上で調べたPlatform versionのものを探します。今回の例ならstabilize-5500.100.Bというものがあります。これが安定版ソースのブランチの名前になります。
他にrelease-R34-5500.Bというブランチもありますがこれは安定版より若干新しめのソースが入っているようです。こちらを使ってもあまり差はないとは思います。

安定版ソースのチェックアウトとビルド


安定版ソースを使ったビルドの方法は基本的には以前書いた記事と全く同じです。ただ、ソースをチェックアウトする際、repo initに-bオプションで上で調べたリポジトリ名を指定します。具体的な指定方法は以下の通りです。

$ repo init -u https://chromium.googlesource.com/chromiumos/manifest.git --repo-url https://chromium.googlesource.com/external/repo.git -b stabilize-5500.100.B
  

なお、すでに別のブランチからチェックアウトした環境がある場合は、それとは別にディレクトリを作って、その下でrepo init以降の手順を行う必要があります。 これ以外は以前書いた記事と同じなので割愛します。

とりあえずこの方法でビルドしたものをKVM上で動かしてみたもののスクリーンショットを載せます。

バージョン番号を見るとChrome Releaseの記事では34.0.1847.118 、実際にビルドできたのは34.0.1847.120と微妙に違っていますが、ほぼ同じものになっているようです。

あと、このバージョンをVAIO Type Pで動かしてみました。まだカーネルの再構築はしていないのでUSBからブートしただけですが、以前ビルドしたものと比べてキーボード入力のレスポンスがよくなっており、違和感なく操作できます。
時間ができたら再構築してVAIOのChromium OSを入れ替えるつもりです。

[4/14追記]
今回ビルドしたstabilize-5500.100などのR34系はVAIO Type Pで動かすとPATAの問題のほかにシャットダウンしても電源が切れずにリブートする、スリープ時にスリープせずシャットダウンしてしまうといった問題があるようです。
ちょっと調べてみましたが原因はわかりませんでした。R34はカーネルのバージョンが3.4と古いため、このあたりの対応がまだ不十分なのかもしれません。R35はカーネルバージョンが3.10であり、このあたりの対策ができているようです。残念ですがR35に戻そうと思います。
もうしばらく待てばR35が安定版になるだろうから、そうなれば今よりは安心して使えるようになるのかな。
 
  
  
  
[関連記事]

[悲報] Chrome R44でffmpegsumoが消えた
Dev serverによるChromium OSのアップデート
Chromium OSにパッケージを追加する
最近のChromium OS R35がVAIO Type Pで動かない件への対策
勝手ビルド版Chromium OSとGoogleドライブの連携
Chromium OSをKVMで動かす
勝手ビルド版Chromium OSをVirtualBoxで動くようにする
Chromium OSのカーネルをVAIO Type P向けに再構築する
Chromium OSのビルド環境を作る
Hexxeh版Chromium OSをVAIO Type Pにインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ




ランキングに参加してみました。クリックしていただければ嬉しいです。

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

パソコン ブログランキングへ

拍手[0回]



    5  6  7  8  9  10  11  12  13  14  15 
プロフィール
HN:
zui
性別:
非公開
PR
忍者カウンター
忍者ブログ [PR]