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はChromium OSのSDKの一部ですので、起動するにはChromium OSのSDKが必要です。また、一度は自分でChromium OSのビルドを行っていることが必要です。Chromium OSのビルドの手順はこちらの記事にまとめていますので参考にしていただければと思います。
ビルド環境があるならDev serverの起動は非常に簡単です。cros_sdkでchroot環境を立ち上げてstart_devserverコマンドを実行するだけです。
Dev serverはデフォルトではビルドマシンのTCPポート8080を使用します。変更する場合は--portオプションで変更できます。
Dev serverの標準出力にはログがどんどん出力されますので、Chromium OSの実機から接続があればすぐにわかります。
Chromium OSインストールマシン側でDev serverに接続しに行くための設定は/etc/lsb-releaseというファイルに記述されています。このファイルの下２行に以下のような記述があります。
このdevserverのアドレスには、ビルド環境上でhostname -fを実行して得られる値がChromium OSのビルド時に自動で格納されています。なので、DNSの設定をきちんと行っているなどでChromium OSの実機からビルドマシンのホスト名がきちんと認識できているなら、何も設定しなくてもビルドマシン上でDev serverを起動すればすぐ使えるようになります。
うちはその辺の設定は手を抜いているので、該当箇所をIPアドレスに書き換えて認識させましたｗｗ
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でターミナルを開き、以下のコマンドを実行します。
このコマンドを実行すると、--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パーティションに入れるようにすれば更新時に消えないようにできるかもしれませんが、そもそもこれでちゃんと動くかどうかはまだ試してはいません。
個人で使うだけならビルド時にプラグインを含めてイメージを作っちゃうのが一番楽かもしれませんが、これもまだ試してはいません。
上記の方法で更新されるのはROOTパーティションのみです。/usr/localなどが置かれているSTATEパーティションを更新する場合は、ターミナルからstateful_updateというコマンドを実行する必要があるということです。が、
404エラーが出てしまいました。stateful_updateは
http://devserver_host:8080/static/stateful.tgz
というファイルをダウンロードしに行くようですが、devserverのstatic配下にはstateful.tgzがありません。
Dev server上のstaticディレクトリは、ビルドマシンのchroot環境では/usr/lib/devserver/staticにあたります。この下を見ると以下のようになっています。
ビルドイメージはこのディレクトリのx86-genericの下にシンボリックリンクの形で準備されます。
stateful.tgzはこのバージョン名のシンボリックリンクの下に作られています。
なので、以下のようにstaticディレクトリ配下に最新ビルドのstateful.tgzへのシンボリックリンクを作ります。
この状態で実機上でstateful_updateを実行してみます。
今度はうまくいきました。公式サイトの解説ページにはこんな作業が必要とは書いてありません。なんでこうなってしまうのかはよくわかっていません。
なお、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を使うと、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配下の一部のパッケージをインストールしようとすると以下のようなエラーが出ることがあります。
このエラーが出たときは--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メモリからブートするときのメモ
今回は公式サイト"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というファイルに記述されています。このファイルの下２行に以下のような記述があります。
CHROMEOS_AUSERVER=http://devserverのアドレス:ポート番号/update CHROMEOS_DEVSERVER=http://devserverのアドレス:ポート番号/
このdevserverのアドレスには、ビルド環境上でhostname -fを実行して得られる値がChromium OSのビルド時に自動で格納されています。なので、DNSの設定をきちんと行っているなどでChromium OSの実機からビルドマシンのホスト名がきちんと認識できているなら、何も設定しなくてもビルドマシン上でDev serverを起動すればすぐ使えるようになります。
うちはその辺の設定は手を抜いているので、該当箇所をIPアドレスに書き換えて認識させましたｗｗ
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メモリからブートするときのメモ
ランキングに参加してみました。クリックしていただければ嬉しいです。
 にほんブログ村 |
 パソコン ブログランキングへ |
