PCメモ

[PR]

2024/11/21 (Thu) 20:19

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

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)

CentOS6へのClamAVのインストール

2014/04/06 (Sun) 13:24

数か月前にCentOS6を古いマシン(32bit)から64bit OSが動かせる新しいマシンにリプレースしたのですが、今の今までウィルススキャンソフトを入れていないという恐ろしいことに気づきました。

ということでリプレース前に使っていたClamAVを今のマシンに入れることにしました。
その手順をメモっておきます。作業は全部rootで行いました。

ダウンロード・インストール

リポジトリにrpmforgeが使えるように設定していればyumで以下のようにインストールできます。

# yum install --enablerepo=rpmforge clamav clamd

clamdの起動

clamdを起動しておきます。

# /etc/init.d/clamd start
Starting Clam AntiVirus Daemon: LibClamAV Warning: **************************************************
LibClamAV Warning: ***  The virus database is older than 7 days!  ***
LibClamAV Warning: ***   Please update it as soon as possible.    ***
LibClamAV Warning: **************************************************
                                                           [  OK  ]

ちなみにchkconfigはデフォルトでonになっているようですのでリブートしても自動で立ち上がるでしょう。

データベースの更新

上でデータベースが古いと出ているので更新します。

# /usr/bin/freshclam
ClamAV update process started at Sun Apr  6 11:54:37 2014
Downloading main-55.cdiff [100%]
main.cld updated (version: 55, sigs: 2424225, f-level: 60, builder: neo)
WARNING: getfile: daily-15077.cdiff not found on remote server (IP: 219.94.128.99)
WARNING: getpatch: Can't download daily-15077.cdiff from db.jp.clamav.net
WARNING: getfile: daily-15077.cdiff not found on remote server (IP: 211.10.155.48)
WARNING: getpatch: Can't download daily-15077.cdiff from db.jp.clamav.net
WARNING: getfile: daily-15077.cdiff not found on remote server (IP: 218.44.253.75)
WARNING: getpatch: Can't download daily-15077.cdiff from db.jp.clamav.net
WARNING: Incremental update failed, trying to download daily.cvd
Downloading daily.cvd [100%]
daily.cvd updated (version: 18746, sigs: 871270, f-level: 63, builder: neo)
Downloading bytecode.cvd [100%]
bytecode.cvd updated (version: 236, sigs: 43, f-level: 63, builder: dgoddard)
Database updated (3295538 signatures) from db.jp.clamav.net (IP: 27.96.54.66)
Clamd successfully notified about the update.

このfreshclamコマンドを日次で実行するスクリプトが/etc/cron.daily/freshclamという名前で自動でインストールされているので、以降は毎日定期的にアップデートが実行されるはずです。

スキャン実行スクリプトの作成

/etc/cron.dailyに日次スキャンを行うスクリプトを書いておきます。

# cd /etc/cron.daily
# vi clamscan

#!/bin/bash
LOG_FILE="/var/log/clamav/clamscan.log"

/usr/bin/yum -y update --enablerepo=rpmforge clamd 
/usr/bin/yum -y update --enablerepo=rpmforge clamav

/usr/bin/clamscan -i -r -l $LOG_FILE /home
/usr/bin/clamscan -i -r -l $LOG_FILE /raid6

とりあえず/homeと/raid6という２つのディレクトリをスキャンするように指定しています。-iは問題を検出したファイルだけを出力するオプション、-rはサブディレクトリもチェックするオプションです。-lオプションでログの出力先を指定しています。
あと、一応実行前にclamdとclamavの更新があればインストールするようにしています。

スキャンの実行

とりあえず作ったスクリプトでスキャンを実行しておきます。

# sh ./clamscan

こんなコマンドを実行してログを監視しておきます。10秒ごとにログの末尾30行を定期的に表示してくれます。

# watch -n 10 tail -n 30 /var/log/clamav/clamscan.log

何も出なければいいんですが、果たしてどうなることやら。問題がなければこんなログが出ます。

----------- SCAN SUMMARY -----------
Known viruses: 3290138
Engine version: 0.98.1
Scanned directories: 16114
Scanned files: 77250
Infected files: 0
Data scanned: 7608.61 MB
Data read: 1386266.04 MB (ratio 0.01:1)
Time: 705.741 sec (11 m 45 s)

infected filesが0なので平気だったようです。無事に終われば、後は毎日自動で実行されるはずです。

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

にほんブログ村

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

[0回]

Linux ｜ Comment(0)

LinuxのRAID復旧で失敗しかけた話

