2014/03/19 (Wed) 22:18
'15/03/21 一部古くなっていた部分を修正しました。
前回VAIO Type PのハードディスクにChromium OSを入れようとして挫折しましたが、なんかもやもやするので結局自分でビルドしてみることにしました。
今回はとりあえずビルドできるようにするところまで行います。
Chromium OSのビルド方法はChromium OSの公式サイトの"Chromium OS Developer Guide"に書いてあったので、そのとおりにやってみます。
ガイドにはソースを本家リポジトリにコミットするために必要な準備作業がいくつか出てきますが、そんなつもりはないのでその辺の操作は飛ばしてとりあえずビルドできる環境を作ります。
ビルドに使うOSは64bit版Ubuntu 12.04 14.04 LTSが良いとされています('15.04.25 追記:公式ページで推奨のビルド環境用OSが14.04に変わっていました。)。でも、残念ながら今使っているLinuxはCentOSでUbuntuではありません。それ専用のマシンは用意できないので、今回はCentOSに入れてあるVirtualBox上に環境を作ります。
Ubuntuのインストールについてはここでは特に触れません。注意すべきなのは、64bit版にすること、メモリは4GB以上、ディスク容量は最低でも40GBは必要です(最初30GBでやっていてあふれました)。40GBでもいろいろ作業しているうちに足りなくなるかもしれませんのでもう少し多めにしたほうがいいかもしれません。
また、最終的にイメージをUSBメモリに書きだしますので、USBメモリにアクセスできるようにしておく必要があります。
あと、ビルドに使うユーザ名は、ビルドしたChromium OSのビルド情報などに表示されますので、あまり変な名前は付けないほうがいいかもしれませんねw
今回は、ビルド環境をユーザのホームディレクトリの下に作っていきます。
ビルド環境用のUbuntuを起動し、ターミナルから以下のコマンドを実行します。
続けてdepot_toolsのインストールを行います。どうやらChromium OSのソースリポジトリにアクセスするために使われるツールのようです。 以下のコマンドを実行します。
これでホームディレクトリの下にdepot_toolsというディレクトリが作成され、そこにdepot_toolの実行環境が作られますので、~/.bashrcを編集してdepot_toolsへのパスを追加します。
Chromium OSのビルドツールが正しく動作するためにsudoersのオプションtty_ticketsを無効にします。以下のコマンドを実行します。
以下のコマンドを実行します。メールアドレスと名前はそれぞれ適切なものに置き換えます。
以下のコマンドを実行してx86_64と表示されればOK。
以下のコマンドを実行してオーナーだけ読み書き、それ以外は読み取りになるようにします。
これで準備は終わりです。ソースのダウンロードを始めます。
ソースコードを置くディレクトリを作成します。今回はユーザのホームディレクトリの下にchromiumosというディレクトリを作ります。
ガイドによると、ソース置き場はパフォーマンス上の問題からNFS上に置くな、ということです。当初VMにあまりディスク容量をさきたくなかったのでソースはホストOS側においてcifsかNFSでマウントしようかと思っていたのですが、この記述を見てやめました。
いよいよソースを取り出します。以下のコマンドを実行します。
['14/4/13追記]
以下の方法で取り出されるのは現時点での最新の開発版ソースになります。Chromebookで使われている安定版のソースを取り出したいときは以下のrepo initに-bオプションでチェックアウトするブランチの名前を指定します。詳しくはこちらの記事を参照してください。
repoコマンドは上でインストールしたdepot_toolsに含まれているツールでChromium OSのソースリポジトリへのアクセスを行うコマンドです。repo syncを実行するとソースのチェックアウトが始まるのでひたすら待ちます。待ち時間はかなりあります。こちらの環境では4~50分かかりました。
Chromium OSのビルドはchrootを使って外部から隔離された環境で行われます。chroot後は~/chromiumos/chrootが新しいルートとなり、この下にChromium OSビルド専用の/usr/binなどが準備されます。これにより、マシンの環境に左右されずに同等のビルド結果が得られるようにしているようです。sdkの初回起動時は、このビルド環境用のバイナリのダウンロードが行われます。ダウンロードが終わるとシェルのプロンプトが(cr)で始まるものに変わり、カレントディレクトリも~/trunk/src/scriptsに変わります。メッセージにTo enter the chroot,~とか出ていますが、この状態ですでにchrootした環境に移っています。以降はこの環境で作業をしていきます。
続いて、ビルドのターゲットとするアーキテクチャを指定します。いずれはVAIO Type Pで動かしたいので、今回はx86をターゲットにします。以下のように指定します。
Chromium OSのSDKでは、ターゲットアーキテクチャごとにビルドの設定をまとめたものを「オーバレイ」と呼んでいて、各種ビルドツールの--boardオプションでこのオーバレイの名前を指定します。あらかじめこの名前を環境変数BOARDに設定しているわけです。
このオーバレイの実体は~/trunk/src/overlaysの下に"overlay-オーバレイ名"という名前でおいてあります。
続けて、これからビルドするChromium OSでシェルを使う際のアカウントとなるchronosのパスワードを指定します。
ビルドもかなり時間がかかります。上にもあるようにこちらの環境では42分かかっています。
ビルドが終わったらディスクイメージを作成します。これまた時間がかかります。
--noenable_rootfs_verification オプションはChromium OSのセキュリティ関連のオプションでverified bootという機構を無効にします。verified bootはブート時にルートパーティションの内容をチェックして不正な修正がくわえられていたらブートを中断してリカバリモードに落ちる、というような仕組みのようで(Chromium OSではなく)Google Chrome OSの売りの一つです。
"Chromium OS FAQ"の"What's the difference between Chromium OS and Google Chrome OS?"を読むと、verified bootは専用のファームウェアの使用が前提で、Chromebookでは有効でもChromium OSでは機能しない、といった記述があるようです。Chromium OSでこのオプションを外すとどうなるのか、多少でもセキュアになるんでしょうか。まだよくわかりません。
作成したディスクイメージは以下のコマンドでマウントして中身を見ることができます。
マウント先はルートパーティションが/tmp/m、STATEパーティションが/tmp/sになります。
不要になったら以下のコマンドでアンマウントします。
出来上がったイメージはUSBメモリに書き込んだり、仮想マシン用のディスクイメージにしたりすることができます。とりあえず今回はUSBメモリに直接イメージを書き込んでみます。以下のコマンドを実行すると、USBメモリを探して直接そこに書きだしに行きます。
これで作成したUSBメモリを使ってVAIO Type PでChromium OSをブートしてみました。
今回はESCを押した後のbootコマンドで
chromeos-usb.A root=/dev/sda3 init=/sbin/init
とすることでブートできました。 Haxxeh版に比べるとかなりレスポンスが良くなっています。でも軽いとまでは言えない感じです。相変わらずHDDは認識しません。
とりあえず自分でビルドしてみた感触ですが、デフォルトでビルドするだけならば、思っていたよりは難しくないですね。ガイドの通りにやればとりあえずできました。ただ、ものがでかいだけに時間はかなりかかります。
いろいろいじって、VAIO Type Pでいい感じに動くようにもっていきたいのですが、果たしてうまくいくんだろうか。。。
とりあえず今回はここまで。
[関連記事]
[悲報] 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のカーネルをVAIO Type P向けに再構築する
Hexxeh版Chromium OSをVAIO Type Pにインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ
前回VAIO Type PのハードディスクにChromium OSを入れようとして挫折しましたが、なんかもやもやするので結局自分でビルドしてみることにしました。
今回はとりあえずビルドできるようにするところまで行います。
Chromium OSのビルド方法はChromium OSの公式サイトの"Chromium OS Developer Guide"に書いてあったので、そのとおりにやってみます。
ガイドにはソースを本家リポジトリにコミットするために必要な準備作業がいくつか出てきますが、そんなつもりはないのでその辺の操作は飛ばしてとりあえずビルドできる環境を作ります。
ビルド用仮想マシンの作成
ビルドに使うOSは64bit版Ubuntu 12.04 14.04 LTSが良いとされています('15.04.25 追記:公式ページで推奨のビルド環境用OSが14.04に変わっていました。)。でも、残念ながら今使っているLinuxはCentOSでUbuntuではありません。それ専用のマシンは用意できないので、今回はCentOSに入れてあるVirtualBox上に環境を作ります。
Ubuntuのインストールについてはここでは特に触れません。注意すべきなのは、64bit版にすること、メモリは4GB以上、ディスク容量は最低でも40GBは必要です(最初30GBでやっていてあふれました)。40GBでもいろいろ作業しているうちに足りなくなるかもしれませんのでもう少し多めにしたほうがいいかもしれません。
また、最終的にイメージをUSBメモリに書きだしますので、USBメモリにアクセスできるようにしておく必要があります。
あと、ビルドに使うユーザ名は、ビルドしたChromium OSのビルド情報などに表示されますので、あまり変な名前は付けないほうがいいかもしれませんねw
今回は、ビルド環境をユーザのホームディレクトリの下に作っていきます。
Subversion, Git, Curlのインストール
ビルド環境用のUbuntuを起動し、ターミナルから以下のコマンドを実行します。
user@Ubuntu:~$ sudo apt-get install git-core gitk git-gui subversion curl
depot_toolsのインストール
続けてdepot_toolsのインストールを行います。どうやらChromium OSのソースリポジトリにアクセスするために使われるツールのようです。 以下のコマンドを実行します。
user@Ubuntu:~$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
これでホームディレクトリの下にdepot_toolsというディレクトリが作成され、そこにdepot_toolの実行環境が作られますので、~/.bashrcを編集してdepot_toolsへのパスを追加します。
user@Ubuntu:~$ vi .bachrc (略) export PATH="$PATH":~/depot_tools ←この行を追加
sudoersのtty_ticketsオプションを無効にする
Chromium OSのビルドツールが正しく動作するためにsudoersのオプションtty_ticketsを無効にします。以下のコマンドを実行します。
user@Ubuntu:~$ cd /tmp user@Ubuntu:/tmp$ cat > ./sudo_editor <<EOF #!/bin/sh echo Defaults \!tty_tickets > \$1 # Entering your password in one shell affects all shells echo Defaults timestamp_timeout=180 >> \$1 # Time between re-requesting your password, in minutes (Ctrl-D) user@Ubuntu:/tmp$ chmod +x ./sudo_editor user@Ubuntu:/tmp$ sudo EDITOR=./sudo_editor visudo -f /etc/sudoers.d/relax_requirements
gitの設定
以下のコマンドを実行します。メールアドレスと名前はそれぞれ適切なものに置き換えます。
user@Ubuntu:/tmp$ cd user@Ubuntu:~$ git config --global user.email "you@example.com" user@Ubuntu:~$ git config --global user.name "Your Name"
64ビットOSを使っているか確認する。
以下のコマンドを実行してx86_64と表示されればOK。
user@Ubuntu:~$ uname -m x86_64
ファイル作成時のパーミッションの設定
以下のコマンドを実行してオーナーだけ読み書き、それ以外は読み取りになるようにします。
user@Ubuntu:~$ umask 022 user@Ubuntu:~$ touch foo user@Ubuntu:~$ ls -l foo -rw-r--r-- 1 user user 0 3月 19 21:47 foo ← -rw-r--r--で始まっていればOK
これで準備は終わりです。ソースのダウンロードを始めます。
ソースコード用ディレクトリの作成
ソースコードを置くディレクトリを作成します。今回はユーザのホームディレクトリの下にchromiumosというディレクトリを作ります。
user@Ubuntu:~$ mkdir -p chromiumos
ガイドによると、ソース置き場はパフォーマンス上の問題からNFS上に置くな、ということです。当初VMにあまりディスク容量をさきたくなかったのでソースはホストOS側においてcifsかNFSでマウントしようかと思っていたのですが、この記述を見てやめました。
ソースの取得
いよいよソースを取り出します。以下のコマンドを実行します。
['14/4/13追記]
以下の方法で取り出されるのは現時点での最新の開発版ソースになります。Chromebookで使われている安定版のソースを取り出したいときは以下のrepo initに-bオプションでチェックアウトするブランチの名前を指定します。詳しくはこちらの記事を参照してください。
user@Ubuntu:~$ cd chromiumos user@Ubuntu:~/chromiumos$ repo init -u https://chromium.googlesource.com/chromiumos/manifest.git --repo-url https://chromium.googlesource.com/external/repo.git Get https://chromium.googlesource.com/external/repo.git (略) repo has been initialized in /home/user/chromiumos user@Ubuntu:~/chromiumos$ repo sync ・・・ひたすら待つ Syncing work tree: 100% (159/159), done. Your sources have been sync'd successfully. user@Ubuntu:~/chromiumos$
repoコマンドは上でインストールしたdepot_toolsに含まれているツールでChromium OSのソースリポジトリへのアクセスを行うコマンドです。repo syncを実行するとソースのチェックアウトが始まるのでひたすら待ちます。待ち時間はかなりあります。こちらの環境では4~50分かかりました。
Chromium OSのSDKを起動する
いよいよChromium OSをビルドします。以下のコマンドでsdkを起動します。user@Ubuntu:~/chromiumos$ cros_sdk Attempting download: https://commondatastorage.googleapis.com/chromiumos-sdk/cros-sdk-2015.01.11.080752.tar.xz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 415M 100 415M 0 0 15.4M 0 0:00:26 0:00:26 --:--:-- 15.6M (略) cros_sdk:make_chroot: All set up. To enter the chroot, run: $ cros_sdk --enter CAUTION: Do *NOT* rm -rf the chroot directory; if there are stale bind mounts you may end up deleting your source tree too. To unmount and delete the chroot cleanly, use: $ cros_sdk --delete (cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $
Chromium OSのビルドはchrootを使って外部から隔離された環境で行われます。chroot後は~/chromiumos/chrootが新しいルートとなり、この下にChromium OSビルド専用の/usr/binなどが準備されます。これにより、マシンの環境に左右されずに同等のビルド結果が得られるようにしているようです。sdkの初回起動時は、このビルド環境用のバイナリのダウンロードが行われます。ダウンロードが終わるとシェルのプロンプトが(cr)で始まるものに変わり、カレントディレクトリも~/trunk/src/scriptsに変わります。メッセージにTo enter the chroot,~とか出ていますが、この状態ですでにchrootした環境に移っています。以降はこの環境で作業をしていきます。
ターゲットアーキテクチャの指定
続いて、ビルドのターゲットとするアーキテクチャを指定します。いずれはVAIO Type Pで動かしたいので、今回はx86をターゲットにします。以下のように指定します。
(cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $ export BOARD=x86-generic (cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $ ./setup_board --board=${BOARD} (略) Done! The SYSROOT is: /build/x86-generic (cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $
Chromium OSのSDKでは、ターゲットアーキテクチャごとにビルドの設定をまとめたものを「オーバレイ」と呼んでいて、各種ビルドツールの--boardオプションでこのオーバレイの名前を指定します。あらかじめこの名前を環境変数BOARDに設定しているわけです。
このオーバレイの実体は~/trunk/src/overlaysの下に"overlay-オーバレイ名"という名前でおいてあります。
chronosパスワードの設定
続けて、これからビルドするChromium OSでシェルを使う際のアカウントとなるchronosのパスワードを指定します。
(cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $ ./set_shared_user_password.sh Enter password for shared user account: ←任意のパスワードを入力 Password set in /etc/shared_user_passwd.txt (cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $
ビルド実行
いよいよビルドします。以下のコマンドを実行します。(cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $ ./build_packages --board=${BOARD} ChromeOS version information: CHROME_BRANCH=35 CHROME_VERSION= CHROMEOS_VERSION_STRING=5660.0.2014_03_19_2334 CHROME_BASE= INFO : Elapsed time (run_chroot_version_hooks): 0m0s INFO : Updating chroot INFO : Clearing shadow utils lockfiles under / ・・・ ひたすら待つ Merge complete Done Builds complete INFO : Elapsed time (build_packages): 42m14s Done (cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $
ビルドもかなり時間がかかります。上にもあるようにこちらの環境では42分かかっています。
ディスクイメージの作成
ビルドが終わったらディスクイメージを作成します。これまた時間がかかります。
(cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $ ./build_image --board=${BOARD} --noenable_rootfs_verification dev ChromeOS version information: CHROME_BRANCH=35 CHROME_VERSION= CHROMEOS_VERSION_STRING=5660.0.2014_03_20_0029 CHROME_BASE= INFO : The following images will be built chromiumos_image.bin. INFO : Clearing shadow utils lockfiles under /build/x86-generic ・・・ひたすら待つ
--noenable_rootfs_verification オプションはChromium OSのセキュリティ関連のオプションでverified bootという機構を無効にします。verified bootはブート時にルートパーティションの内容をチェックして不正な修正がくわえられていたらブートを中断してリカバリモードに落ちる、というような仕組みのようで(Chromium OSではなく)Google Chrome OSの売りの一つです。
"Chromium OS FAQ"の"What's the difference between Chromium OS and Google Chrome OS?"を読むと、verified bootは専用のファームウェアの使用が前提で、Chromebookでは有効でもChromium OSでは機能しない、といった記述があるようです。Chromium OSでこのオプションを外すとどうなるのか、多少でもセキュアになるんでしょうか。まだよくわかりません。
作成したディスクイメージは以下のコマンドでマウントして中身を見ることができます。
(cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $ ./mount_gpt_image.sh --board=${BOARD} -f $(./get_latest_image.sh --board=${BOARD})
マウント先はルートパーティションが/tmp/m、STATEパーティションが/tmp/sになります。
不要になったら以下のコマンドでアンマウントします。
(cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $ ./mount_gpt_image.sh --board=${BOARD} -u
出来上がったイメージはUSBメモリに書き込んだり、仮想マシン用のディスクイメージにしたりすることができます。とりあえず今回はUSBメモリに直接イメージを書き込んでみます。以下のコマンドを実行すると、USBメモリを探して直接そこに書きだしに行きます。
(cr) ((7f6126a...)) user@Ubuntu ~/trunk/src/scripts $ cros flash usb:// ${BOARD}/latest 19:26:55: INFO: Preparing to image the removable device Removable device(s) found. Please select/confirm to continue: [0]: USB DISK 2.0 3.6G (/dev/sdb) Please choose an option [0-0]: 0 19:26:58: INFO: [21/Mar/2015:19:26:58] XBUDDY Using shadow config file stored at /mnt/host/source/src/platform/dev/shadow_xbuddy_config.ini 19:26:58: INFO: [21/Mar/2015:19:26:58] XBUDDY Linking to /mnt/host/source/devserver/static/x86-generic/R41-6680.77.2015_03_21_1849-a1 from /mnt/host/source/src/build/images/x86-generic/R41-6680.77.2015_03_21_1849-a1 19:26:58: INFO: [21/Mar/2015:19:26:58] XBUDDY Get artifact 'ANY' with board x86-generic and version latest'. Locally? True 19:26:58: INFO: [21/Mar/2015:19:26:58] XBUDDY Updating timestamp for x86-generic/R41-6680.77.2015_03_21_1849-a1 19:26:58: INFO: [21/Mar/2015:19:26:58] XBUDDY Returning path to payload: x86-generic/R41-6680.77.2015_03_21_1849-a1/chromiumos_image.bin 19:26:58: INFO: Using image x86-generic/R41-6680.77.2015_03_21_1849-a1/chromiumos_image.bin 19:26:58: INFO: RunCommand: sudo 'CROS_CACHEDIR=/mnt/host/source/.cache' -- /bin/bash -c 'pv -pretb /mnt/host/source/src/build/images/x86-generic/R41-6680.77.2015_03_21_1849-a1/chromiumos_image.bin | dd of=/dev/sdb bs=4M iflag=fullblock oflag=sync' 2.41GiB 0:16:50 [2.44MiB/s] [=========================================================================================>] 100% 617+1 レコード入力 617+1 レコード出力 2589949952 バイト (2.6 GB) コピーされました、 1011.67 秒、 2.6 MB/秒 19:43:50: INFO: RunCommand: sudo 'CROS_CACHEDIR=/mnt/host/source/.cache' -- sync 19:43:52: INFO: Cros Flash completed successfully.
これで作成したUSBメモリを使ってVAIO Type PでChromium OSをブートしてみました。
今回はESCを押した後のbootコマンドで
chromeos-usb.A root=/dev/sda3 init=/sbin/init
とすることでブートできました。 Haxxeh版に比べるとかなりレスポンスが良くなっています。でも軽いとまでは言えない感じです。相変わらずHDDは認識しません。
とりあえず自分でビルドしてみた感触ですが、デフォルトでビルドするだけならば、思っていたよりは難しくないですね。ガイドの通りにやればとりあえずできました。ただ、ものがでかいだけに時間はかなりかかります。
いろいろいじって、VAIO Type Pでいい感じに動くようにもっていきたいのですが、果たしてうまくいくんだろうか。。。
とりあえず今回はここまで。
[関連記事]
[悲報] 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のカーネルをVAIO Type P向けに再構築する
Hexxeh版Chromium OSをVAIO Type Pにインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
PR
2014/03/16 (Sun) 21:13
<'15/09/08追記>
VAIO Type Pで動作するChromium OSのカスタムビルドを公開しました。このビルドでは以下に書いたような問題は起きません。興味がおありでしたらお試しいただければと思います。
前回はVAIO Type PでUSBメモリからChromium OSを起動してみました。
今回はHDDにインストールしてみようとしてみたのですが、どうもHDDを認識してくれないっぽい。どうしてだろうと思っていろいろ調べたのですが、どうやらHexxeh版のLinuxカーネルにはPATAドライバが組み込まれていないようなのです。
以下がHexxeh版のLinuxカーネルのCONFIG内容の抜粋です。
これはVAIO Type PのHDDにインストールしようと思ったら自分でChromium OSをビルドしないといけない、ということのようですね。う~ん、そこまでやるか、どうしようかな。。。
ちなみに、前回動かしたとき、描画処理がもっさりでしたが、カーネル自体にはGMA500のドライバが組み込まれているようです。
/var/log/messagesを見るとgma500を認識している形跡はあるのですが、でもなんか描画はすごく遅い感じです。
ということで、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のカーネルをVAIO Type P向けに再構築する
Chromium OSのビルド環境を作る
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ
VAIO Type Pで動作するChromium OSのカスタムビルドを公開しました。このビルドでは以下に書いたような問題は起きません。興味がおありでしたらお試しいただければと思います。
前回はVAIO Type PでUSBメモリからChromium OSを起動してみました。
今回はHDDにインストールしてみようとしてみたのですが、どうもHDDを認識してくれないっぽい。どうしてだろうと思っていろいろ調べたのですが、どうやらHexxeh版のLinuxカーネルにはPATAドライバが組み込まれていないようなのです。
以下がHexxeh版のLinuxカーネルのCONFIG内容の抜粋です。
$ grep "_PATA_" /mnt/boot/config-3.4.0 # 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 is not set # 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 is not set # CONFIG_PATA_LEGACY is not setことごとく not setでした。。。
これはVAIO Type PのHDDにインストールしようと思ったら自分でChromium OSをビルドしないといけない、ということのようですね。う~ん、そこまでやるか、どうしようかな。。。
ちなみに、前回動かしたとき、描画処理がもっさりでしたが、カーネル自体にはGMA500のドライバが組み込まれているようです。
$ grep "_GMA" /mnt/boot/config-3.4.0 CONFIG_DRM_GMA500=y CONFIG_DRM_GMA600=y CONFIG_DRM_GMA3600=y
/var/log/messagesを見るとgma500を認識している形跡はあるのですが、でもなんか描画はすごく遅い感じです。
ということで、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のカーネルをVAIO Type P向けに再構築する
Chromium OSのビルド環境を作る
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
2014/03/15 (Sat) 21:18
※15.08.14 追記:以下の記述は古いhexxeh版での話です。新しいビルドであればルートパーティションを装置名ではなくパーティションUUIDで指定しているため、以下のようにいちいちbootプロンプトでrootパラメータを指定しなくても起動します。
'15.09,08追記:VAIO Type Pで動作するChromium OSのカスタムビルドを公開しました。興味がおありでしたらお試しいただければと思います。
VAIO Type P(VGN-P61S)でUSBメモリからChromium OSをブートしようとしてはまったのでメモ。
ブート用USBメモリはLinuxで作成しています。
スティックポインターも無線LANも問題なく使えます。ただ、キーレスポンスがすごく悪いです。描画も全体的にかなり重いです。
おそらく描画関係がVAIO Type Pに最適化されていないせいだと思いますが、このままではちょっと使えないかなという感じです。最適化する方法があるかどうか少し探してみるかな。
[関連記事]
[悲報] 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のカーネルをVAIO Type P向けに再構築する
Chromium OSのビルド環境を作る
Hexxeh版Chromium OSをVAIO Type Pにインストールしようとして挫折した話
'15.09,08追記:VAIO Type Pで動作するChromium OSのカスタムビルドを公開しました。興味がおありでしたらお試しいただければと思います。
VAIO Type P(VGN-P61S)でUSBメモリからChromium OSをブートしようとしてはまったのでメモ。
ブート用USBメモリはLinuxで作成しています。
- 以下のURLからChromium OSのUSBメモリ用イメージファイルをダウンロードします。
http://chromeos.hexxeh.net/
こちらの"Nightly build links"のところにあるUSBのアイコンをクリックして
ChromeOS-Vanilla-4028.0.2013_04_20_1810-r706c4144.zip
をダウンロードします。 - ダウンロードしたファイルを解凍して、USBメモリに書き込みます。この例ではUSBメモリは/dev/sdjにつながっています。実際の環境に合わせて書き換えてください。
linux$ unzip ChromeOS-Vanilla-4028.0.2013_04_20_1810-r706c4144.zip linux$ sudo dd if=ChromeOS-Vanilla-4028.0.2013_04_20_1810-r706c4144.img of=/dev/sdj
- できたUSBメモリをVAIOに差し込んで電源を入れます。。。と画面が真っ黒になったまま起動しません。ここではまりました。実際には以下の手順で作業する必要がありました。
- USBメモリを入れて電源を投入し、BIOS起動が終了してChromium OSの起動が始まるタイミングですかさずESCを押します。
- 以下のように表示されます。
aborted
boot:
- このboot: に続けて以下のコマンドを入力します。
boot: chromeos-usb.A root=/dev/sda3
"="が"^"キーになっているので注意です。 - これで無事USBから起動が始まりました。
スティックポインターも無線LANも問題なく使えます。ただ、キーレスポンスがすごく悪いです。描画も全体的にかなり重いです。
おそらく描画関係がVAIO Type Pに最適化されていないせいだと思いますが、このままではちょっと使えないかなという感じです。最適化する方法があるかどうか少し探してみるかな。
[関連記事]
[悲報] 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のカーネルをVAIO Type P向けに再構築する
Chromium OSのビルド環境を作る
Hexxeh版Chromium OSをVAIO Type Pにインストールしようとして挫折した話
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
2014/03/11 (Tue) 22:53
以前こちらとこちらの記事でsimhで動くUNIX V7とホストOSのLinuxでUUCPで通信できるように設定してみましたが、UUCPの設定をしていれば、メールの送受信もできるはず、ということで試してみました。
Linux側のMTA(postfix)の設定はCentOSインストール時のままで何も変えていません。
手順は簡単で、まずUNIX V7側で以下のコマンドを実行します。
(今回はrootユーザで試してみました)
mailコマンドの引数で、アドレスとしてcentos6のユーザーuserあてにメールを送るように指示しています。
それからLinux側で以下のコマンドを実行します。以前も書きましたがUNIX V7は着信専用なのでLinux側からつなぎに行っています。
uulogコマンドでLinux側のUUCPログを見ると以下のように出力されていました。
メールは以下のような内容でちゃんと届きました。
ちゃんとPostfixの設定をしていないのでいろいろ怪しいですが、一応届きましたね。
ちゃんと設定すればUNIX V7からLinux経由で外の世界にメールを送ることもできるんでしょうね。ちょっとおもしろそうです。気が向いたらやってみるかもしれません。
UNIX V7のmailコマンドのソースを見ると、宛先に"!"が含まれているとuuxコマンドを使ってリモートサイトのrmailコマンドを起動してメールを送信するようになっています。該当箇所のソースを抜粋するとこんな感じです。
で、よくわからないのが、
UNIX V7にはmailコマンドはあるがrmailコマンドが存在しない、
ということです。 UNIX V7どうしでメールをやり取りしていた時は一体どうなっていたんでしょうか。
Linuxでman rmailを実行すると、以下の記述があります。
4.2BSDがリリースされたのはWikiによると1983年だそうです。
一方、UNIX V7のmail.cのファイル日付は1979年になっています。
う~ん、よくわかりませんね。。。
[関連記事]
Linux側のMTA(postfix)の設定はCentOSインストール時のままで何も変えていません。
手順は簡単で、まずUNIX V7側で以下のコマンドを実行します。
(今回はrootユーザで試してみました)
unixv7# mail centos6!user uucp mail test (Ctrl+D) unixv7#
mailコマンドの引数で、アドレスとしてcentos6のユーザーuserあてにメールを送るように指示しています。
それからLinux側で以下のコマンドを実行します。以前も書きましたがUNIX V7は着信専用なのでLinux側からつなぎに行っています。
linux$ uucico -S unixv7
uulogコマンドでLinux側のUUCPログを見ると以下のように出力されていました。
uucico unixv7 - (2014-03-11 22:10:42.19 7622) Calling system unixv7 (port TCP) uucico unixv7 - (2014-03-11 22:10:42.73 7622) Login successful uucico unixv7 - (2014-03-11 22:10:42.91 7622) Handshake successful (protocol 'g' sending packet/window 64/3 receiving 64/7) uucico unixv7 root (2014-03-11 22:10:43.06 7622) Receiving D.centos6B0008 uucico unixv7 root (2014-03-11 22:10:43.25 7622) Receiving X.mynameX0006 uucico unixv7 - (2014-03-11 22:10:43.34 7622) Protocol 'g' packets: sent 7, resent 0, received 10 uucico unixv7 - (2014-03-11 22:10:43.40 7622) Call complete (1 seconds 139 bytes 139 bps) uuxqt unixv7 root (2014-03-11 22:10:44.41 7627) Executing X.mynameX0006 (rmail user)
メールは以下のような内容でちゃんと届きました。
Message 56: From root@where.localdomain Tue Mar 11 22:10:44 2014 Return-Path: <root@where.localdomain> X-Original-To: user Delivered-To: user@centos6.localdomain Date: Tue, 11 Mar 2014 22:10:44 +0900 (JST) From: root@where.localdomain (uucp) To: undisclosed-recipients:; Status: R uucp mail test
ちゃんとPostfixの設定をしていないのでいろいろ怪しいですが、一応届きましたね。
ちゃんと設定すればUNIX V7からLinux経由で外の世界にメールを送ることもできるんでしょうね。ちょっとおもしろそうです。気が向いたらやってみるかもしれません。
UNIX V7のmailコマンドのソースを見ると、宛先に"!"が含まれているとuuxコマンドを使ってリモートサイトのrmailコマンドを起動してメールを送信するようになっています。該当箇所のソースを抜粋するとこんな感じです。
sendrmt(n, name) char *name; { (略) if (local) sprintf(cmd, "mail %s", rsys); else { if (index(name+1, '!')) sprintf(cmd, "uux - %s!rmail \\(%s\\)", rsys, name+1); else sprintf(cmd, "uux - %s!rmail %s", rsys, name+1); }
で、よくわからないのが、
UNIX V7にはmailコマンドはあるがrmailコマンドが存在しない、
ということです。 UNIX V7どうしでメールをやり取りしていた時は一体どうなっていたんでしょうか。
Linuxでman rmailを実行すると、以下の記述があります。
歴史 rmail プログラムは 4.2BSD から登場しました。
4.2BSDがリリースされたのはWikiによると1983年だそうです。
一方、UNIX V7のmail.cのファイル日付は1979年になっています。
う~ん、よくわかりませんね。。。
[関連記事]
- [simh-pdp11]UNIX V7とLinuxでUUCP(2)
- [simh-pdp11]UNIX V7とLinuxでUUCP(1)
- [simh-pdp11]UNIX V7の日付まわりを修正する
- [simh-pdp11]UNIX V7に外部からTELNETできるようにする part2
- [simh-pdp11]UNIX V7に外部からTELNETできるようにする
- [simh-pdp11] UNIX V7をテープイメージからインストールする
- [simh-pdp11] Version 7 Unixをインストールする
- simhをインストールしてみる
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
2014/03/09 (Sun) 16:58
使おうとした4GBのUSBメモリが2GBずつ2つのパーティションに分かれていて、1つに戻したかったのでLinux(CentOS6.4)を使って作業しました。
その時のメモです。作業はすべてrootで行います。
この方法で作成したUSBメモリのパーティションに書き込んだubuntuで無事にブートすることができました。
その時のメモです。作業はすべてrootで行います。
- USBメモリをLinuxにつなぐ
- USBメモリのスペシャルファイル名を調べる。
あらかじめUSBメモリのラベル名がわかっているなら、/dev/disk/by-labelにできたシンボリックリンクが指し示す実体を見ればわかります。
linux# cd /dev/disk/by-label linux# ls -l lrwxrwxrwx. 1 root root 10 3\u6708 9 16:04 2014 HDDREG -> ../../sdj1
この例ではUSBメモリにHDDREGというラベルがついていて、それの実体が/dev/sdj1であることがわかります。よってUSBメモリのスペシャルファイル名は/dev/sdjになります。
念のため、fdisk -lを実行してパーティションの状態を確認します。
linux# fdisk -l (略) ディスク /dev/sdj: 4001 MB, 4001366016 バイト ヘッド 64, セクタ 32, シリンダ 3816 Units = シリンダ数 of 2048 * 512 = 1048576 バイト セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O size (minimum/optimal): 512 bytes / 512 bytes ディスク識別子: 0x00000000 デバイス ブート 始点 終点 ブロック Id システム /dev/sdj1 * 1 1967 2014192 e W95 FAT16 (LBA)
ファイルシステムがW95 F16なのでUSBメモリと考えて問題なさそうです。これを間違えてしまうと大変なことになるので慎重に調べます。不安なら/dev/disk/by-idや/dev/disk/by-pathでls -lコマンドを実行するのも効果的です。たいてい"usb"という文字列が含まれているシンボリックリンクがあります。今回の例を示すと以下のようになります。
linux# ls -l /dev/disk/by-id (略) lrwxrwxrwx. 1 root root 9 3\u6708 9 16:31 2014 usb-Sony_Storage_Media_9B2001102180001905-0:0 -> ../../sdj lrwxrwxrwx. 1 root root 10 3\u6708 9 16:31 2014 usb-Sony_Storage_Media_9B2001102180001905-0:0-part1 -> ../../sdj1 (略) linux# ls -l /dev/disk/by-path (略) lrwxrwxrwx. 1 root root 9 3\u6708 9 16:31 2014 pci-0000:00:1a.0-usb-0:1.4:1.0-scsi-0:0:0:0 -> ../../sdj lrwxrwxrwx. 1 root root 10 3\u6708 9 16:31 2014 pci-0000:00:1a.0-usb-0:1.4:1.0-scsi-0:0:0:0-part1 -> ../../sdj1 (略)
- 以下のコマンドでUSBの先頭にあるパーティションテーブルを消します。
ofがHDDだと大変なことになるので上に書いたように慎重に確認しておく必要があります。
linux# dd if=/dev/zero of=/dev/sdj bs=512 count=64 64+0 records in 64+0 records out 32768 bytes (33 kB) copied, 0.013923 s, 2.4 MB/s
念のためにsyncしておきます。linux# sync
- あとは普通にfdiskでパーティションを切ります。
linux# fdisk /dev/sdj 警告: DOS互換モードは廃止予定です。このモード (コマンド 'c') を止めることを 強く推奨します。 and change display units to sectors (command 'u'). コマンド (m でヘルプ): d 選択した領域 1 コマンド (m でヘルプ): p ディスク /dev/sdj: 4001 MB, 4001366016 バイト ヘッド 64, セクタ 32, シリンダ 3816 Units = シリンダ数 of 2048 * 512 = 1048576 バイト セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O size (minimum/optimal): 512 bytes / 512 bytes ディスク識別子: 0x00000000 デバイス ブート 始点 終点 ブロック Id システム コマンド (m でヘルプ): n コマンドアクション e 拡張 p 基本パーティション (1-4) p パーティション番号 (1-4): 1 最初 シリンダ (1-3816, 初期値 1): 初期値 1 を使います Last シリンダ, +シリンダ数 or +size{K,M,G} (1-3816, 初期値 3816): 初期値 3816 を使います コマンド (m でヘルプ): p ディスク /dev/sdj: 4001 MB, 4001366016 バイト ヘッド 64, セクタ 32, シリンダ 3816 Units = シリンダ数 of 2048 * 512 = 1048576 バイト セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O size (minimum/optimal): 512 bytes / 512 bytes ディスク識別子: 0x00000000 デバイス ブート 始点 終点 ブロック Id システム /dev/sdj1 1 3816 3907568 83 Linux コマンド (m でヘルプ): t 選択した領域 1 16進数コード (L コマンドでコードリスト表示): b 領域のシステムタイプを 1 から b (W95 FAT32) に変更しました コマンド (m でヘルプ): p ディスク /dev/sdj: 4001 MB, 4001366016 バイト ヘッド 64, セクタ 32, シリンダ 3816 Units = シリンダ数 of 2048 * 512 = 1048576 バイト セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O size (minimum/optimal): 512 bytes / 512 bytes ディスク識別子: 0x00000000 デバイス ブート 始点 終点 ブロック Id システム /dev/sdj1 1 3816 3907568 b W95 FAT32 コマンド (m でヘルプ): w パーティションテーブルは変更されました! ioctl() を呼び出してパーティションテーブルを再読込みします。 警告: DOS 6.x パーティションを作成、または変更してしまった場合は、 fdisk マニュアルの追加情報ページを参照してください。 ディスクを同期しています。 linux#
この方法で作成したUSBメモリのパーティションに書き込んだubuntuで無事にブートすることができました。
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
プロフィール
HN:
zui
性別:
非公開
カテゴリー
最新記事
(09/28)
(09/03)
(08/26)
(07/23)
(05/24)
PR
忍者カウンター