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

[PR]

2024/11/21 (Thu) 18:07

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

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から起動してみます。設定内容はこんな感じです。