前回の記事でも書きましたが、今自分でビルドしているChromiumOSはVirtualBoxやVMwareでは動きません。Hexxeh版はVirtualBox上でもちゃんと動くのに自分でビルドするとなんでだめなのか、気になったので調べてみました。自分が使っている仮想環境がVirtualBoxなので、今回はVirtualBoxをターゲットにします。VMWareで動くかどうかは調べていません。Linux...」の画面が出た後勝手にリブートし、再度ブートが始まった後固まります。この固まった状態で右Ctrl+F2(実機のCtrl+Alt+F2相当)を押すとターミナルが表示されました。完全に固まっているわけではなく、OS自体は起動しているようです。そこでログインして/var/log/Xorg.0.logを見てみると以下のような表示が出ていました。file.見たところグラフィック関連のドライバロードに失敗しているようです。Additionsをインストールすると入るドライバですのでロードできないのは仕方ないですが、気になるのは次のvesaのロードに失敗していることです。ちなみにHexxeh版をVirtualBoxで実行したときのログはこんな感じ。detectedちゃんとvesaのロードに成功しています。いうことでこれが原因かなとあたりをつけてさくっと組み込んでみたのですが。/dev/memとなって落ちてしまいました。int10の後何の問題もなく動いています。後気になるのが、自分でビルドしたものにはfbdevドライバが入っているのにHexxeh版にはfbdevドライバが入っていないということ。これは一体どういうことなのか、といろいろググって見つけたのが以下の記事でした。master]どうやらセキュリティ向上のためにXorgの動作アカウントがrootになっていたのをやめたようです。deniedで落ちるようになったようです。この記事が書かれたのは去年の11月、Hexxeh版がビルドされたのは去年の4月なので、この辺りの事情が当時と今自分でビルドする場合だと変わってくるようです。確かにHexxeh版の/usr/bin/Xの動作アカウントはrootになっています。自分でビルドしたものはXがすぐ落ちちゃうのでpsには出てきませんが、どうやらxorgというユーザで起動しに行くようです。記事にはfbdevはroot権限を要求しないのでvesaのかわりにこれを使うようにと書かれています。Hexxeh版でfbdevが組み込まれていないのに、今デフォルトでビルドするとfbdevが組み込まれるのはこういった事情のようです。設定がうまくされていないらしく結局Xの起動に失敗するようです。OSは仮想環境としてはKVM/QEMUを推奨していてVirutualBoxやVMWareはほとんど無視らしく、このあたりが放置されているようです。それだとWindows上の仮想環境で試したい、という時に手がなくなってしまいますので、やっぱVirtualBoxで動くようにはしておきたい。ここで、対応案が2つ出てきます。1つは記事に書かれているようにfbdevを使ってXが立ち上がるようにすること。1つはXをroot起動してvesaを使えるようにすること。前者の方法を調べてみると/dev/fb0を作ったり/etc/xorg.confを書き換えたりといろいろ大変そうです。この変更は、インストール後に書き換えるのではなくてビルド時にきちんとChromiumOSのパッケージに反映されるようにする必要があります。デバイスファイルの追加方法はまだよくわかっていないので大変そうです。後者の方法は調べたら2か所書き換えるだけでOKでした。怒られそうですが今回はその方法でサクッと対応してしまいます。#'15.03.28追記:これはR35の時の記述です。今はソース修正しないとXの起動ユーザを変更できなくなり、到底簡単とは言えない状態になってしまいました。以下ではその手順を追記しています。OSのビルド環境構築およびカスタマイズ手順を前提にしています。細かい部分は端折っています。OSに組み込むビデオカードドライバの一覧は、ターゲットアーキテクチャ用オーバレイのprofiles/base/make.defaultsに書かれています。make.defaultsにvesaを付け加えるだけです。以前はoverlay-x86-generic直下のmake.confで設定しましたが、R45以降上記の場所に変わっています。手順は以下の通りになります。ソースを同期しておきます。BOARD=x86-generic今のところずっとx86をターゲットにしているので、BOARDに設定するオーバレイの名前はx86-genericです。このx86-genericの実体は~/trunk/src/overlays/overlay-x86-genericにあります。編集するのはそこにあるprofiles/base/make.defaultsです。ファイルの最後の行にあるVIDEO_CARDSが編集箇所で、ここにvesaを書き加えるだけです。startでブランチを切ります。startはやらなくていいのかなと思っています。この辺はよくわかりませんでした。vesaの組み込みはこれだけでできてしまいます。続いて、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です。該当箇所を抜粋すると以下のようになっています。}ここに書かれている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の内容はこんな感じです。←これを追加したらXがroot起動するようにする。board_use_x86-genericcros-debuglegacy_keyboardlegacy_power_buttonここまでわかれば修正は簡単です。R39の時に作った修正パッチを示します。base::FilePath());ただ、修正に取り掛かる前にcros_workonで編集宣言する必要がありますので、修正するソースを含むパッケージがどれかを調べます。src/platform2名前はchromeos-base/chromeos-loginとわかりましたのでcros_workonで編集開始を宣言してからブランチを切って編集します。chrome_setup.ccこれで修正は終了です。上に書いたパッチを使うなら以下のような感じです。R39の時に作ったパッチをR40に当てた時の結果です。lines).あとは前と同じように再ビルドするだけです。再ビルドする前回PATAドライバを組み込んだときはcros_workon_makeで編集したパッケージだけを後から組み込みましたが、今回はオーバレイの設定そのものを書き換えているので、build_packageで一からビルドします。ビルドが終わったら結果を確認してみます。vesa_drv.sovesa_drv.soができているのでとりあえずOKのようです。OSのイメージを作ります。--board=x86-genericイメージができたら、このタイミングで/etc/ui_use_flags.txtを書き換えてしまいます。イメージをmount_gpt_image.shでマウントしてファイルを書き換えます。つづけて、VirtualBox用の仮想ディスクイメージを作ります。仮想ディスクを作るには~/trunk/src/scripts/image_to_vm.shというスクリプトを使います。以前は直接VirtualBox用のvdiファイルを作るオプションがあったのですが、とうとう開発チームに見放されたのかオプションが廃止されてしまいました。qemu用のイメージを作ってからVBoxManageで変換をかけます。これで~/trunk/src/build/images/x86-generic/latestの下にchromiumos_qemu_image.binというファイルができるので、これをvdiに変換します。こちらではビルド環境自体がVirtualBox上のゲストOSなので、当然VBoxManageは入っていません。ファイルをホストOSに転送してホストOS上でVBoxManageを実行します。01:12ここからはホストOSでの作業です。実行するコマンドは以下のとおりです。(7322MB)...これでVirtualBox用のvdiファイルができたので、VirtualBoxから起動してみます。設定内容はこんな感じです。起動したところ、今度は無事にGUIが上がりました。画面の上部に小さくビルド番号が出ていますが、今日('15/3/27)の日付になっています。うまくいったようです。使い勝手はあまりよくないです。Additionsが入っていないのでマウス統合もできないし、なんかマウスの動きが微妙です。使えないよりはいいかな。いうことで今回はここまで。OSをUSBメモリからブートするときのメモランキングに参加してみました。クリックしていただければ嬉しいです。