2014/04/01 (Tue) 22:34

うちではCentOS6で2TBのディスク7台をRAID6で運用しているのですが、今日そのうちの１台が壊れたらしく、RAIDがデグレード状態になっていました。

ということで予備のディスクを使って復旧を行いました。

まず本当なら壊れたディスクをRAIDから除去するのですが、すっかり忘れてました。
ここからもうすでにいろいろまずかったのですが。

で、マシンをシャットダウンしてディスク交換を行い、再起動しました。
fdiskで交換したディスクにパーティションを作って、パーティションタイプをLinux raid 自動検出に変えます。手順はこんな感じ。

# fdisk /dev/sdf

(略)

コマンド (m でヘルプ): n　　←新規パーティション
コマンドアクション
   e   拡張
   p   基本領域 (1-4)
p　　　　　　　　　　　　　←基本領域
領域番号 (1-4): 1
最初 シリンダ (1-243201, default 1): 1
終点 シリンダ または +サイズ または +サイズM または +サイズK (1-243201, default 243201): +243153　  

コマンド (m でヘルプ): p　

Disk /dev/sdf: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/sdf1               1      243154  1953134473+  83  Linux　　←普通のLinuxパーティションなのでRAIDに変える

コマンド (m でヘルプ): t　←パーティションタイプ変更
Selected partition 1
16進数コード (L コマンドでコードリスト表示): fd　　　　　←Linux RAIDを指定
領域のシステムタイプを 1 から fd (Linux raid 自動検出) に変更しました

コマンド (m でヘルプ): p　　←状態確認

Disk /dev/sdf: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/sdf1               1      243154  1953134473+  fd  Linux raid 自動検出　　←Linux RAIDになった

コマンド (m でヘルプ): w　　　　←結果保存
領域テーブルは交換されました！

ioctl() を呼び出して領域テーブルを再読込みします。
ディスクを同期させます。
#

で、このディスクをRAIDに組み込みます。

# mdadm --manage /dev/md2 --add /dev/sdf
mdadm: added /dev/sdf

で、自動的にRAIDのリカバリが始まり、後は待つだけ。。。。

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] 
md2 : active raid6 sdc1[0] sdf[7] sdi1[6] sdh1[5] sdg1[4] sde1[2] sdd1[1]
      9765672000 blocks level 6, 64k chunk, algorithm 2 [7/6] [UUU_UUU]
      [>....................]  recovery =  0.0% (126080/1953134400) finish=1806.9min 

speed=18011K/sec

ん？！

なんか変だぞ？

よく見たら/dev/sdfになってるｗｗｗ

ここは/dev/sdf1でないとダメじゃないですか！

ありゃま、どうしよう、ということでやり直しです。
まず、リカバリ中ですが無視していったんRAIDを止めました。

# mdadm --stop /dev/md2
mdadm: stopped /dev/md2

で、ミスって組み込んだ/dev/sdfをのぞいた6台でRAIDを組みなおします。

# mdadm --assemble /dev/md2 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdg1 /dev/sdh1 /dev/sdi1
mdadm: /dev/md2 has been started with 6 drives (out of 7).

間違えて/dev/sdfで組み込んじゃったHDDはパーティションテーブルがおかしくなっているはずなのでいったんクリアしておきます。

# dd if=/dev/zero of=/dev/sdf bs=512 count=64
64+0 records in
64+0 records out
32768 bytes (33 kB) copied, 0.260877 s, 126 kB/s

で、もう一度fdiskでパーティションを切り直し。手順は上に書いた通りです。
そして、今度こそは/dev/sdf1をRAIDに組み込みます。

# mdadm --manage /dev/md2 --add /dev/sdf1
mdadm: added /dev/sdf1

これで今度こそちゃんとリカバリが始まりました。

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] 
md2 : active raid6 sdf1[7] sdc1[0] sdi1[6] sdh1[5] sdg1[4] sde1[2] sdd1[1]
      9765672000 blocks level 6, 64k chunk, algorithm 2 [7/6] [UUU_UUU]
      [>....................]  recovery =  0.3% (6041092/1953134400) finish=1535.5min 

speed=21132K/sec

まったく、、我ながらなにやってるんでしょうかねｗｗｗ
リカバリには丸一日かかるので放置しました。

で、終わったのでいったんリブートしました。するとまたデグレード。

みるとまた/dev/sdfがRAIDに取り込まれている。。。

これを忘れていたのが原因でした。

# mdadm --zero-superblock /dev/sdf

