PCメモ Chromium OS

[PR]

2024/04/25 (Thu) 12:33

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

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 -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回]

Chromium OS ｜ Comment(0)

勝手ビルド版Chromium OSとGoogleドライブの連携

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ドライブ連携だけです。ほかはまた問題が見えたら対策しようと思います。

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回]

Chromium OS ｜ Comment(0)

Chromium OSをKVMで動かす

2014/04/06 (Sun) 22:55

以前の記事でChromium OSを強引にVirtualBox上で動かしましたが、そこで書いたように、もともとChromium OSで正式にサポートしている仮想マシン環境はKVM/QEMUです。

今まではCentOS6上でずっとVirtualBoxを使ってきたのですが、この機会にKVMを導入し、その上でChromium OSを動かしてみることにしました。

KVMのインストール

KVMはyumコマンドで普通に導入できます。rootで以下のコマンドを実行します。

# yum groupinstall Virtualization "Virtualization Client" "Virtualization Platform" "Virtualization Tools"

終わったらリブートしておきます。

ブリッジインタフェースの作成

続いてKVMの仮想マシンがネットワークに接続できるようにするためにはネットワークブリッジの設定が必要なようなので、その設定を行います。
/etc/sysconfig/network-scriptsの下にブリッジインタフェースの設定ファイルを作ります。

# cd /etc/sysconfig/network-scripts/
# vi ifcfg-br0
DEVICE=br0
TYPE=Bridge
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=dhcp
DELAY=0

こちらのRHELのカスタマポータルの記事によると、NM_CONTROLLEDにはnoを指定した方がよいようです。また、DELAY=0の設定も追加します。IPアドレスはDHCPを使いたいのでBOOTPROT=dhcpとしています。
合わせてeth0の方の設定も変更します。

# vi ifcfg-eth0

DEVICE=eth0
HWADDR=XX:XX:XX:XX:XX:XX
TYPE=Ethernet
UUID=cc2f2844-a96b-4df0-a9c2-847bcd96ac5b
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=dhcp
BRIDGE=br0

元の定義から変更したのはNM_CONTROLLEDをnoに変えたのと、最後のBRIDGE=br0の行を追加した所だけです。
これでネットワークを再起動します。

# service network restart

ネットワークを再起動したらブリッジインタフェースが有効になっているか確認します。

# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.bc5ff4975979	no		eth0

これでKVMのインストールは完了です。
こちらではVirtualBoxと併用していますが、VirtualBoxを使うときは事前にKVMのサービスであるlibvirtdを落としておく必要があります。逆にKVMを使う場合はVirtualBoxの仮想マシンをすべて電源OFFか保存状態にしてからlibvirtdを起動します。とりあえずこの手順で問題なく併用できました。まあ、併用といっても両方使えるというだけで、さすがに同時起動はムリですねｗ

KVM用Chromium OSイメージの作成

KVMの仮想マシンを作る前に、そこで動かすChromium OSのイメージを作っておかなくてはいけません。Chromium OSのビルドについては以前の記事で書きましたのでそちらを参照してください。そのなかで、VirtualBox用のvdiファイルを作成するコマンドimage_to_vm.shについて書きましたが、KVM用の時は--formatオプションを外して以下のように起動するだけです。

(cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $ ./image_to_vm.sh --board=${BOARD}

これで、イメージで最新のビルドイメージディレクトリ~/trunk/src/build/images/x86-generic/R35-nnnn.0.yyyy_mm_dd_hhmm-a1の下にchromiumos_qemu_image.binというファイルができます。これを適当なところにコピーします。私のビルド環境はVirtualBox上にあるのでscpでホストOSにコピーしました。
なお、最新以外のビルドイメージからKVM用イメージを作りたいときはを使いたいときは、 --fromオプションでビルドイメージがあるディレクトリを指定します。

Chromium OS用仮想マシンの作成

これで準備ができたので、KVM上でChromium OSを動かすための仮想マシンの設定を行います。
アプリケーション－システムツールの下に「仮想マシンマネージャー」ができているので、これを起動します。

一覧に表示されているlocalhost(QEMU)を選択してマウスの右ボタンをクリックして「新規」を選択します。以下のようにダイアログが表示されますので、任意の名前を入れて、「既存のディスクイメージをインポート」を選んで「進む」をクリックします。

続けて、既存のストレージパスを聞かれるので、上で作成したKVM用イメージを選択します。OSはLinux、バージョンはGeneric 2.6.x Kernelを選びました。

続いて以下のようにメモリとCPUの数を聞かれるので、デフォルトのまま次へ進みます。

これでここまでの設定概要が表示されるので、「詳細なオプション」をクリックして、仮想化の種類にkvm、アーキテクチャにi686を選んで完了をクリックします。

これでインストールが行われて以下のように無事起動しました。

とりあえず動きはしましたが、使ってみた感じマウスの動きは自分でビルドしたVirtualBox版の方がスムーズです。KVM版はなんかマウスの動きが飛び飛びというかコマ落ちしているというか、そんな感じです。
まだ使い始めたばかりでよくわかっていないので、もしかすると設定が不十分なのかもしれません。
ただ、確かにカーネルをカスタマイズしなくてもブートします。
以前の記事で最近のChromium OSではXの起動アカウントにrootを使わないようになったと書きましたが、確かにxorgというアカウントで動いています。ビデオドライバもfbdevを使うようで、/dev/fb0が自動で作られていました。

ぶっちゃけ普段使いには微妙な感じですが、カスタマイズしなくても動くと環境と言うのはいじくり回しておかしくなったときのために用意しておいてもいいかな、とは思います。

［関連記事］

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

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

にほんブログ村

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

[0回]

Chromium OS ｜ Comment(0)

勝手ビルド版Chromium OSをVirtualBoxで動くようにする

2014/03/30 (Sun) 18:39

VirtualBoxで動かない原因を調査する。

＃'15.03.28 一部修正しました。
＃'16.02.14 一部修正しました。

前回の記事でも書きましたが、今自分でビルドしているChromiumOSはVirtualBoxやVMwareでは動きません。
Hexxeh版はVirtualBox上でもちゃんと動くのに自分でビルドするとなんでだめなのか、気になったので調べてみました。

なお、自分が使っている仮想環境がVirtualBoxなので、今回はVirtualBoxをターゲットにします。VMWareで動くかどうかは調べていません。

自分でビルドしたものをVirtualBoxで動かすと、初回起動時は「Decompressing Linux...」の画面が出た後勝手にリブートし、再度ブートが始まった後固まります。こんな感じです。

この固まった状態で右Ctrl+F2（実機のCtrl+Alt+F2相当）を押すとターミナルが表示されました。
どうやら完全に固まっているわけではなく、OS自体は起動しているようです。

そこでログインして/var/log/Xorg.0.logを見てみると以下のような表示が出ていました。

[     8.935] (II) Loading extension DRI2
[     8.935] (==) Matched vboxvideo as autoconfigured driver 0
[     8.935] (==) Matched vesa as autoconfigured driver 1
[     8.935] (==) Matched fbdev as autoconfigured driver 2
[     8.935] (==) Assigned the driver to the xf86ConfigLayout
[     8.935] (II) LoadModule: "vboxvideo"
[     8.935] (WW) Warning, couldn't open module vboxvideo
[     8.935] (II) UnloadModule: "vboxvideo"
[     8.935] (II) Unloading vboxvideo
[     8.935] (EE) Failed to load module "vboxvideo" (module does not exist, 0)
[     8.935] (II) LoadModule: "vesa"
[     8.935] (WW) Warning, couldn't open module vesa
[     8.935] (II) UnloadModule: "vesa"
[     8.935] (II) Unloading vesa
[     8.935] (EE) Failed to load module "vesa" (module does not exist, 0)
[     8.936] (II) LoadModule: "fbdev"
[     8.936] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[     8.936] (II) Module fbdev: vendor="X.Org Foundation"
[     8.936] 	compiled for 1.12.4, module version = 0.4.1
[     8.936] 	ABI class: X.Org Video Driver, version 12.1
[     8.936] (II) FBDEV: driver for framebuffer: fbdev
[     8.936] (++) using VT number 1

[     8.943] (II) Loading sub module "fbdevhw"
[     8.943] (II) LoadModule: "fbdevhw"
[     8.943] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[     8.943] (II) Module fbdevhw: vendor="X.Org Foundation"
[     8.943] 	compiled for 1.12.4, module version = 0.0.2
[     8.943] 	ABI class: X.Org Video Driver, version 12.1
[     8.943] (EE) open /dev/fb0: No such file or directory
[     8.943] (WW) Falling back to old probe method for fbdev
[     8.943] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[     8.943] (II) UnloadModule: "fbdev"
[     8.943] (II) UnloadSubModule: "fbdevhw"
[     8.943] (EE) Screen(s) found, but none have a usable configuration.
[     8.943] 
Fatal server error:
[     8.943] no screens found
[     8.943] 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[     8.943] Please also check the log file at "/var/log/xorg/Xorg.0.log" for additional information.
[     8.943] 
[     8.946] Server terminated with error (1). Closing log file.

見たところグラフィック関連のドライバロードに失敗しているようです。最初のvboxvideoはVirtualBoxのGuest Additionsをインストールすると入るドライバですのでロードできないのは仕方ないですが、気になるのは次のvesaのロードに失敗していることです。

ちなみにHexxeh版をVirtualBoxで実行したときのログはこんな感じ。

[     9.150] (II) LoadModule: "vboxvideo"
[     9.150] (WW) Warning, couldn't open module vboxvideo
[     9.150] (II) UnloadModule: "vboxvideo"
[     9.150] (II) Unloading vboxvideo
[     9.150] (EE) Failed to load module "vboxvideo" (module does not exist, 0)
[     9.150] (II) LoadModule: "vesa"
[     9.150] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[     9.151] (II) Module vesa: vendor="X.Org Foundation"
[     9.151] 	compiled for 1.12.4, module version = 2.3.0
[     9.151] 	Module class: X.Org Video Driver
[     9.151] 	ABI class: X.Org Video Driver, version 12.1
[     9.151] (II) LoadModule: "fbdev"
[     9.151] (WW) Warning, couldn't open module fbdev
[     9.151] (II) UnloadModule: "fbdev"
[     9.151] (II) Unloading fbdev
[     9.151] (EE) Failed to load module "fbdev" (module does not exist, 0)
[     9.151] (II) VESA: driver for VESA chipsets: vesa
[     9.151] (++) using VT number 1

[     9.161] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[     9.161] (II) Loading sub module "vbe"
[     9.161] (II) LoadModule: "vbe"
[     9.161] (II) Loading /usr/lib/xorg/modules/libvbe.so
[     9.161] (II) Module vbe: vendor="X.Org Foundation"
[     9.161] 	compiled for 1.12.4, module version = 1.1.0
[     9.161] 	ABI class: X.Org Video Driver, version 12.1
[     9.161] (II) Loading sub module "int10"
[     9.161] (II) LoadModule: "int10"
[     9.161] (II) Loading /usr/lib/xorg/modules/libint10.so
[     9.161] (II) Module int10: vendor="X.Org Foundation"
[     9.161] 	compiled for 1.12.4, module version = 1.0.0
[     9.161] 	ABI class: X.Org Video Driver, version 12.1
[     9.161] (II) VESA(0): initializing int10
[     9.162] (II) VESA(0): Primary V_BIOS segment is: 0xc000
[     9.163] (II) VESA(0): VESA BIOS detected

ちゃんとvesaのロードに成功しています。
ということでこれが原因かなとあたりをつけてさくっと組み込んでみたのですが。。。

[     3.305] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[     3.305] (II) Module vesa: vendor="X.Org Foundation"
[     3.305] 	compiled for 1.12.4, module version = 2.3.0
[     3.305] 	Module class: X.Org Video Driver
[     3.305] 	ABI class: X.Org Video Driver, version 12.1
[     3.305] (II) LoadModule: "fbdev"
[     3.305] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[     3.305] (II) Module fbdev: vendor="X.Org Foundation"
[     3.305] 	compiled for 1.12.4, module version = 0.4.1
[     3.305] 	ABI class: X.Org Video Driver, version 12.1
[     3.305] (II) VESA: driver for VESA chipsets: vesa
[     3.305] (II) FBDEV: driver for framebuffer: fbdev
[     3.305] (++) using VT number 1

[     3.307] (WW) Falling back to old probe method for fbdev
[     3.307] (II) Loading sub module "fbdevhw"
[     3.307] (II) LoadModule: "fbdevhw"
[     3.307] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[     3.307] (II) Module fbdevhw: vendor="X.Org Foundation"
[     3.307] 	compiled for 1.12.4, module version = 0.0.2
[     3.307] 	ABI class: X.Org Video Driver, version 12.1
[     3.307] (EE) open /dev/fb0: No such file or directory
[     3.307] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[     3.307] (II) Loading sub module "vbe"
[     3.307] (II) LoadModule: "vbe"
[     3.307] (II) Loading /usr/lib/xorg/modules/libvbe.so
[     3.307] (II) Module vbe: vendor="X.Org Foundation"
[     3.307] 	compiled for 1.12.4, module version = 1.1.0
[     3.307] 	ABI class: X.Org Video Driver, version 12.1
[     3.307] (II) Loading sub module "int10"
[     3.307] (II) LoadModule: "int10"
[     3.307] (II) Loading /usr/lib/xorg/modules/libint10.so
[     3.307] (II) Module int10: vendor="X.Org Foundation"
[     3.307] 	compiled for 1.12.4, module version = 1.0.0
[     3.307] 	ABI class: X.Org Video Driver, version 12.1
[     3.307] (II) VESA(0): initializing int10
[     3.307] (WW) xf86ReadBIOS: Failed to open /dev/mem (Permission denied)
[     3.307] (EE) VESA(0): Cannot read int vect
[     3.307] (II) UnloadModule: "vesa"
[     3.307] (II) UnloadSubModule: "int10"
[     3.307] (II) Unloading int10
[     3.307] (II) UnloadSubModule: "vbe"
[     3.307] (II) Unloading vbe
[     3.307] (EE) Screen(s) found, but none have a usable configuration.
[     3.307] 
Fatal server error:
[     3.307] no screens found
[     3.307] 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[     3.307] Please also check the log file at "/var/log/xorg/Xorg.0.log" for additional information.
[     3.307] 
[     3.308] Server terminated with error (1). Closing log file.

vesaのモジュールは読み込んだのですが、その先でFaild to open /dev/memとなって落ちてしまいました。hexxeh版はVESA(0):initializing int10の後何の問題もなく動いています。
後気になるのが、自分でビルドしたものにはfbdevドライバが入っているのにHexxeh版にはfbdevドライバが入っていないということ。

これは一体どういうことなのか、といろいろググって見つけたのが以下の記事でした。

use fbdev instead of vesa for X11 driver [chromiumos/overlays/chromiumos-overlay : master]

どうやらセキュリティ向上のためにXorgの動作アカウントがrootになっていたのをやめたようです。そのため、vesaドライバが/dev/memを見に行ったときにPermission deniedで落ちるようになったようです。

この記事が書かれたのは去年の１１月、Hexxeh版がビルドされたのは去年の４月なので、この辺りの事情が当時と今自分でビルドする場合だと変わってくるようです。確かにHexxeh版の/usr/bin/Xの動作アカウントはrootになっています。

root      1077     1  0 20:38 tty1     00:00:03 /usr/bin/X -nohwaccess -noreset -maxvt 2 -nolisten tcp vt1 -auth /var/run/chromelogin.auth -logfile /var/log/xorg/Xorg.0.log

一方自分でビルドしたものはXがすぐ落ちちゃうのでpsには出てきませんが、どうやらxorgというユーザで起動しに行くようです。

記事にはfbdevはroot権限を要求しないのでvesaのかわりにこれを使うようにと書かれています。Hexxeh版でfbdevが組み込まれていないのに、今デフォルトでビルドするとfbdevが組み込まれるのはこういった事情のようです。が、設定がうまくされていないらしく結局Xの起動に失敗するようです。

Chromium OSは仮想環境としてはKVM/QEMUを推奨していてVirutualBoxやVMWareはほとんど無視らしく、このあたりが放置されているようです。でもそれだとWindows上の仮想環境で試したい、という時に手がなくなってしまいますので、やっぱVirtualBoxで動くようにはしておきたい。

ここで、対応案が２つ出てきます。
１つは記事に書かれているようにfbdevを使ってXが立ち上がるようにすること。
もう１つはXをroot起動してvesaを使えるようにすること。

が、前者の方法を調べてみると/dev/fb0を作ったり/etc/xorg.confを書き換えたりといろいろ大変そうです。しかもこの変更は、インストール後に書き換えるのではなくてビルド時にきちんとChromiumOSのパッケージに反映されるようにする必要があります。特にデバイスファイルの追加方法はまだよくわかっていないので大変そうです。

一方、後者の方法は調べたら２か所書き換えるだけでOKでした。なので、怒られそうですが今回はその方法でサクッと対応してしまいます。

＃'15.03.28追記：これはR35の時の記述です。今はソース修正しないとXの起動ユーザを変更できなくなり、到底簡単とは言えない状態になってしまいました。以下ではその手順を追記しています。

※ここから下の内容は前々回および前回の記事で書いたChromium OSのビルド環境構築およびカスタマイズ手順を前提にしています。なので、細かい部分は端折っています。

vesaドライバの組み込み

Chromium OSに組み込むビデオカードドライバの一覧は、ターゲットアーキテクチャ用オーバレイのprofiles/base/make.defaultsに書かれています。なので、make.defaultsにvesaを付け加えるだけです。
# 16.02.14 ：以前はoverlay-x86-generic直下のmake.confで設定しましたが、R45以降上記の場所に変わっています。
手順は以下の通りになります。
まずいつものようにcros_sdkを起動してchroot環境に移行しますが、その前にrepo sync でソースを同期しておきます。

chromium@Ubuntu12:~$ cd chromiumos/
chromium@Ubuntu12:~/chromiumos$ repo sync
しばらく待つ
Your sources have been sync'd successfully.
chromium@Ubuntu12:~/chromiumos$ ./chromite/bin/cros_sdk 
[sudo] password for chromium: 
(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $ export BOARD=x86-generic

今のところずっとx86をターゲットにしているので、BOARDに設定するオーバレイの名前はx86-genericです。このx86-genericの実体は~/trunk/src/overlays/overlay-x86-genericにあります。編集するのはそこにあるprofiles/base/make.defaultsです。

(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd ../overlays/overlay-x86-generic/profiles/base
(cr) ((961208f...)) chromium@Ubuntu12 ~/trunk/src/overlays/overlay-x86-generic/profiles/base $ ls
make.defaults  package.use  parent
(cr) ((961208f...)) chromium@Ubuntu12 ~/trunk/src/overlays/overlay-x86-generic/profiles/base $ cat make.defaults

（略）

VIDEO_CARDS="intel nouveau radeon"

ファイルの最後の行にあるVIDEO_CARDSが編集箇所で、ここにvesaを書き加えるだけです。
ファイルを書き換えるので、repo startでブランチを切ります。個々のパッケージを書き換えるのではなくてオーバレイの設定を変更するのでcros_workon startはやらなくていいのかなと思っています。この辺はよくわかりませんでした。

(cr) ((961208f...)) chromium@Ubuntu12 ~/trunk/src/overlays/overlay-x86-generic $ repo start my-x86-generic .
(cr) ((961208f...)) chromium@Ubuntu12 ~/trunk/src/overlays/overlay-x86-generic $ cd profiles/base
(cr) (my-x86-generic) chromium@Ubuntu12 ~/trunk/src/overlays/overlay-x86-generic/profiles/base $ vi make.defaults 
（略）
VIDEO_CARDS="intel nouveau radeon vesa"

とりあえずvesaの組み込みはこれだけでできてしまいます。

Xの動作権限の変更

続いて、Xの動作権限をrootにしてしまいます。
R36まではXの動作権限は/sbin/session_manager_setup.shというスクリプトを編集するだけで変えることができましたが、R37からこの仕組みがなくなってしまい、Xの起動ユーザはsession_managerのソースコードに埋めこまれてしまいました。
そのため、Xの起動ユーザを変更するためにはソースコードを書き換えた上でsession_managerをビルドしなおさないといけません。

ただ、このユーザ変更はセキュリティ対策のために行われたようなので、できればユーザをrootにするのは必要なときだけにしたいわけです。そこで、とりあえず設定ファイルにパラメータを書けば起動ユーザをROOTに変えられるような形にしてみます。

R37以降ではGUI周りの設定を行うファイルは/etc/chrome_dev.confというファイルに変わりましたが、このファイルが読み込まれるのはXの起動より後なので、今回の用途には使えません。session_managerがXの起動より前によみこむファイルに/etc/ui_use_flags.txtというのがあるのでこれを使います。

Xの起動を行っているソースファイルは~/trunk/src/platform2/login_manager/chrome_setup.ccです。該当箇所を抜粋すると以下のようになっています。

  
  // Start X in the background before doing more-expensive setup.
  scoped_ptr<xserverrunner> x_runner;
  const base::FilePath xauth_path(kXauthPath);
  const bool using_x11 = builder.UseFlagIsSet("X");          // ← ここでui_use_flags.txtに"X"があるか見ている
  if (using_x11) {
    x_runner.reset(new XServerRunner);
    CHECK(x_runner->StartServer(
        XServerRunner::kDefaultUser, XServerRunner::kDefaultVt,     // ←ここでXを起動している
        builder.is_developer_end_user(), xauth_path));
    }
  }

ここに書かれているXServerRunner::kDefaultUserが"xorg"と定義されているので、このx_runner->StartServerの引数を"root"に書き換えてしまえば起動ユーザをrootに変えられます。
また、その少し上にbuilder.UseFlagIsSet("X")という記述がありますが、これが/etc/ui_use_flags.txtに"X"という行があるかどうかをチェックしている箇所で、この”X"の記述があればXサーバを起動する、という流れになっています。なので、今回は/etc/ui_use_flags.txtに"X_ROOT"という記述があればrootで起動するようにしてみます。ちなみにui_use_flags.txtの内容はこんな感じです。

# This file is just for libchromeos's ChromiumCommandBuilder class.
# Don't use it for anything else. Your code will break.
X                                 ←これが上で参照されていた"X"
X_ROOT                            ←これを追加したらXがroot起動するようにする。
board_use_x86-generic
cros-debug
legacy_keyboard
legacy_power_button

ここまでわかれば修正は簡単です。R39の時に作った修正パッチを示します。

diff --git a/login_manager/chrome_setup.cc b/login_manager/chrome_setup.cc
index dc63dcb..bf9101a 100644
--- a/login_manager/chrome_setup.cc
+++ b/login_manager/chrome_setup.cc
@@ -287,11 +287,20 @@ void PerformChromeSetup(std::map<std::string, std::string>* env_vars_out,
   scoped_ptr<xserverrunner> x_runner;
   const base::FilePath xauth_path(kXauthPath);
   const bool using_x11 = builder.UseFlagIsSet("X");
+  // 14.12.28 add exec X with root user
+  const bool exec_root = builder.UseFlagIsSet("X_ROOT");
   if (using_x11) {
     x_runner.reset(new XServerRunner);
+    if (exec_root){
+    CHECK(x_runner->StartServer(
+        "root", XServerRunner::kDefaultVt,
+        builder.is_developer_end_user(), xauth_path));
+    }
+    else{
     CHECK(x_runner->StartServer(
         XServerRunner::kDefaultUser, XServerRunner::kDefaultVt,
         builder.is_developer_end_user(), xauth_path));
+    }
   }
 
   builder.SetUpChromium(using_x11 ? xauth_path : base::FilePath());

ただ、修正に取り掛かる前にcros_workonで編集宣言する必要がありますので、修正するソースを含むパッケージがどれかを調べます。

(cr) (my-x86-generic) chromium@Ubuntu12 ~/trunk/src/overlays/overlay-x86-generic $ cd ~/trunk/src/scripts
(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cros_workon --board=${BOARD} info --all | grep login
(略)
chromeos-base/chromeos-login chromiumos/platform2 src/platform2

名前はchromeos-base/chromeos-loginとわかりましたのでcros_workonで編集開始を宣言してからブランチを切って編集します。

(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cros_workon --board=${BOARD} start chromeos-login
INFO    : Started working on 'chromeos-base/chromeos-login' for 'x86-generic'
(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd ../platform2/login_manager/
(cr) ((b0e3638...)) chromium@Ubuntu12 ~/trunk/src/platform2/login_manager $ repo start my_login_manager . 
(cr) (my_login_manager) chromium@Ubuntu12 ~/trunk/src/platform2/login_manager $ vi chrome_setup.cc

これで修正は終了です。上に書いたパッチを使うなら以下のような感じです。R39の時に作ったパッチをR40に当てた時の結果です。

(cr) (release-R40-6457.B/my-platform2) chromium@Ubuntu12 ~/trunk/src/platform2 $ patch -p1 --dry-run < ~/myenv/patches/platform2/login_manager_X_ROOT.diff 
patching file login_manager/chrome_setup.cc
Hunk #1 succeeded at 283 (offset -4 lines).
(cr) (release-R40-6457.B/my-platform2) chromium@Ubuntu12 ~/trunk/src/platform2 $ patch -p1 < ~/myenv/patches/platform2/login_manager_X_ROOT.diff 
patching file login_manager/chrome_setup.cc
Hunk #1 succeeded at 283 (offset -4 lines).

あとは前と同じように再ビルドするだけです。

再ビルドする

前回PATAドライバを組み込んだときはcros_workon_makeで編集したパッケージだけを後から組み込みましたが、今回はオーバレイの設定そのものを書き換えているので、build_packageで一からビルドします。

(cr) ((b0e3638...)) chromium@Ubuntu12 ~/trunk/src/platform2/login_manager $ cd ../../scripts/
(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./build_packages --board=${BOARD}
・・・ひたすら待つ
Merge complete
Done
Builds complete
INFO    : Elapsed time (build_packages): 37m8s
Done
(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $

ビルドが終わったら結果を確認してみます。

(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd /build/x86-generic/usr/lib/xorg/modules/drivers/
(cr) chromium@Ubuntu12 /build/x86-generic/usr/lib/xorg/modules/drivers $ ls
ati_drv.so  fbdev_drv.so  intel_drv.so  nouveau_drv.so  radeon_drv.so  vesa_drv.so

vesa_drv.soができているのでとりあえずOKのようです。X_ROOTのほうは動かしてみるまでわかりませんがｗ

Chromium OSのイメージ作成

ではいつものようにChromium OSのイメージを作ります。

(cr) ((696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./build_image --board=${BOARD} --noenable_rootfs_verification dev
・・・ひたすら待つ
INFO    : Elapsed time (build_image): 22m14s
To copy the image to a USB key, use:
  ./image_to_usb.sh --from=../build/images/x86-generic/R35-5709.0.2014_03_30_1739-a1
To convert it to a VMWare image, use:
  ./image_to_vm.sh --from=../build/images/x86-generic/R35-5709.0.2014_03_30_1739-a1 --board=x86-generic

イメージができたら、このタイミングで/etc/ui_use_flags.txtを書き換えてしまいます。イメージをmount_gpt_image.shでマウントしてファイルを書き換えます。

(cr) (release-R40-6457.B/my-scripts) chromium@Ubuntu12 ~/trunk/src/scripts $ sh ./mount_gpt_image.sh --board=${BOARD} -f $(./get_latest_image.sh --board=${BOARD})
1+0 レコード入力
1+0 レコード出力
1 バイト (1 B) コピーされました、 0.000279644 秒、 3.6 kB/秒
Setting up symlinks for /usr/local for /tmp/s/dev_image
INFO    : Image specified by /mnt/host/source/src/build/images/x86-generic/R40-6457.79.2015_03_27_2245-a1 mounted at /tmp/m successfully.
(cr) (release-R40-6457.B/my-scripts) chromium@Ubuntu12 ~/trunk/src/scripts $ cd /tmp/m/etc
(cr) chromium@Ubuntu12 /tmp/m/etc $ sudo vi ui_use_flags.txt 
(cr) chromium@Ubuntu12 /tmp/m/etc $ cd ~/trunk/src/scripts/
(cr) (release-R40-6457.B/my-scripts) chromium@Ubuntu12 ~/trunk/src/scripts $ sh ./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
WARNING : umount failed, but devices were unmounted anyway
WARNING : umount failed, but devices were unmounted anyway
(cr) (release-R40-6457.B/my-scripts) chromium@Ubuntu12 ~/trunk/src/scripts $

つづけて、VirtualBox用の仮想ディスクイメージを作ります。仮想ディスクを作るには~/trunk/src/scripts/image_to_vm.shというスクリプトを使います。ただ、以前は直接VirtualBox用のvdiファイルを作るオプションがあったのですが、とうとう開発チームに見放されたのかオプションが廃止されてしまいました。なので、qemu用のイメージを作ってからVBoxManageで変換をかけます。

(cr) ((696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./image_to_vm.sh --board=${BOARD}
・・・しばらく待つ
Creating final image
Created image at /mnt/host/source/src/build/images/x86-generic/R40-6457.79.2015_03_27_2245-a1
If you have qemu-kvm installed, you can start the image by:
sudo kvm -m 1024 -vga cirrus -pidfile /tmp/kvm.pid -net nic,model=virtio -net user,hostfwd=tcp::9222-:22 \
-hda /mnt/host/source/src/build/images/x86-generic/R40-6457.79.2015_03_27_2245-a1/chromiumos_qemu_image.bin
(cr) ((696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $

これで~/trunk/src/build/images/x86-generic/latestの下にchromiumos_qemu_image.binというファイルができるので、これをvdiに変換します。こちらではビルド環境自体がVirtualBox上のゲストOSなので、当然VBoxManageは入っていません。ファイルをホストOSに転送してホストOS上でVBoxManageを実行します。

(cr) ((696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd ../build/images/x86-generic/latest/
(cr) chromium@Ubuntu12 ~/trunk/src/build/images/x86-generic/latest $ ls 
boot.config  chromiumos_image.bin       config.txt  mount_image.sh      rootfs      stateful      umount_image.sh
boot.desc    chromiumos_qemu_image.bin  esp         pack_partitions.sh  rootfs_dir  stateful_dir  unpack_partitions.sh
(cr) chromium@Ubuntu12 ~/trunk/src/build/images/x86-generic/latest $ scp chromiumos_qemu_image.bin hostuser@192.168.xx.xx:/hoge/VMs/
hostuser@192.168.xx.xx's password: 
chromiumos_qemu_image.bin                                                               100% 2470MB  34.3MB/s  37.8MB/s   01:12

ここからはホストOSでの作業です。実行するコマンドは以下のとおりです。

[hostuser@host VMs]$ VBoxManage convertdd chromiumos_qemu_image.bin vm_chromium_image.vdi
Converting from raw image file="chromiumos_qemu_image.bin" to file="vm_chromium_image.vdi"...
Creating dynamic image with size 7677640704 bytes (7322MB)...

これでVirtualBox用のvdiファイルができたので、VirtualBoxから起動してみます。設定内容はこんな感じです。

起動したところ、今度は無事にGUIが上がりました。

画面の上部に小さくビルド番号が出ていますが、今日（'15/3/27）の日付になっています。うまくいったようです。

ただ、使い勝手はあまりよくないです。Guest Additionsが入っていないのでマウス統合もできないし、なんかマウスの動きが微妙です。でも使えないよりはいいかな。

ということで今回はここまで。

［関連記事］

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

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

にほんブログ村

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

[0回]

Chromium OS ｜ Comment(0)

Chromium OSのカーネルをVAIO Type P向けに再構築する

2014/03/24 (Mon) 09:44

＜'15/09/08追記＞

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

前々回の記事でも書きましたが、Chromium OSのカーネルにはPATAドライバが入っていません。そのため、そのままではVAIO Type Pの内蔵HDDを認識してくれず、HDDへのインストールができません。

そこで、今回はChromium OSのカーネル設定を変更して再ビルドし、VAIO Type P(VGN-P61S)の内蔵HDDが正しく認識できるようにしてみます。うまくいけばVAIO Type Pでも内蔵HDDからブートできるようになります。

今回は内蔵HDDに対応するだけです。他にも何か必要かもしれませんが、まだ問題が見えていないのでとりあえず無視。何かあれば対応しようと思います。

なお、うちのVAIOはSSD換装していないので、SSDでうまくいくかは分かりません。また、今回のVAIO Type Pは旧型です。新型は手元にないのでよく分かりません。そもそもこんな問題は起きないかもしれません。

今回の内容は一応簡単な動作確認はしていますが、素人が試した内容なのでいろいろ嘘があるかもしれません。
今回の記事では以下の各ページを参考にしています。中身は英語ですが、英語はよくわかっていませんので間違えて理解している可能性が高いです。正確に理解したい方は以下の各ページをご覧になることをお勧めします。

ビルド環境の起動

今回は、前回の記事で書いたChromium OSのビルド環境がすでにあり、Chromium OSを最低１回はビルドしていることを前提として進めて行きます。今回は前回の環境を再度起動するところから始めます。

ビルド環境をVirtualBoxなどの仮想環境で作成している方は、現時点で一度スナップショットをとっておくことをお勧めします。

まずビルド用のUbuntu 12.04 LTSを起動して、ビルド用ユーザでChromium OSのSDKを起動します。以下のコマンドを実行します。

chromium@Ubuntu12:~$ cd ~/chromiumos/
chromium@Ubuntu12:~/chromiumos$ ./chromite/bin/cros_sdk
[sudo] password for chromium: 
(cr) ((395f6d3...)) chromium@Ubuntu12 ~/trunk/src/scripts $ export BOARD=x86-generic

一度実行しているので、今回はすぐにchroot環境に移行します。移行したら上記のようにBOARDの設定を行います。ターゲットはVAIO Type Pなのでx86-genericです。

カーネルソースの場所を探す

今回の目的はカーネルの設定を変更してPATAドライバを有効にしてカーネルを再ビルドし、ChromiumOSに組み込みなおすことです。
そのため、まずカーネルソースがどこにあるかを探します。

前回の記事でx86-genericはビルドの設定をまとめたオーバレイの名前だと書きましたが、このオーバレイは複数のパッケージから構成されています。以下のコマンドを実行することで、x86-genericに含まれるパッケージの一覧を表示することができます。

(cr) ((395f6d3...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cros_workon --board=${BOARD} list --all
(略）
sys-kernel/chromeos-kernel
sys-kernel/chromeos-kernel-3_10
sys-kernel/chromeos-kernel-3_14
sys-kernel/chromeos-kernel-next
(略)

カーネルパッケージが４つも出てきます。この辺りの事情はよくわからないのですが、この記事を書いた時点では、x86-genericに関しては正解は "chromeos-kernel-3_10" になります。
（参考：[PSA] x86 generic overlays now use chromeos-kernel-3_10 ）
これを間違えると、後でビルドしたカーネルをChromium OSに組み込む際にFile Collisionというエラーが起きます。
なお、ほかのアーキテクチャでは違うカーネルパッケージを使っている可能性がありますが、それについては現時点では把握していません。

パッケージ名を把握したら、そのソースがどこにあるかは以下のコマンドで調べることができます。

(cr) ((395f6d3...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cros_workon --board=${BOARD} info --all | grep chromeos-kernel-3_10
/mnt/host/source/src/scripts/cros_workon: eval: 行 137: 予期しないトークン `(' 周辺に構文エラーがあります
/mnt/host/source/src/scripts/cros_workon: eval: 行 137: `CROS_WORKON_INCREMENTAL_BUILD=1 CROS_WORKON_USE_VCSID=1 CROS_WORKON_LOCALNAME=( CROS_WORKON_PROJECT=("${CROS_WORKON_LOCALNAME[@]/#/chromiumos/platform/}") CROS_WORKON_DESTDIR=("${CROS_WORKON_LOCALNAME[@]/#/${S}/}")'
sys-kernel/chromeos-kernel-3_10 chromiumos/third_party/kernel-next src/third_party/kernel-next
sys-kernel/chromeos-kernel-3_10 chromiumos/third_party/kernel-next src/third_party/kernel/3.10
sys-kernel/chromeos-kernel-3_10 chromiumos/third_party/kernel-next src/third_party/kernel/3.14

なんかエラーが出ていますが気にしません。結果が３行出ていますが、2行目があたりです。３つのカラムに分かれて出てきていますが、ソースの場所は最後のカラム src/third_party/kernel/3.10 です。これは~/trunkからの相対パスになります。

パッケージの編集開始

Chromium OSのSDKでは、パッケージに対して修正を加える前に、以下のコマンドを使ってパッケージの編集開始操作を行う必要があるようです。

(cr) ((395f6d3...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cros_workon --board=${BOARD} start chromeos-kernel-3_10
INFO    : Started working on 'sys-kernel/chromeos-kernel-3_10' for 'x86-generic'

ソースコードの同期

編集に取り掛かる前にソースの同期を行っておきます。
以下のコマンドを、もう一つ端末を起動してchrootの外、~/chromiumosの下で実行します。

chromium@Ubuntu12:~$ cd chromiumos/
chromium@Ubuntu12:~/chromiumos$ repo sync
remote: Finding sources: 100% (3/3)
（略）
Your sources have been sync'd successfully.

これでソースの編集準備ができました。以降はまたchrootした環境に戻って作業します。

ブランチの作成

Chromium OSのSDKはソースコードの管理にgitを使っていますので、編集に先立ってブランチを作成します。ただし直接gitのコマンドを使わず、repoコマンドを使用します。ブランチを作成する場合は、先ほど調べたソースコードのディレクトリに移動してから以下のコマンドを実行します。

(cr) ((395f6d3...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd ../third_party/kernel/3.10/
(cr) ((0df1ac4...)) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10 $ repo start mykernel-3_10 .　　←最後にピリオドがあるので注意
(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10 $

repo start の次のmykernel-3_10はブランチの名前ですので任意の名前を指定できます。ブランチを作成するとシェルプロンプトにその名前が表示されます。

カーネル設定ファイルの書き換え

ブランチを作ったので、いよいよカーネルの設定を変更します。
カーネルの設定ファイルはカーネルソースディレクトリの下のchromeos/configの下にあります。

Chromium OSのSDKではカーネル設定に関して"splitconfig"という仕組みを取り入れていて、アーキテクチャに共通の設定をchromeos/config/base.configに書き、それ以外のアーキテクチャごとに異なる設定をarmel, i386, x86_64の各サブディレクトリに分けておいてあり、これをビルド時に統合して各アーキテクチャに適したコンフィギュレーションを行うようになっているようです。
今回はVAIO Type PをターゲットにPATA関連の設定を行いますので、base.configおよびi386サブディレクトリに対してgrep PATA を実行してPATA関係のパラメータがあるファイルを探します。

(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10 $ cd chromeos/config/
(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10/chromeos/config $ ls
armel  base.config  i386  x86_64
(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10/chromeos/config $ grep PATA base.config
(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10/chromeos/config $ cd i386
(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10/chromeos/config/i386 $ ls
chromeos-pinetrail-i386.flavour.config  chromiumos-i386.flavour.config  common.config
(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10/chromeos/config/i386 $ grep PATA *
common.config:# CONFIG_PATA_ACPI is not set
common.config:# CONFIG_PATA_ALI is not set
common.config:# CONFIG_PATA_AMD is not set
common.config:# CONFIG_PATA_ARTOP is not set
(略)
common.config:# CONFIG_PATA_SCH is not set
(略)

これでchromeos/config/i386/common.configが編集対象と判明したので、このファイルを編集します。今回は以下の２つのパラメータをyに書き換えます。

(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10/chromeos/config/i386 $ vi common.config

(略)
CONFIG_PATA_ACPI=y
(略)
CONFIG_PATA_SCH=y
(略)

ここで、パラメータはmではなく必ずyを指定します。mを指定するとUSBメモリからHDDにChromium OSをインストールするところまではいきますが、インストールしたOSからブートできなくなります。
今VAIOで使っているlubuntu 13.10ではこれらにmを指定しているので同じにしてみたのですが、うまくいかずにはまって結構悩みました。

Chromium OSでは、ブート時に以下のようなシーケンスを取るようです。

１．MBRに書かれたブートローダが起動し、パーティション12にあるカーネルを起動
２．パーティション12にあるカーネルがパーティション3または5にある本番カーネルを起動

パーティション3または5がルートパーティションで、verified bootの仕組みを実現するため、同じ内容が２つ用意されているようです。一方パーティション12にはブート用のカーネルが置いてあります。vmlinux自体はルートパーティションと同じものですが、パーティション12にはカーネルモジュールがインストールされません。そのため、PATAドライバをモジュールにしてしまうとパーティション12のカーネルはルートパーティションを見つけられずにブートに失敗するのではないかと考えています。
そのため必ずyを指定してPATAドライバをカーネルに直接リンクする必要があります。

先ほども書いたようにChromium OSでは"splitconfig"という仕組みを取り入れているので、単にファイルを書き換えるだけではだめなようで、専用のスクリプトを実行して編集内容を全体に反映する必要があります。
途中で何回か質問をされますが、すべてデフォルトでEnterのみ押します。

(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10/chromeos/config/i386 $ cd ../../..
(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10 $ ./chromeos/scripts/kernelconfig oldconfig
（略）
#
# configuration written to .config
#
Running splitconfig for armel

このスクリプトではi386だけでなくx86_64およびarmelの設定も必要に応じて同時に更新するようです。編集されたファイルを確認してみるとこんな感じになります。

(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10 $ git status
# On branch mykernel-3_10
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   chromeos/config/i386/common.config
#	modified:   chromeos/config/x86_64/common.config
#
no changes added to commit (use "git add" and/or "git commit -a")

i386だけでなくx86_64の設定も書き換わっているようです。

カーネルの再ビルドとChromium OSへの取り込み

これでカーネルの再ビルドの準備ができましたので、カーネルを再ビルドし、以前に実行したChromium OSのビルド結果に新しいカーネルを取り込みます。
カーネルの再ビルドと更新したカーネルのOSへの取り込みは、以下のコマンドで一気に実行できます。

(cr) (mykernel-3_10) chromium@Ubuntu12 ~/trunk/src/third_party/kernel/3.10 $ cd ../../../scripts/
(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $ FEATURES="noclean" cros_workon_make --board=${BOARD} chromeos-kernel-3_10 --install
・・・しばらく待つ
>>> Auto-cleaning packages...

>>> Using system located in ROOT tree /build/x86-generic/

>>> No outdated packages were found on your system.
(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $

FEATURES="noclean"を指定すると、変更したところが局所的ならその部分だけをビルドしますのでうまくいけば早くビルドが終わります。今回のケースは残念ながら全部ビルドになったようで時間がそれなりにかかりました。
ちなみに、最初のカーネルパッケージの選択を間違えると、ここで再ビルドも終わった後にエラーになって失敗します。ここまで来てエラーだと結構ショックがでかいですので気を付ける必要があります。

ビルドと取り込みが終わったら、変更内容がきちんと反映されているか確認します。
Chromium OSのビルド結果はchroot環境の/buildの下にあります。カーネルコンフィギュレーションファイルが/build/x86-generic/bootの下にあるので見てみます。

(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd /build/x86-generic/boot/
(cr) chromium@Ubuntu12 /build/x86-generic/boot $ grep PATA config-3.10.18 
# PATA SFF controllers with BMDMA
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_SC1200 is not set
CONFIG_PATA_SCH=y
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_TOSHIBA is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_PATA_RZ1000 is not set
CONFIG_PATA_ACPI=y
# CONFIG_PATA_LEGACY is not set

うまく反映されているようです。

＜4/19追記＞

現在のChromium OSのソースコードではこの修正だけではVAIO Type Pでブートしません。こちらの記事も参照してください。

イメージの再作成

これでカーネルの置換が終わりました。前回の記事でいうとbuild_packageが終わったのと同じ状況です。後は前回と同様にChromium OSのディスクイメージを再作成してUSBメモリに書きだします。

(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./build_image --board=${BOARD} --noenable_rootfs_verification dev
ひたすら待つ
INFO    : Elapsed time (build_image): 19m49s
To copy the image to a USB key, use:
  ./image_to_usb.sh --from=../build/images/x86-generic/R35-5682.0.2014_03_24_2142-a1
To convert it to a VMWare image, use:
  ./image_to_vm.sh --from=../build/images/x86-generic/R35-5682.0.2014_03_24_2142-a1 --board=x86-generic

(cr) ((c97f454...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./image_to_usb.sh --board=${BOARD}
No target device specified, autodetecting...
Found /dev/sdb: Sony Storage Media, 3.7 GiB
No image name specified, autodetecting...
Found default image chromiumos_image.bin
Copying image /mnt/host/source/src/build/images/x86-generic/R35-5682.0.2014_03_24_2142-a1/chromiumos_image.bin to device /dev/sdb...
WARNING : this will erase all data on /dev/sdb: Sony Storage Media, 3.7 GiB
Are you sure (y/N)? y
2.41GiB 0:10:39 [3.86MiB/s] [================================>] 100%            
617+1 レコード入力
617+1 レコード出力
INFO    : Elapsed time (image_to_usb.sh): 10m45s
Done.

作成したUSBメモリでVAIO Type Pをブートしてみます。

以前の記事で、USBメモリからブートする際にESCを押してコマンドを入力しないと起動しないと書きましたが、PATAドライバを組み込んだ後のUSBメモリであれば、ESCを押さなくても起動するようになっているはずです。ブート時に内蔵HDDが認識されることにより、内蔵HDDが/dev/sda、USBメモリが/dev/sdbと、Chromium OSの想定通りにデバイスファイル名が割り当てられるようになるためです。

あとは、GoogleアカウントでログインしてCtrl+Alt+Tを押してコンソールを起動し、

crosh> install

とすればHDDへのインストールが始まります。HDDの中身は全部消されますので、必要ならあらかじめバックアップを取っておきます。インストール中にWARNING one of the GPT header/entries is invalidという警告が出ますが、インストール自体はうまくいくようです。気になる方はGPartedなどでUSBメモリのGPTパーティションを修復をすればでなくなります。

インストールが終わったら再起動してHDDからうまくChromium OSがブートすれば成功です。

とりあえず今回はここまで。

［関連記事］

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

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

にほんブログ村

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

[1回]

Chromium OS ｜ Comment(6)

＜　 HOME 　＞ 1　 2　 3　

プロフィール

ＨＮ：

zui

性別：

非公開

カテゴリー