[0回]
PR
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のプラグインを抜き出してインストールすることができるようになります。
・・・まあ、スクリプトが公開されているんでそれ使ったほうが早いですがｗ
Flashの話はとりあえず今回はおいておいてパッケージの追加の話だけ書きます。
組み込む方法といっても方法はいくつか考えられます。
一番手っ取り早いのは普通にソースをダウンロードしてきてconfigureしてmakeする、という方法です。
もう一つはChromium OSのSDKにパッケージを追加してSDKの流儀で組み込む方法です。
このほかにDev Serverを使う方法があります。Dev serverについてはこちらの記事でまとめています。
今回はbinutilsを最初の方法、p7zipを２番目の方法でインストールしていきます。ただ、前者の方法は軽く触れるだけにして、後者をメインに書いていきます。
なお、今回も既にChromium OSのビルド環境が手元にあることを前提にして書いていきます。ビルド環境の構築方法はこちらの記事で書いています。
また、パッケージの追加・置換は手順を間違えると最悪ビルド環境が壊れてしまうので、バックアップやVMを使っているならスナップショットの作成を行って作業前に戻せるようにしておくことをお勧めします。
実は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用のコンパイラである
が使われるように設定します。
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 OSインストールマシンからscpなどでarをコピーし、/usr/local/binにコピーすればOKです。
今回の内容は本家サイト"The Chromium Project"以下の各ページを参考にしています。
Chromium OSの情報源は英語ばかりなのでまた間違って理解している可能性があります。詳しいことはこれらの本家サイトをご覧ください。
Chromium OSのパッケージシステムはGentoo Linuxというディストリビューションで使われているPortageというものです。Portageでは各ソフトのダウンロード・ビルド方法を拡張子がebuildのファイルに書いておき、これを実行することでソフトウェアのインストールを行います。debやrpmと違ってバイナリパッケージではなく、基本的にはソースアーカイブをネット経由でダウンロードしてから逐次ビルドするところに特徴があります（バイナリパッケージもあるようですが）。
Chromium OSのSDKでは、このebuildファイルが置かれている場所が大きく分けて以下の２つあります。
~/trunk/src/third_party/chromiumos_overlay
~/trunk/src/third_party/portage_stable
前者はChromium OSの中核をなすパッケージや、Chromium OSに取り込むにあたってカスタマイズが施されているようなソフトのパッケージが置かれているようです。なので、ここにパッケージがあるときは下手に置き換えないほうが得策です。
こっちにおいてあるパッケージでChromium OSに取り込まれていないものはあまり多くないと思いますが、binutilsはこちらにパッケージがあるけどデフォルトではChromium OSに取り込まれないものの１つです。
これに対して、一般に配布されているオープンソースソフトウェアをそのまま取り込むようなケースではportage_stableにあるパッケージが使われます。ここにはGentoo Linuxのパッケージツリーからそのまま持ってきただけと思われるものが多数置いてありますが、必ずしも最新のパッケージになっているというわけではありません。
また、portage_stableには、実際にはChromium OSのイメージに取り込まれないようなパッケージもいくつかおいてあったりします。今回扱うものでは、p7zipがこちらに当てはまります。
上記２つのディレクトリの下には、ソフトウェアのカテゴリを表すサブディレクトリがたくさん作られています。これらのカテゴリを表すサブディレクトリのさらに下に各ソフトウェアのディレクトリが作られ、その中に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配下の現状を見るとこのようになっています。
p7zipのほうは既にパッケージが存在していますが、バージョンが9.13とちょっと古いようです（記事作成時点では9.20が最新）。現状Chromium OSにはp7zipは含まれていませんので使われていないにも関わらずパッケージだけは置いてあるようです。
binutilsのほうはパッケージがありません。
一方、chromiumos-overlayのほうは結論だけ書きますが、p7zipについてはp7zip自体も、その上位カテゴリのapp-archもありません。それに対してbinutilsのほうはsys-develカテゴリの中にパッケージが存在しています。
これらをふまえてパッケージの追加を行っていきます。
p7zipは既にパッケージが存在していますが、バージョンが古いです。この古いバージョンでビルドを試みましたがコンパイルエラーになりました。
p7zipはchromiumos-overlaysのほうにパッケージがないので、思い切ってバージョンをあげてしまいます。
Chromium OS SDKにはパッケージの更新を行うための専用のコマンドが用意されているので、そのコマンドで更新をかけます。
一応、Chromium SDKを起動するところから手順を書いてきます。
今回は~/trank/src/third_party/portage_stableで作業をするので、ここにブランチを作ります。
続けてcros_portage_upgradeというコマンドを実行します。これが上流サイトから最新のパッケージをダウンロードして置き換えるためのコマンドです。
黄色い文字で警告が表示されます。これは、--boardオプションでx86-genericだけを指定したためです。--boardオプションは:で区切って複数のアーキテクチャを指定できますが、私が使っている環境がx86しかセットアップしていないので１つだけ指定しています。 この警告ではパッケージの置換は他のアーキテクチャにも影響を与えるため、１つだけ指定すると他のアーキテクチャでビルドできなくなるかもしれないよ、というようなことを言っているようです。ここはとりあえずyesを入力して先に進みます。
冒頭に
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コマンドを直接使うことは基本的にはありません。
うまくコンパイルできたようです。
ちなみにパッケージそのものにはソースコードは含まれておらず、ビルド時にリモートからダウンロードするようになっています。ダウンロードしたソースコードは
/build/${BOARD}/tmp/portage/の下に置かれます。
ここまででp7zipのパッケージをコンパイルしましたが、これだけではChromium OSにビルド結果が取り込まれません。取り込まれるようにするためには、~/trunk/src/third_party/chromiumos_overlay/chromeos-baseの下にある以下のいずれかのパッケージのebuildファイルを編集して、追加するパッケージ名を依存関係の一覧に追記する必要があります。
前者に追加した場合、バイナリはChromium OSの/usr/binや/usr/libにインストールされます。後者に追加した場合は/usr/local配下にバイナリが置かれます。
特段の必要がなければ基本的にはchromeos-devのほうにパッケージを追加したほうが簡単です。
chromeosのほうに追加する場合は、以下の２点に気を使う必要があります。
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という変数です。
ここで、chromeosの下には
chromeos-0.1.0-r94.ebuild
chromeos-0.1.0.ebuild
の２つのファイルがあり、前者は後者へのシンボリックリンクになっています。
編集を加えた後は、ビルドシステムが変更を認識できるようにシンボリックのリビジョン番号をカウントアップします。
ビルドがうまくいったようなので、続けてbuild_imageします。
build_packagesでビルドを行うと、各パッケージのバイナリは
/build/${BOARD}/package/パッケージカテゴリ名
の下にtbz2形式で圧縮されて格納されます。この中から必要なものがbuild_imageの実行時に展開されてディスクイメージの中にコピーされるようになっています。
終わったらイメージをマウントして中を確認し、追加したコマンドが含まれているか確認します。作成したビルドイメージのルートパーティションは/tmp/mにマウントされるので、確認する場所は/tmp/m/usr/local/binになります。ここに7*で始まるファイルがあるかチェックします。
うまくできていたようです。確認が終わったらイメージはアンマウントします。
CPV: chromeos-base/chromeos-dev-0.1.0-rXX
という文字列を検索します。XXはebuildファイルをリネームしたときに指定したリビジョン番号です。すると以下のような内容が見つかるはずです。
このDEPEND:の後に取り込まれるパッケージがずらずら書いてありますので、この中に自分が追加したパッケージが確かに含まれていることを確認します。含まれていない場合はどこかにミスがあります。
うまくいかないケースではリビジョンをあげ忘れて前のリビジョンしかヒットしない場合が多いのではないかと思います。
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メモリからブートするときのメモ
今回追加するのはgnu binutilsとp7zipです。
binutilsに含まれているarコマンドとp7zipに含まれる7zコマンドがChromium OSに入っているとUbuntuなどのDebian系で使われているパッケージ形式であるdebファイルをChromium OS上で直接展開できるようになります。
これができるようになると、Chromeブラウザの最新版をgoogleから直接Chromium OS上にダウンロードして、そこからFlashとPDFのプラグインを抜き出してインストールすることができるようになります。
・・・まあ、スクリプトが公開されているんでそれ使ったほうが早いですがｗ
Flashの話はとりあえず今回はおいておいてパッケージの追加の話だけ書きます。
組み込む方法といっても方法はいくつか考えられます。
一番手っ取り早いのは普通にソースをダウンロードしてきてconfigureしてmakeする、という方法です。
もう一つはChromium OSのSDKにパッケージを追加してSDKの流儀で組み込む方法です。
このほかにDev Serverを使う方法があります。Dev serverについてはこちらの記事でまとめています。
今回はbinutilsを最初の方法、p7zipを２番目の方法でインストールしていきます。ただ、前者の方法は軽く触れるだけにして、後者をメインに書いていきます。
なお、今回も既に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ファイルが置かれている場所が大きく分けて以下の２つあります。
~/trunk/src/third_party/chromiumos_overlay
~/trunk/src/third_party/portage_stable
前者はChromium OSの中核をなすパッケージや、Chromium OSに取り込むにあたってカスタマイズが施されているようなソフトのパッケージが置かれているようです。なので、ここにパッケージがあるときは下手に置き換えないほうが得策です。
こっちにおいてあるパッケージでChromium OSに取り込まれていないものはあまり多くないと思いますが、binutilsはこちらにパッケージがあるけどデフォルトではChromium OSに取り込まれないものの１つです。
これに対して、一般に配布されているオープンソースソフトウェアをそのまま取り込むようなケースではportage_stableにあるパッケージが使われます。ここにはGentoo Linuxのパッケージツリーからそのまま持ってきただけと思われるものが多数置いてありますが、必ずしも最新のパッケージになっているというわけではありません。
また、portage_stableには、実際にはChromium OSのイメージに取り込まれないようなパッケージもいくつかおいてあったりします。今回扱うものでは、p7zipがこちらに当てはまります。
上記２つのディレクトリの下には、ソフトウェアのカテゴリを表すサブディレクトリがたくさん作られています。これらのカテゴリを表すサブディレクトリのさらに下に各ソフトウェアのディレクトリが作られ、その中に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しかセットアップしていないので１つだけ指定しています。 この警告ではパッケージの置換は他のアーキテクチャにも影響を与えるため、１つだけ指定すると他のアーキテクチャでビルドできなくなるかもしれないよ、というようなことを言っているようです。ここはとりあえず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のほうに追加する場合は、以下の２点に気を使う必要があります。
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
の２つのファイルがあり、前者は後者へのシンボリックリンクになっています。
編集を加えた後は、ビルドシステムが変更を認識できるようにシンボリックのリビジョン番号をカウントアップします。
(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メモリからブートするときのメモ
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
[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の下に大量にログが出ていました。
そのログはどれも以下のようなメッセージを出力して終わっていました。
落ちているのはカーネルではなくChromiumです。どうやらGPU関係で何かエラーが出ていてGUIが起動できないみたいです。ログが大量に出ているのは何度もリトライしてその都度落ちたからっぽい。
とはいえ、最初のロゴは出ているので、全然グラフィックが使えていないわけではないっぽい。
いままでトラブルは全部カーネルでChromiumのトラブルは初だったので、どこをどう調べたらよいかよくわからなかったのですが、ログを見る限りでは/sbin/session_manage_setup.shからChromiumを起動するタイミングで落ちているっぽいので/sbin/session_manager_setup.shが動いていた時と何か変わってないか比べてみると、以下のような差がありました。
GPU_FLAGSの設定で--gpu-sandbox-failures-fatalがnoだったのがyesに変わっています。ものすごくにおいます。さっそくここをnoに書き換えてブートしてみたらあっさり起動しました。
session_manager_setup.shをビルド時に書き換える方法はこちらの記事で触れていますので参考にしてください。
とりあえず解説なしで手順だけ書き連ねると以下のような感じになります。
上記手順と以前書いた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メモリからブートするときのメモ
ブートすると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メモリからブートするときのメモ
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
[1回]
2014/04/13 (Sun) 23:04
以前の記事でChromium OSのビルド手順について書きましたが、あの手順に従ってビルドした場合、使用されるソースはその時点での最新の開発版ソースになります。
Chromium OSのリリースにはDev Channel（開発中バージョン）, Beta Channel（ベータバージョン）, Stable Channel（安定版：Chromebookで実際に動いているもの）という３つのチャンネルがあるのですが、あの手順でチェックアウトされるのは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以降の手順を行う必要があります。 これ以外は以前書いた記事と同じなので割愛します。
とりあえずこの方法でビルドしたものを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メモリからブートするときのメモ
Chromium OSのリリースにはDev Channel（開発中バージョン）, Beta Channel（ベータバージョン）, Stable Channel（安定版：Chromebookで実際に動いているもの）という３つのチャンネルがあるのですが、あの手順でチェックアウトされるのは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メモリからブートするときのメモ
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
[0回]
2014/04/12 (Sat) 16:25
# '15.03.24 一部古い記述を修正しました。
以前の記事でChromium OSのビルド方法を書きましたが、この方法だとFilesアプリを起動したときにローカルのダウンロードフォルダは見えるのにGoogleドライブのほうは開いてみても中身が全然見えない、という問題がありました。
これはFilesアプリがGoogleドライブにアクセスする際にGoogleのAPIを使用しており、APIにアクセスするための認証キーが存在しないためにアクセス権エラーになっているのが原因でした。
エラーの内容は、Chromiumブラウザを起動してchrome://drive-internalsにアクセスするとみることができます。
赤字でHTTP_FORBIDDENというエラーがたくさん出ています。これが認証キーがないために起きるエラーです。
Chromium(OSに限らない？)のAPI Keyに関する情報の詳細は以下の公式サイトのページに書いてあります。
API Keys (http://www.chromium.org/developers/how-tos/api-keys)
これによると直し方は２つあって、ビルド時にAPIキーを埋め込んでしまう方法とインストール後にAPIキーをファイルに書き込む方法があります。
今回は後者の方法を使って対策します。あと、対策するのはFilesアプリのGoogleドライブ連携だけです。ほかはまた問題が見えたら対策しようと思います。
上に書いたAPI Keysの解説ページにはGoogle GroupのChromium-devに参加しないと使えないAPIがある、という記述があります。
ただ、Googleドライブと連携するためのAPIはChromium-devに参加しなくても使えますので、面倒ならここは飛ばしても構わないと思います。
とりあえず今回は上の記事に従ってChromium-devに参加してみます。
まずhttps://groups.google.com/a/chromium.org/forum/?fromgroups#!forum/chromium-devにアクセスします。以下のように表示されるので「投稿するには～」の青いボタンをクリックします。
「Chromium-dev」グループに参加という画面が出るので「このグループに参加」をクリックします。メールを受け取るのが嫌なら真ん中の「新しいメッセージごとに～」のコンボボックスを「更新情報をメールで受け取らない」に変更しておきます。
これでChromium-devへ参加できました。続けてAPIの有効化を行います。
Google APIを使えるようにするには、Google Developers Consoleというページにアクセスして、使いたいAPIを有効化し、かつAPIにアクセスするための認証キーを発行してもらう必要があります。今回作業する範囲ならGoogleアカウントさえあれば、費用は掛かりません。
まずhttps://cloud.google.com/consoleにアクセスします。以下のようなページが表示されるので赤い「CREATE PROJECT」ボタンをクリックします。
※IE9ではうまくアクセスできませんでした。FirefoxやChromeを使うのがお勧めです。
New Projectという画面が表示されるので、適当な名前を入力し、２つめのI have read and agree to all Terms of Service for ～をチェックして Createをクリックします。
しばらく待つとプロジェクトが作られるので、左側のメニューからAPI & authをクリックします。APIの一覧が表示されるので「Drive API」を探して右側の「OFF」ボタンをクリックして「ON」に変えます。
ちなみに、上に書いたAPI Keysのページには、有効にしておくといいAPIとして以下のものがあげられています。（逆に肝心のDrive APIのことは書いてありません。それでちょっとはまりました）
赤字で示したものはChromium-devグループに参加していないと使えないAPIです。必要に応じて有効にしておくといいと思います。
ちなみにChrome Remote Desktop APIを有効化しなくてもChromium OS上でリモートデスクトップは使用できました。このAPIがどこで役立ってくるのかはよくわかっていません。
続けてAPI Keyを発行します。
ここまででAPIの有効化ができましたが、このAPIをChromium OSから使えるようにするためにはAPI Keyを入手しておく必要があります。API Keyの入手もGoogle Developer Console上で続けて行います。
API Keyと一口に言っても、実際には以下の３つがあります。
この３つをすべて入手する必要があります。
まず左のメニューのAPI & Authの下にあるCredentialsをクリックし、OAuthの下の赤いCREATE NEW CLIENT IDをクリックします。
Create Client IDという画面が出るので、Application typeをInstalled application、 Installed application typeをOtherにしてCreate Client IDという青いボタンをクリックします。
画面右側に"Client ID for native applicationという枠が表示されます。ここのClient IDとClient secret（赤丸で囲んだもの）をあとで使います。
続けて、下のCreate New Keyという赤いボタン（青丸で囲んだもの）をクリックします。
Create a new keyという画面が出るので、左から2番目のBrowser keyボタンをクリックします。
Create a browser key wnd configure allowed referersという画面が出るのでそのままCreateという青いボタンをクリックします。
Key for browser applicationsという枠が新たに表示されます。ここのAPI Keyをあとで使います。
これで必要な３つのキーがそろいましたので、Chromium OS上でAPI Keyの設定を行います。
上のAPI Keyのページでは、入手したAPI KEYを環境変数に設定するようにと書いてありますが、実際の設定場所が書いていません。単にchronosユーザの~/.bashrcに書いてもうまくいきません。設定先は/etc/chrome_dev.confというChromiumブラウザの設定ファイルに行います。
まず、Chromium OSを起動してCtrl+Alt+F2を押してターミナルを開き、ユーザchronosでログインします。パスワードは使っているChromium OSのビルド時に設定した値ですのでまちまちです。ArnoldThaBat版を使っているなら"password"です。
/etc/chrome_dev.confはルートパーティションにあります。Chromium OSはルートパーティションをリードオンリーでマウントしますので、リードライトでマウントしなおします。
ルートパーティションをリマウントしたらchrome_dev.confを編集して、上で取得したClient ID, Client Secret, API Keyを書き込みます。
とりあえずこれで作業は終わりです。この後リブートするのですが、GUI側でログインしている場合はCtrl+Alt+F1を押してGUIに戻ってGUIセッションからログアウトしてください。ログアウトせずに再起動すると再起動後にエラーが出ることがあります。
それからChromium OSを再起動すればGoogleドライブの内容にアクセスできるはずです。
Googleドライブの内容が見えるようになりました。最初に見たchrome://drive-internalsを見てみても赤字のエラーは消えています。
なお、Chromium OSのメジャーなビルドの１つであるArnoldTheBat版もAPI Keyが埋め込まれていないため、今回記事にした方法でAPI Keyを有効にする必要があるようです。
ちなみにHexxeh版はこの作業を行わなくてもGoogleドライブにアクセスできます。おそらくビルド時にAPIキーを埋め込んであるんだと思いますが、上にURLをのせた公式サイトのAPI Keyのページには
Note that the keys you have now acquired are not for distribution purposes and must not be shared with other users.
とあるんですよね。distribution OKなAPIキーをどこかで入手したんでしょうか。それともChromium-devに参加しなくても使えるAPIなら公開してもいいのかな？
このあたりはまだよくわかっていません。
'15.5.15 追記：同じような質問がこちらにありました。
回答を引用すると
"not for distribution purposes" refers to the keys themselves, not the binaries that you build that use those keys,
だそうです。Keyそのものを公開しなければ、Keyを組み込んだバイナリを配っても別に問題はないみたいですね。
ただ、GoogleのAPIにはAPI Key単位でQuota（単位時間当たりのAPIアクセス回数）が決められていて、Quotaを超えるAPIアクセスは全部エラーで跳ねられます。ビルド時にAPI Keyを埋め込んでしまうと、そのビルドを使っているユーザ全員がそのQuotaに縛られるので、ある時突然Googleドライブにアクセスできなくなる可能性があります。そういう意味では自分で専用にAPI Keyを取っておいたほうが安心かなとも思います。
［関連記事］
[悲報] Chrome R44でffmpegsumoが消えた
Dev serverによるChromium OSのアップデート
Chromium OSにパッケージを追加する
最近のChromium OS R35がVAIO Type Pで動かない件への対策
安定版ソースを使ってChromium OSをビルドする
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メモリからブートするときのメモ
以前の記事でChromium OSのビルド方法を書きましたが、この方法だとFilesアプリを起動したときにローカルのダウンロードフォルダは見えるのにGoogleドライブのほうは開いてみても中身が全然見えない、という問題がありました。
これはFilesアプリがGoogleドライブにアクセスする際にGoogleのAPIを使用しており、APIにアクセスするための認証キーが存在しないためにアクセス権エラーになっているのが原因でした。
エラーの内容は、Chromiumブラウザを起動してchrome://drive-internalsにアクセスするとみることができます。
赤字でHTTP_FORBIDDENというエラーがたくさん出ています。これが認証キーがないために起きるエラーです。
Chromium(OSに限らない？)のAPI Keyに関する情報の詳細は以下の公式サイトのページに書いてあります。
API Keys (http://www.chromium.org/developers/how-tos/api-keys)
これによると直し方は２つあって、ビルド時にAPIキーを埋め込んでしまう方法とインストール後にAPIキーをファイルに書き込む方法があります。
今回は後者の方法を使って対策します。あと、対策するのはFilesアプリのGoogleドライブ連携だけです。ほかはまた問題が見えたら対策しようと思います。
Chromium-dev グループへの参加
上に書いたAPI Keysの解説ページにはGoogle GroupのChromium-devに参加しないと使えないAPIがある、という記述があります。
ただ、Googleドライブと連携するためのAPIはChromium-devに参加しなくても使えますので、面倒ならここは飛ばしても構わないと思います。
とりあえず今回は上の記事に従ってChromium-devに参加してみます。
まずhttps://groups.google.com/a/chromium.org/forum/?fromgroups#!forum/chromium-devにアクセスします。以下のように表示されるので「投稿するには～」の青いボタンをクリックします。
「Chromium-dev」グループに参加という画面が出るので「このグループに参加」をクリックします。メールを受け取るのが嫌なら真ん中の「新しいメッセージごとに～」のコンボボックスを「更新情報をメールで受け取らない」に変更しておきます。
これでChromium-devへ参加できました。続けてAPIの有効化を行います。
Google API の有効化
Google APIを使えるようにするには、Google Developers Consoleというページにアクセスして、使いたいAPIを有効化し、かつAPIにアクセスするための認証キーを発行してもらう必要があります。今回作業する範囲ならGoogleアカウントさえあれば、費用は掛かりません。
まずhttps://cloud.google.com/consoleにアクセスします。以下のようなページが表示されるので赤い「CREATE PROJECT」ボタンをクリックします。
※IE9ではうまくアクセスできませんでした。FirefoxやChromeを使うのがお勧めです。
New Projectという画面が表示されるので、適当な名前を入力し、２つめのI have read and agree to all Terms of Service for ～をチェックして Createをクリックします。
しばらく待つとプロジェクトが作られるので、左側のメニューからAPI & authをクリックします。APIの一覧が表示されるので「Drive API」を探して右側の「OFF」ボタンをクリックして「ON」に変えます。
ちなみに、上に書いたAPI Keysのページには、有効にしておくといいAPIとして以下のものがあげられています。（逆に肝心のDrive APIのことは書いてありません。それでちょっとはまりました）
- Google Cloud Messaging for Chrome
- Google Maps Geolocation API
- Time Zone API
- Chrome Remote Desktop API
- Chrome Spelling API
- Chrome Suggest API
- Chrome Sync API
- Chrome Translate Element
- Safe Browsing API
- Speech API
- Google Now For Chrome API
赤字で示したものはChromium-devグループに参加していないと使えないAPIです。必要に応じて有効にしておくといいと思います。
ちなみにChrome Remote Desktop APIを有効化しなくてもChromium OS上でリモートデスクトップは使用できました。このAPIがどこで役立ってくるのかはよくわかっていません。
続けてAPI Keyを発行します。
API Keyの入手
ここまででAPIの有効化ができましたが、このAPIをChromium OSから使えるようにするためにはAPI Keyを入手しておく必要があります。API Keyの入手もGoogle Developer Console上で続けて行います。
API Keyと一口に言っても、実際には以下の３つがあります。
- Client id
- Client Secret
- API Key
この３つをすべて入手する必要があります。
まず左のメニューのAPI & Authの下にあるCredentialsをクリックし、OAuthの下の赤いCREATE NEW CLIENT IDをクリックします。
Create Client IDという画面が出るので、Application typeをInstalled application、 Installed application typeをOtherにしてCreate Client IDという青いボタンをクリックします。
画面右側に"Client ID for native applicationという枠が表示されます。ここのClient IDとClient secret（赤丸で囲んだもの）をあとで使います。
続けて、下のCreate New Keyという赤いボタン（青丸で囲んだもの）をクリックします。
Create a new keyという画面が出るので、左から2番目のBrowser keyボタンをクリックします。
Create a browser key wnd configure allowed referersという画面が出るのでそのままCreateという青いボタンをクリックします。
Key for browser applicationsという枠が新たに表示されます。ここのAPI Keyをあとで使います。
これで必要な３つのキーがそろいましたので、Chromium OS上でAPI Keyの設定を行います。
API Keyの設定
上のAPI Keyのページでは、入手したAPI KEYを環境変数に設定するようにと書いてありますが、実際の設定場所が書いていません。単にchronosユーザの~/.bashrcに書いてもうまくいきません。設定先は/etc/chrome_dev.confというChromiumブラウザの設定ファイルに行います。
まず、Chromium OSを起動してCtrl+Alt+F2を押してターミナルを開き、ユーザchronosでログインします。パスワードは使っているChromium OSのビルド時に設定した値ですのでまちまちです。ArnoldThaBat版を使っているなら"password"です。
/etc/chrome_dev.confはルートパーティションにあります。Chromium OSはルートパーティションをリードオンリーでマウントしますので、リードライトでマウントしなおします。
chronos@localhost / $ sudo mount -o remount,rw /
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
Password:
ルートパーティションをリマウントしたらchrome_dev.confを編集して、上で取得したClient ID, Client Secret, API Keyを書き込みます。
chronos@localhost / $ sudo vi /etc/chrome_dev.conf GOOGLE_DEFAULT_CLIENT_ID=(上で取得したClient ID) GOOGLE_DEFAULT_CLIENT_SECRET=(上で取得したClient Secret) GOOGLE_API_KEY=(上で取得したAPI key) （略）
とりあえずこれで作業は終わりです。この後リブートするのですが、GUI側でログインしている場合はCtrl+Alt+F1を押してGUIに戻ってGUIセッションからログアウトしてください。ログアウトせずに再起動すると再起動後にエラーが出ることがあります。
それからChromium OSを再起動すればGoogleドライブの内容にアクセスできるはずです。
Googleドライブの内容が見えるようになりました。最初に見たchrome://drive-internalsを見てみても赤字のエラーは消えています。
なお、Chromium OSのメジャーなビルドの１つであるArnoldTheBat版もAPI Keyが埋め込まれていないため、今回記事にした方法でAPI Keyを有効にする必要があるようです。
ちなみにHexxeh版はこの作業を行わなくてもGoogleドライブにアクセスできます。おそらくビルド時にAPIキーを埋め込んであるんだと思いますが、上にURLをのせた公式サイトのAPI Keyのページには
Note that the keys you have now acquired are not for distribution purposes and must not be shared with other users.
とあるんですよね。distribution OKなAPIキーをどこかで入手したんでしょうか。それともChromium-devに参加しなくても使えるAPIなら公開してもいいのかな？
このあたりはまだよくわかっていません。
'15.5.15 追記：同じような質問がこちらにありました。
回答を引用すると
"not for distribution purposes" refers to the keys themselves, not the binaries that you build that use those keys,
だそうです。Keyそのものを公開しなければ、Keyを組み込んだバイナリを配っても別に問題はないみたいですね。
ただ、GoogleのAPIにはAPI Key単位でQuota（単位時間当たりのAPIアクセス回数）が決められていて、Quotaを超えるAPIアクセスは全部エラーで跳ねられます。ビルド時にAPI Keyを埋め込んでしまうと、そのビルドを使っているユーザ全員がそのQuotaに縛られるので、ある時突然Googleドライブにアクセスできなくなる可能性があります。そういう意味では自分で専用にAPI Keyを取っておいたほうが安心かなとも思います。
［関連記事］
[悲報] Chrome R44でffmpegsumoが消えた
Dev serverによるChromium OSのアップデート
Chromium OSにパッケージを追加する
最近のChromium OS R35がVAIO Type Pで動かない件への対策
安定版ソースを使ってChromium OSをビルドする
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メモリからブートするときのメモ
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
[0回]
プロフィール
ＨＮ：
zui
性別：
非公開
カテゴリー
最新記事
(09/28)
(09/03)
(08/26)
(07/23)
(05/24)
PR
忍者カウンター