忍者ブログ
PCメモ
PC関係のメモ、気付いたこと。 simhとChromium OSをいじって遊んでいます。 Chromium OSのカスタムビルドを配布しています。(http://chromiumosde.gozaru.jp) twitter: @zui22904336 PGP fingerprint: 45FC 0E47 A68A FA06 02FE 2BEF B72C C6E6 F9FF 1C19
Admin / Write
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)

これによると直し方は2つあって、ビルド時に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という画面が表示されるので、適当な名前を入力し、2つめの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と一口に言っても、実際には以下の3つがあります。

  • Client id
  • Client Secret
  • API Key

この3つをすべて入手する必要があります。

まず左のメニューの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をあとで使います。




これで必要な3つのキーがそろいましたので、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のメジャーなビルドの1つである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メモリからブートするときのメモ




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

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

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

拍手[0回]

PR


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を起動します。とりあえずこの手順で問題なく併用できました。まあ、併用といっても両方使えるというだけで、さすがに同時起動はムリですねw

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メモリからブートするときのメモ




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

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

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

拍手[0回]



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という2つのディレクトリをスキャンするように指定しています。-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なので平気だったようです。無事に終われば、後は毎日自動で実行されるはずです。






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

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

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

拍手[0回]



2014/04/01 (Tue) 22:34
うちではCentOS6で2TBのディスク7台をRAID6で運用しているのですが、今日そのうちの1台が壊れたらしく、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になってるwww

ここは/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

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

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

みるとまた/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置換はたまにしかやらないので手順を忘れてしまって一度だとうまくいかないことが多いです。今回はうまくリカバリできたけど、これから失敗しないようにしないと。。。



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

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

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

拍手[0回]



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で落ちるようになったようです。

この記事が書かれたのは去年の11月、Hexxeh版がビルドされたのは去年の4月なので、この辺りの事情が当時と今自分でビルドする場合だと変わってくるようです。 確かに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で動くようにはしておきたい。

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

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

一方、後者の方法は調べたら2か所書き換えるだけで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のほうは動かしてみるまでわかりませんがw

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メモリからブートするときのメモ




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

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

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

拍手[0回]



    6  7  8  9  10  11  12  13  14  15 
プロフィール
HN:
zui
性別:
非公開
PR
忍者カウンター
忍者ブログ [PR]