一度RAIDに取り込んだディスクは、ディスクの末尾にスーパーブロックというRAID専用の情報が書き込まれているので、これを消さないといけませんでした。

あと、よく考えたらAFTのことも忘れていました。AFTというのは物理セクタのサイズを従来の512バイトから4096バイトに拡張したものです。ただしLinux上だと論理セクタは512バイトのままのようです。
普通にfdiskでパーティションを切ると開始位置はシリンダにそろえられますが、これは論理セクタ単位だと63セクタになります。これだとAFTディスクの物理セクタサイズと一致しないので、fdiskを実行したとに以下のようなメッセージが出ます。

＜非AFTディスクの場合＞

ディスク /dev/sdg: 2000.4 GB, 2000398934016 バイト
ヘッド 255, セクタ 63, シリンダ 243201
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト　　←　物理セクタ＝論理セクタ
I/O size (minimum/optimal): 512 bytes / 512 bytes
ディスク識別子: 0x0811122f

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdg1               1      243154  1953134473+  fd  Linux raid 自動検出
（ここに何も出ない）

＜AFTディスクの場合＞

# fdisk -l /dev/sdf

ディスク /dev/sdf: 2000.4 GB, 2000398934016 バイト
ヘッド 255, セクタ 63, シリンダ 243201
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト　←ここの物理が4096バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x00000000

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1               1      243154  1953134473+  fd  Linux raid 自動検出
Partition 1 does not start on physical sector boundary.　←こんなエラーが出る

fdiskを-uオプション付きで実行すると表示をセクタ単位にすることができます。それで実行すると以下のようになっています。

# fdisk -lu /dev/sdf

ディスク /dev/sdf: 2000.4 GB, 2000398934016 バイト
ヘッド 255, セクタ 63, シリンダ 243201
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x00000000

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1              63  3906269009  1953134473+  fd  Linux raid 自動検出
Partition 1 does not start on physical sector boundary.

開始位置が63になっていて、これが8の倍数（4096/512）になっていないと性能が出ないという話があります。性能が出ないだけで一応使えますが、とりあえずやり直すならfdiskを-u付きで起動して、ちゃんと物理セクタに合わせてパーティションを切りなおします。

[root@developper ~]# fdisk -u /dev/sdf

警告: DOS互換モードは廃止予定です。このモード (コマンド 'c') を止めることを
      強く推奨します。.

コマンド (m でヘルプ): p

ディスク /dev/sdf: 2000.4 GB, 2000398934016 バイト
ヘッド 255, セクタ 63, シリンダ 243201, 合計 3907029168 セクタ
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x00000000

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1              63  3906269009  1953134473+  fd  Linux raid 自動検出

コマンド (m でヘルプ): d
選択した領域 1

コマンド (m でヘルプ): n
コマンドアクション
   e   拡張
   p   基本パーティション (1-4)
p
パーティション番号 (1-4): 1
最初 セクタ (63-3907029167, 初期値 63): 64　←　ここで64を指定
Last セクタ, +セクタ数 or +size{K,M,G} (64-3907029167, 初期値 3907029167):
初期値 3907029167 を使います　← Lastセクタは1足して8の倍数ならOK

コマンド (m でヘルプ): p

ディスク /dev/sdf: 2000.4 GB, 2000398934016 バイト
ヘッド 255, セクタ 63, シリンダ 243201, 合計 3907029168 セクタ
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x00000000

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1              64  3907029167  1953514552   83  Linux

コマンド (m でヘルプ): t
選択した領域 1
16進数コード (L コマンドでコードリスト表示): fd
領域のシステムタイプを 1 から fd (Linux raid 自動検出) に変更しました

コマンド (m でヘルプ): p

ディスク /dev/sdf: 2000.4 GB, 2000398934016 バイト
ヘッド 255, セクタ 63, シリンダ 243201, 合計 3907029168 セクタ
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x00000000

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1              64  3907029167  1953514552   fd  Linux raid 自動検出
（ここにエラーメッセージが出なければOK）
コマンド (m でヘルプ): w
パーティションテーブルは変更されました！

ioctl() を呼び出してパーティションテーブルを再読込みします。
ディスクを同期しています。

とりあえずこれで再度RAIDに組み込んでリカバリしたらうまくいきました。
RAIDのHDD置換はたまにしかやらないので手順を忘れてしまって一度だとうまくいかないことが多いです。今回はうまくリカバリできたけど、これから失敗しないようにしないと。。。

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

にほんブログ村

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

[0回]

Linux ｜ 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)