2015/12/03 (Thu) 22:20
12/1にGoogle GroupのChromium-devグループに以下のタイトルで投稿がありました。
Updates to Google Chrome Linux support
これによると、来年3月で32bit版Linux用Chromeブラウザの更新を止めるとのことです。 一部で報道もされているようですし、twitterにもツイートがかなり流れてきています。
前回のChromeのWindows XPサポート停止の件はGoogleのChrome Blogでアナウンスされていましたが、今回の話はChromium-devグループの投稿がソースなので、まだ正式発表というわけではないのかもしれません。ただ、Chromiumの開発メンバーが実名でデタラメを流すとも思えないので信ぴょう性は高いのでしょう、きっと。
この件は、配布しているChromium OS カスタムビルドの観点からは、
来年3月以降Flashが事実上使えなくなるかもしれない
という非常に大きな問題につながるのでちょっと洒落になりません。
上記URLのスレッドには、
If so, that'll certainly change when we stop offering the 32-bit download, 〜
という記述もあるので、来年3月以降すぐかしばらくしてかはわかりませんが、更新が止まるだけでなく最終リリースのパッケージもいずれ削除されてダウンロードできなくなると思われます。
今のカスタムビルドはPentium M対応のこともあって32bit版でリリースしており、Flashのインストールをこの今問題になっている32bit版Linux用Chromeブラウザのパッケージを使って行っています。
なので、Googleが提供をやめればカスタムビルドのFlash対応もそこで打ち止めとなります。
Chromium開発チームはChromiumブラウザは来年3月以降も32bit Linux向けにビルドできるようにするからそっちを使えと言っていますが問題なのはそこじゃなくてFlashなのです。これがどうなるか正確な情報はありませんが、普通に考えれば同時に提供中止となるというのが自然な流れでしょう。
現状カスタムビルドではアップデートの際にFlashが消えてしまう仕様になっています。
これはFlashはしょっちゅうセキュリティアップデートがあるのでChromium OSのアップデートのタイミングで半ば強制的にFlashも入れ替えてもらい、最新に状態を保ってもらう、という意図もありました。
ただ、これはあくまでもChromeが継続的にリリースされていることが前提です。Chromeのリリースが止まるならこういう仕様ではさすがに問題があります。Chromeのリリース終了後にChromium OSをアップデートしたらFlashが消えてしまいもう二度と入手できません、ではさすがに怒られてしまいます。
なので、FlashについてはChromium OSのアップデート後も継続して以前のものが使えるように変更しようと思います（更新ももちろんできます。3月までですがｗ）。ただ、今リリース準備しているR47-7520.55にはさすがに間に合いませんのでもう１つか２つ先のアップデートででも直そうかと思います。ただ、あのしょっちゅうセキュリティアップデートしているFlashを更新なしで延々と使い続けることになるので正直現実的とは思えません。ないよりマシ（ほんとか？）というだけです。
また、来年3月以降にこのカスタムビルドに出会う人がいれば、その人には救う手段はありません。
この問題はUbuntuやDebianなどの32bit版でも起きるはずです。
これらのディストリビューションではpepperflashplugin-nonfreeというパッケージでChromiumブラウザにFlashプラグインを導入できるようにしていますが、中でやっていることは上で書いたカスタムビルドのケースと同じで、ChromeのパッケージからFlashプラグインを引っこ抜いてChromiumで使えるようにする、ということなので、こちらも今のままではChromeの提供終了と同時におわります。
これらの救済のためにもPepper Flashプラグインだけで単体リリースしてくれればいいんですが。
もしそうなれば、いまmp3対応でやっているのと同じような方法で、カスタムビルドでもFlash対応を継続できる可能性が残るんですが。。。
ちなみに、Chromebookのx86版は調べた限りでは2011年7月に出たAcer AC700が最後のようで、これのEOLが来年の7月になります。こいつのアップデートペイロードをダウンロードしてそこから引っこ抜けば7月まではFlashつかえるかもしれませんｗ。でもそのためにはAC700の実機から公開鍵をとってこないとダメでしょうから実機をデベロッパーモードにしてそこから引っこ抜いたほうが早かったりします。まあ、仮にペイロードから抜けたとしてもそんなスクリプトを配ったりしたら怒られちゃいますがｗ。
とにかく，そこでLinux系列の32bit版Pepper Flashは絶滅ということになるのかな。そのうちGoogleから正式にアナウンスあるでしょうし、様子を見守ろうと思います。
Updates to Google Chrome Linux support
これによると、来年3月で32bit版Linux用Chromeブラウザの更新を止めるとのことです。 一部で報道もされているようですし、twitterにもツイートがかなり流れてきています。
前回のChromeのWindows XPサポート停止の件はGoogleのChrome Blogでアナウンスされていましたが、今回の話はChromium-devグループの投稿がソースなので、まだ正式発表というわけではないのかもしれません。ただ、Chromiumの開発メンバーが実名でデタラメを流すとも思えないので信ぴょう性は高いのでしょう、きっと。
この件は、配布しているChromium OS カスタムビルドの観点からは、
来年3月以降Flashが事実上使えなくなるかもしれない
という非常に大きな問題につながるのでちょっと洒落になりません。
上記URLのスレッドには、
If so, that'll certainly change when we stop offering the 32-bit download, 〜
という記述もあるので、来年3月以降すぐかしばらくしてかはわかりませんが、更新が止まるだけでなく最終リリースのパッケージもいずれ削除されてダウンロードできなくなると思われます。
今のカスタムビルドはPentium M対応のこともあって32bit版でリリースしており、Flashのインストールをこの今問題になっている32bit版Linux用Chromeブラウザのパッケージを使って行っています。
なので、Googleが提供をやめればカスタムビルドのFlash対応もそこで打ち止めとなります。
Chromium開発チームはChromiumブラウザは来年3月以降も32bit Linux向けにビルドできるようにするからそっちを使えと言っていますが問題なのはそこじゃなくてFlashなのです。これがどうなるか正確な情報はありませんが、普通に考えれば同時に提供中止となるというのが自然な流れでしょう。
現状カスタムビルドではアップデートの際にFlashが消えてしまう仕様になっています。
これはFlashはしょっちゅうセキュリティアップデートがあるのでChromium OSのアップデートのタイミングで半ば強制的にFlashも入れ替えてもらい、最新に状態を保ってもらう、という意図もありました。
ただ、これはあくまでもChromeが継続的にリリースされていることが前提です。Chromeのリリースが止まるならこういう仕様ではさすがに問題があります。Chromeのリリース終了後にChromium OSをアップデートしたらFlashが消えてしまいもう二度と入手できません、ではさすがに怒られてしまいます。
なので、FlashについてはChromium OSのアップデート後も継続して以前のものが使えるように変更しようと思います（更新ももちろんできます。3月までですがｗ）。ただ、今リリース準備しているR47-7520.55にはさすがに間に合いませんのでもう１つか２つ先のアップデートででも直そうかと思います。ただ、あのしょっちゅうセキュリティアップデートしているFlashを更新なしで延々と使い続けることになるので正直現実的とは思えません。ないよりマシ（ほんとか？）というだけです。
また、来年3月以降にこのカスタムビルドに出会う人がいれば、その人には救う手段はありません。
この問題はUbuntuやDebianなどの32bit版でも起きるはずです。
これらのディストリビューションではpepperflashplugin-nonfreeというパッケージでChromiumブラウザにFlashプラグインを導入できるようにしていますが、中でやっていることは上で書いたカスタムビルドのケースと同じで、ChromeのパッケージからFlashプラグインを引っこ抜いてChromiumで使えるようにする、ということなので、こちらも今のままではChromeの提供終了と同時におわります。
これらの救済のためにもPepper Flashプラグインだけで単体リリースしてくれればいいんですが。
もしそうなれば、いまmp3対応でやっているのと同じような方法で、カスタムビルドでもFlash対応を継続できる可能性が残るんですが。。。
ちなみに、Chromebookのx86版は調べた限りでは2011年7月に出たAcer AC700が最後のようで、これのEOLが来年の7月になります。こいつのアップデートペイロードをダウンロードしてそこから引っこ抜けば7月まではFlashつかえるかもしれませんｗ。でもそのためにはAC700の実機から公開鍵をとってこないとダメでしょうから実機をデベロッパーモードにしてそこから引っこ抜いたほうが早かったりします。まあ、仮にペイロードから抜けたとしてもそんなスクリプトを配ったりしたら怒られちゃいますがｗ。
とにかく，そこでLinux系列の32bit版Pepper Flashは絶滅ということになるのかな。そのうちGoogleから正式にアナウンスあるでしょうし、様子を見守ろうと思います。
[8回]
PR
2015/07/24 (Fri) 02:30
長いことブログをサボってましたが、その間もちょくちょくChromium OSはいじってまして、ちょっと気になることがあったので久しぶりに記事に書きます。
Chromeが7/21のStable Channel Updateで R44になりましたが、このバージョンからffmpegsumoがインストールパッケージの中から消えてしまいました。
ffmpegsumoはChrome/Chromiumで音声/映像を再生するためのコーデックを集めたプラグインで、LinuxやChromium OSではlibffmpegsumo.soというファイル名です。
これがどこに行ったかというと、なんとスタティックリンクされてchrome本体にffmpegが吸収されてしまったようです。
この修正のコミット内容はこちらで見ることができます。
https://chromium.googlesource.com/chromium/src/+/ab31fe6077d2ba3ede9a302d9ef4554363c9a939
これがなくなると、mp3, mp4, aacなど、デコーダの配布にライセンスが必要とされているフォーマットの音声・映像データをChromium OSで再生することができなくなってしまいます。
Chromium OSのようなフリーのOSでは、デコーダの配布にライセンス料がかかるようなコーデックを含めることはできませんので、Chromium OSに付いているlibffmpegsumo.soは有料コーデックを除いた状態になっています。そして、これを各ユーザが独自にChrome添付のlibffmpegsumo.soに置き換えることでmp3などを使えるようにしていました。
ところが、今回からプラグインの供給元だったChromeのパッケージからこれが消えてしまったわけですから、もはや今までの方法は使えなくなってしまいました。
この辺はライセンス的に本当にクリーンなのかよくわかりませんが、LinuxのChromiumブラウザ(Chromeではない)でも似たようなことをし ていて、例えばubuntuでも標準のChromiumブラウザのパッケージには有料コーデックなしのlibffmpegsumoが入っており、mp3な どのコーデックを含んだlibffmpegsumoを組み込むためのパッケージとして、chromium-codecs-ffmpeg-extraというものが別に用意されています（これの配布 ライセンスがどうなっているかはよくわかりませんが）。
ということでこの問題はLinuxのChromiumブラウザにも影響があるわけで、以下のURLでLinux視点での議論の内容を見ることができます。
https://groups.google.com/a/chromium.org/forum/#!msg/chromium-packagers/R5rcZXWxBEQ/B6k0zzmJbvcJ
これを見ると、Chromiumのビルド設定を変えてプラグインではなくffmpegの普通の共有ライブラリ(libffmpeg.so)を使うように修正し、今までのlibffmpegsumo.soの代わりにlibffmpeg.soを取り替える、という方法で対処する、という方針のようです。これであれば、最悪個人でffmpegをビルドすれば対応できるので、どうにもならずに詰む、という状況は避けられます。
まだR44のchromium-codecs-ffmpeg-extraは出ていないようなので具体的な形は見えませんが、もうしばらくすればLinuxでは何らかの方法で対応が進むんじゃないでしょうか。配布ライセンスの問題をどうクリアするのかはわかりませんが。
一方、Chromium OSですが、R44のSDKではそのままビルドすると依然としてlibffmpegsumo.soを使う形でビルドされます。もう代わりのlibffmpegsumo.soは存在しませんからこの形でビルドして配布されているChromium OSを使うと、今後mp3/4/aacはどうやっても再生できないという事になります。
R45以降は自分では試していませんが他の人がビルドしたものを見るとスタティックリンクに変わっているようですので、これもやはりどうしようもありません。
なので、Chromium OSのビルダーさんたちがこの辺の問題を認識してビルド方法をLinuxと同じように変えてくれるまでは一般のユーザさんはどうにも対応できないことになります。
あと、仮にビルド方法を変えてもらったとしても、今度はChroium OS用のlibffmpeg.soをどこから調達するのか、という問題が発生します。他のLinux用にビルドされたものを持ってきてもそのまま動くとは限りません。Chrome/Chromiumのプラグインだったffmpegsumoと違ってlibffmpeg.soはただの共有ライブラリですから、それが更に他のライブラリをリンクしていればそれらも持ってこなければいけないでしょうし、ライブラリのバージョンの問題もありそうです。
なので、確実に動かすためにはChromium OS用にlibffmpeg.soをビルドしなければなりませんが、ライセンスの問題で個人がビルドしたものは配布できないわけです。さぁ困りましたｗ
おそらく解としては各ユーザがChromebrewやCroutonを導入して実機上でffmpegをビルドする、という形に落ち着くような気がします。ファイル１個コピーすれば済んでいたものがこうなってしまうというのはエラいことになっちゃったなぁ、という感じです。
個人としてChromium OSをスクラッチからビルドするのであれば、配布するわけではないのでmp3/4/aacを有効にしてビルドすることでこのへんの問題を回避することは一応可能ですが、それははもっとハードルが高くなるので問題の一般的な解決策にはならないですよね。。
’15.09.26 追記
UbuntuでChromiumブラウザ R45の配布が始まりましたが、このR45からchromium-codecs-ffmpeg-extraパッケージに含まれるファイルがlibffmpegsumo.soからlibffmpeg.soに切り替わりました。
こちらのファイルリストには依然としてlibffmpegsumo.soがありますが、これは間違いで、パッケージを展開すればlibffmpeg.soが入っているのが確認できます。上に載せたURLでの議論が反映されたようです。
今度リリースしたChromium OS カスタムビルドのアップデート版(R45-7262.57)では、このUbuntu 14.04 32bit版のchromium-codecs-ffmpeg-extraパッケージに含まれるlibffmpeg.soを導入することでmp3, mp4, aacの再生ができることを確認しています。導入手順をこちらのページで公開しています。
［関連記事］
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にインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ
Chromeが7/21のStable Channel Updateで R44になりましたが、このバージョンからffmpegsumoがインストールパッケージの中から消えてしまいました。
ffmpegsumoはChrome/Chromiumで音声/映像を再生するためのコーデックを集めたプラグインで、LinuxやChromium OSではlibffmpegsumo.soというファイル名です。
これがどこに行ったかというと、なんとスタティックリンクされてchrome本体にffmpegが吸収されてしまったようです。
この修正のコミット内容はこちらで見ることができます。
https://chromium.googlesource.com/chromium/src/+/ab31fe6077d2ba3ede9a302d9ef4554363c9a939
これがなくなると、mp3, mp4, aacなど、デコーダの配布にライセンスが必要とされているフォーマットの音声・映像データをChromium OSで再生することができなくなってしまいます。
Chromium OSのようなフリーのOSでは、デコーダの配布にライセンス料がかかるようなコーデックを含めることはできませんので、Chromium OSに付いているlibffmpegsumo.soは有料コーデックを除いた状態になっています。そして、これを各ユーザが独自にChrome添付のlibffmpegsumo.soに置き換えることでmp3などを使えるようにしていました。
ところが、今回からプラグインの供給元だったChromeのパッケージからこれが消えてしまったわけですから、もはや今までの方法は使えなくなってしまいました。
この辺はライセンス的に本当にクリーンなのかよくわかりませんが、LinuxのChromiumブラウザ(Chromeではない)でも似たようなことをし ていて、例えばubuntuでも標準のChromiumブラウザのパッケージには有料コーデックなしのlibffmpegsumoが入っており、mp3な どのコーデックを含んだlibffmpegsumoを組み込むためのパッケージとして、chromium-codecs-ffmpeg-extraというものが別に用意されています（これの配布 ライセンスがどうなっているかはよくわかりませんが）。
ということでこの問題はLinuxのChromiumブラウザにも影響があるわけで、以下のURLでLinux視点での議論の内容を見ることができます。
https://groups.google.com/a/chromium.org/forum/#!msg/chromium-packagers/R5rcZXWxBEQ/B6k0zzmJbvcJ
これを見ると、Chromiumのビルド設定を変えてプラグインではなくffmpegの普通の共有ライブラリ(libffmpeg.so)を使うように修正し、今までのlibffmpegsumo.soの代わりにlibffmpeg.soを取り替える、という方法で対処する、という方針のようです。これであれば、最悪個人でffmpegをビルドすれば対応できるので、どうにもならずに詰む、という状況は避けられます。
まだR44のchromium-codecs-ffmpeg-extraは出ていないようなので具体的な形は見えませんが、もうしばらくすればLinuxでは何らかの方法で対応が進むんじゃないでしょうか。配布ライセンスの問題をどうクリアするのかはわかりませんが。
一方、Chromium OSですが、R44のSDKではそのままビルドすると依然としてlibffmpegsumo.soを使う形でビルドされます。もう代わりのlibffmpegsumo.soは存在しませんからこの形でビルドして配布されているChromium OSを使うと、今後mp3/4/aacはどうやっても再生できないという事になります。
R45以降は自分では試していませんが他の人がビルドしたものを見るとスタティックリンクに変わっているようですので、これもやはりどうしようもありません。
なので、Chromium OSのビルダーさんたちがこの辺の問題を認識してビルド方法をLinuxと同じように変えてくれるまでは一般のユーザさんはどうにも対応できないことになります。
あと、仮にビルド方法を変えてもらったとしても、今度はChroium OS用のlibffmpeg.soをどこから調達するのか、という問題が発生します。他のLinux用にビルドされたものを持ってきてもそのまま動くとは限りません。Chrome/Chromiumのプラグインだったffmpegsumoと違ってlibffmpeg.soはただの共有ライブラリですから、それが更に他のライブラリをリンクしていればそれらも持ってこなければいけないでしょうし、ライブラリのバージョンの問題もありそうです。
なので、確実に動かすためにはChromium OS用にlibffmpeg.soをビルドしなければなりませんが、ライセンスの問題で個人がビルドしたものは配布できないわけです。さぁ困りましたｗ
おそらく解としては各ユーザがChromebrewやCroutonを導入して実機上でffmpegをビルドする、という形に落ち着くような気がします。ファイル１個コピーすれば済んでいたものがこうなってしまうというのはエラいことになっちゃったなぁ、という感じです。
個人としてChromium OSをスクラッチからビルドするのであれば、配布するわけではないのでmp3/4/aacを有効にしてビルドすることでこのへんの問題を回避することは一応可能ですが、それははもっとハードルが高くなるので問題の一般的な解決策にはならないですよね。。
’15.09.26 追記
UbuntuでChromiumブラウザ R45の配布が始まりましたが、このR45からchromium-codecs-ffmpeg-extraパッケージに含まれるファイルがlibffmpegsumo.soからlibffmpeg.soに切り替わりました。
こちらのファイルリストには依然としてlibffmpegsumo.soがありますが、これは間違いで、パッケージを展開すればlibffmpeg.soが入っているのが確認できます。上に載せたURLでの議論が反映されたようです。
今度リリースしたChromium OS カスタムビルドのアップデート版(R45-7262.57)では、このUbuntu 14.04 32bit版のchromium-codecs-ffmpeg-extraパッケージに含まれるlibffmpeg.soを導入することでmp3, mp4, aacの再生ができることを確認しています。導入手順をこちらのページで公開しています。
［関連記事］
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にインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ
ランキングに参加してみました。クリックしていただければ嬉しいです。
 にほんブログ村 |
 パソコン ブログランキングへ |
[1回]
2014/05/01 (Thu) 23:14
今回はDev Serverを使ったChromium OSのアップデートやパッケージの追加を試してみようと思います。
今回は公式サイト"The Chromium Project"の"Dev server"のページをほとんどそのまま試していますので正確なことが知りたい方はそちらを参照してください。
Dev serverはChromium OSのビルド環境上で起動することのできるHTTPベースのサーバで、以下のような機能があります。
USBを使ったインストールだとディスクの中身がすべて消えてしまいますが、Dev serverを導入すると更新を行ってもホームディレクトリは消えないのでそれまでの設定を残しつつChromium OSの更新ができるようになりますのでかなり便利です。
Dev serverはChromium OSのSDKの一部ですので、起動するにはChromium OSのSDKが必要です。また、一度は自分でChromium OSのビルドを行っていることが必要です。Chromium OSのビルドの手順はこちらの記事にまとめていますので参考にしていただければと思います。
ビルド環境があるならDev serverの起動は非常に簡単です。cros_sdkでchroot環境を立ち上げてstart_devserverコマンドを実行するだけです。
Dev serverはデフォルトではビルドマシンのTCPポート8080を使用します。変更する場合は--portオプションで変更できます。
Dev serverの標準出力にはログがどんどん出力されますので、Chromium OSの実機から接続があればすぐにわかります。
Chromium OSインストールマシン側でDev serverに接続しに行くための設定は/etc/lsb-releaseというファイルに記述されています。このファイルの下２行に以下のような記述があります。
このdevserverのアドレスには、ビルド環境上でhostname -fを実行して得られる値がChromium OSのビルド時に自動で格納されています。なので、DNSの設定をきちんと行っているなどでChromium OSの実機からビルドマシンのホスト名がきちんと認識できているなら、何も設定しなくてもビルドマシン上でDev serverを起動すればすぐ使えるようになります。
うちはその辺の設定は手を抜いているので、該当箇所をIPアドレスに書き換えて認識させましたｗｗ
Dev serverが立ち上がっており、かつ実機側の/etc/lsb-releaseが正しく設定されているなら、Chromium OSの実機でChromiumブラウザを起動して[設定]－[ヘルプ]を開けば、勝手に接続してバージョン確認を行い、今インストールされているバージョンよりDev server上のビルドイメージのほうが新しければ勝手に更新が始まります。
更新が始まってしばらくすれば以下のように再起動を促す画面が表示されます。
この状態で再起動すれば、以下のように更新されたOSが起動します。
この例では35.0.1902から35.0.1916に更新されています。
私はChromebookは持っていませんので推測ですが、おおむねChromebookと変わらないような感じで更新できているのではないでしょうか。少なくともいちいちUSBに焼いて再インストールするよりははるかにましです。
ただ、厄介といえば厄介なのが、このヘルプページを開くと「勝手に更新が始まってしまう」という点です。
メーカーがビルドしたOSならともかく自分で適当にビルドしたものだと、ふとしたはずみで勝手に更新されてしまうのはちょっと困るという場合もあります。
勝手に更新されるのが嫌なら、/etc/lsb-releaseにはあえてでたらめなアドレスを書いておき、コマンドラインから手動で更新する、という方法があります。
手動で更新を行う場合は、Chromium OSの実機上でCtrl+Alt+F2でターミナルを開き、以下のコマンドを実行します。
このコマンドを実行すると、--omaha_urlで指定したDev server上にある最新のビルドイメージに更新されます。--omaha_urlを省略した場合は/etc/lsb-releaseのCHROMEOS_AUSERVERの値が使われます。
このコマンドを実行すると現在実機にインストールされているバージョンよりDev serverのほうが古くても更新がかかります。
ただ、あくまでも更新対象はDev server上の一番新しいイメージのようです。これをコマンドラインから選択する方法はまだわかっていません。chroot環境を複数持っていれば、古いほうのchroot環境でDev serverを起動することで古いイメージに戻すことができますが、同一chroot環境でいくつもビルドイメージを持っている場合は、今のところサーバ側で細工しない限り古いバージョンへ戻す方法がわかっていません。
なお、この方法ではROOTパーティションが丸ごと新しいイメージに書き換わります。そのため、更新前の環境でROOTパーティションに対して何らかの変更を行っているとその内容がすべて消えます。
一番影響が大きいのは後付けでPDFやFlashなどのプラグインをインストールしているケースだと思いますが、基本的には再度入れなおしになります。
もしかしたらビルド時にlibpepflashplayer.soやlibpdf.soをSTATEパーティションへのシンボリックリンクにしたイメージを作っておいてこれらのプラグインをSTATEパーティションに入れるようにすれば更新時に消えないようにできるかもしれませんが、そもそもこれでちゃんと動くかどうかはまだ試してはいません。
個人で使うだけならビルド時にプラグインを含めてイメージを作っちゃうのが一番楽かもしれませんが、これもまだ試してはいません。
上記の方法で更新されるのはROOTパーティションのみです。/usr/localなどが置かれているSTATEパーティションを更新する場合は、ターミナルからstateful_updateというコマンドを実行する必要があるということです。が、
404エラーが出てしまいました。stateful_updateは
http://devserver_host:8080/static/stateful.tgz
というファイルをダウンロードしに行くようですが、devserverのstatic配下にはstateful.tgzがありません。
Dev server上のstaticディレクトリは、ビルドマシンのchroot環境では/usr/lib/devserver/staticにあたります。この下を見ると以下のようになっています。
ビルドイメージはこのディレクトリのx86-genericの下にシンボリックリンクの形で準備されます。
stateful.tgzはこのバージョン名のシンボリックリンクの下に作られています。
なので、以下のようにstaticディレクトリ配下に最新ビルドのstateful.tgzへのシンボリックリンクを作ります。
この状態で実機上でstateful_updateを実行してみます。
今度はうまくいきました。公式サイトの解説ページにはこんな作業が必要とは書いてありません。なんでこうなってしまうのかはよくわかっていません。
なお、STATEパーティションの更新はコマンド実行終了時点ではまだ行われていません。ここでダウンロードした内容は/mnt/stateful_partition/の下のdev_image_newおよびvar_newというディレクトリに格納され、リブート時に本来のディレクトリであるdev_imageおよびvar_overlayと置換されます。
なお、stateful_updateコマンド実行時に接続しに行くDev serverは、/etc/lsb-releaseのCHROMEOS_DEVSERVERで指定したアドレスになります。
また、STATEパーティションの更新では/home配下は変更されないのでユーザ固有のデータは更新後でも引き継がれます。
Dev serverを使うと、OS自体の更新だけでなく、個別にパッケージを指定して実機に取り込むこともできるようになります。パッケージを個別でインストールするには以下のコマンドを実行します。
$ sudo gmerege [-n] パッケージ名 [--accept_stable]
gmergeコマンドを実行すると、デフォルトではROOTパーティションの/usr/binや/usr/libなどにバイナリがインストールされるようです。インストール先を変更できるかどうかはまだ調べていません。
ここで、-nオプションはDev server上でそのパッケージがすでにビルド済みなら改めてビルドせずにバイナリをダウンロードするように指示します。
また、--accept_stableオプションはビルド環境上の~/trunk/src/third_party/chromiumos-overlay配下にあるパッケージの一部をインストールするときに指定する必要が出てくることがあります。
chromiumos_overlay配下の一部のパッケージをインストールしようとすると以下のようなエラーが出ることがあります。
このエラーが出たときは--accept_stableオプションを指定して再実行するとパッケージのインストールができます。
このエラーがでるのは、chromiumos_overlay配下にあるパッケージで、ebuildファイルのinheritパラメータにcros_workonの記述があるパッケージです。
あまりこの辺の意味はよくわかっていませんが、この辺のパッケージは基本的にOSインストール時にまとめてインストールされるものですので、あらためて、パッケージ単体でインストールするものではない、ということなのでしょう。
cros_workonはそれらのパッケージに対して修正を加える際に実行するコマンドで、それが実行されているならそのパッケージはカスタマイズされていると判断されて実機に追加インストールできるようになっているが、それ以外はガードがかかっており、ガードを外すのが--accept_stableオプション、ということなのだろうと理解しています。
なお、前回の記事ではbinutilsをChromium OSのイメージに導入するのに非常にてこずりましたが、Dev serverからのインストールなら非常に簡単にできました。Chromium OSをいじるうえではDev serverは欠かせないツールになりそうです。
［関連記事］
[悲報] Chrome R44でffmpegsumoが消えた
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にインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ
今回は公式サイト"The Chromium Project"の"Dev server"のページをほとんどそのまま試していますので正確なことが知りたい方はそちらを参照してください。
Dev serverはChromium OSのビルド環境上で起動することのできるHTTPベースのサーバで、以下のような機能があります。
- オートアップデートができる
- 手動での更新も可能
- パッケージ単位でのダウンロード・インストールができる。
このとき、ビルドしていないものであればサーバでパッケージをビルドさせてからそれをダウンロード・インストールすることができる。
USBを使ったインストールだとディスクの中身がすべて消えてしまいますが、Dev serverを導入すると更新を行ってもホームディレクトリは消えないのでそれまでの設定を残しつつChromium OSの更新ができるようになりますのでかなり便利です。
Dev serverの起動
Dev serverはChromium OSのSDKの一部ですので、起動するにはChromium OSのSDKが必要です。また、一度は自分でChromium OSのビルドを行っていることが必要です。Chromium OSのビルドの手順はこちらの記事にまとめていますので参考にしていただければと思います。
ビルド環境があるならDev serverの起動は非常に簡単です。cros_sdkでchroot環境を立ち上げてstart_devserverコマンドを実行するだけです。
chromium@Ubuntu12:~/chromiumR35$ ./chromite/bin/cros_sdk [sudo] password for chromium: (cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ export BOARD=x86-generic (cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ start_devserver [01/May/2014:20:48:50] DEVSERVER Using cache directory /var/lib/devserver/static/cache [01/May/2014:20:48:50] DEVSERVER Serving from /var/lib/devserver/static [01/May/2014:20:48:50] XBUDDY Using shadow config file stored at /mnt/host/source/src/platform/dev/shadow_xbuddy_config.ini [01/May/2014:20:48:50] ENGINE Listening for SIGHUP. [01/May/2014:20:48:50] ENGINE Listening for SIGTERM. [01/May/2014:20:48:50] ENGINE Listening for SIGUSR1. [01/May/2014:20:48:50] ENGINE Bus STARTING [01/May/2014:20:48:50] ENGINE Started monitor thread 'Autoreloader'. [01/May/2014:20:48:50] ENGINE Started monitor thread '_TimeoutMonitor'. [01/May/2014:20:48:50] ENGINE Serving on :::8080 [01/May/2014:20:48:50] ENGINE Bus STARTED
Dev serverはデフォルトではビルドマシンのTCPポート8080を使用します。変更する場合は--portオプションで変更できます。
Dev serverの標準出力にはログがどんどん出力されますので、Chromium OSの実機から接続があればすぐにわかります。
Chromium OS 実機側の設定
Chromium OSインストールマシン側でDev serverに接続しに行くための設定は/etc/lsb-releaseというファイルに記述されています。このファイルの下２行に以下のような記述があります。
CHROMEOS_AUSERVER=http://devserverのアドレス:ポート番号/update CHROMEOS_DEVSERVER=http://devserverのアドレス:ポート番号/
このdevserverのアドレスには、ビルド環境上でhostname -fを実行して得られる値がChromium OSのビルド時に自動で格納されています。なので、DNSの設定をきちんと行っているなどでChromium OSの実機からビルドマシンのホスト名がきちんと認識できているなら、何も設定しなくてもビルドマシン上でDev serverを起動すればすぐ使えるようになります。
うちはその辺の設定は手を抜いているので、該当箇所をIPアドレスに書き換えて認識させましたｗｗ
Dev serverによるChromium OSの更新
Dev serverが立ち上がっており、かつ実機側の/etc/lsb-releaseが正しく設定されているなら、Chromium OSの実機でChromiumブラウザを起動して[設定]－[ヘルプ]を開けば、勝手に接続してバージョン確認を行い、今インストールされているバージョンよりDev server上のビルドイメージのほうが新しければ勝手に更新が始まります。
更新が始まってしばらくすれば以下のように再起動を促す画面が表示されます。
この状態で再起動すれば、以下のように更新されたOSが起動します。
この例では35.0.1902から35.0.1916に更新されています。
私はChromebookは持っていませんので推測ですが、おおむねChromebookと変わらないような感じで更新できているのではないでしょうか。少なくともいちいちUSBに焼いて再インストールするよりははるかにましです。
ただ、厄介といえば厄介なのが、このヘルプページを開くと「勝手に更新が始まってしまう」という点です。
メーカーがビルドしたOSならともかく自分で適当にビルドしたものだと、ふとしたはずみで勝手に更新されてしまうのはちょっと困るという場合もあります。
勝手に更新されるのが嫌なら、/etc/lsb-releaseにはあえてでたらめなアドレスを書いておき、コマンドラインから手動で更新する、という方法があります。
手動で更新を行う場合は、Chromium OSの実機上でCtrl+Alt+F2でターミナルを開き、以下のコマンドを実行します。
chronos@localhost / $ sudo update_engine_client --omaha_url=http://Devserverのアドレス:ポート番号/update --update Password: [0501/220512:INFO:update_engine_client.cc(529)] Forcing an update by setting app_version to ForcedUpdate. [0501/220512:INFO:update_engine_client.cc(531)] Initiating update check and install. [0501/220512:INFO:update_engine_client.cc(555)] Waiting for update to complete. LAST_CHECKED_TIME=1398949512 PROGRESS=0.000005 CURRENT_OP=UPDATE_STATUS_DOWNLOADING NEW_VERSION=9999.0.0 NEW_SIZE=302343638 （略） LAST_CHECKED_TIME=1398949512 PROGRESS=0.000000 CURRENT_OP=UPDATE_STATUS_UPDATED_NEED_REBOOT NEW_VERSION=9999.0.0 NEW_SIZE=302343638 [0501/222043:INFO:update_engine_client.cc(384)] Update succeeded -- reboot needed. chronos@localhost / $
このコマンドを実行すると、--omaha_urlで指定したDev server上にある最新のビルドイメージに更新されます。--omaha_urlを省略した場合は/etc/lsb-releaseのCHROMEOS_AUSERVERの値が使われます。
このコマンドを実行すると現在実機にインストールされているバージョンよりDev serverのほうが古くても更新がかかります。
ただ、あくまでも更新対象はDev server上の一番新しいイメージのようです。これをコマンドラインから選択する方法はまだわかっていません。chroot環境を複数持っていれば、古いほうのchroot環境でDev serverを起動することで古いイメージに戻すことができますが、同一chroot環境でいくつもビルドイメージを持っている場合は、今のところサーバ側で細工しない限り古いバージョンへ戻す方法がわかっていません。
なお、この方法ではROOTパーティションが丸ごと新しいイメージに書き換わります。そのため、更新前の環境でROOTパーティションに対して何らかの変更を行っているとその内容がすべて消えます。
一番影響が大きいのは後付けでPDFやFlashなどのプラグインをインストールしているケースだと思いますが、基本的には再度入れなおしになります。
もしかしたらビルド時にlibpepflashplayer.soやlibpdf.soをSTATEパーティションへのシンボリックリンクにしたイメージを作っておいてこれらのプラグインをSTATEパーティションに入れるようにすれば更新時に消えないようにできるかもしれませんが、そもそもこれでちゃんと動くかどうかはまだ試してはいません。
個人で使うだけならビルド時にプラグインを含めてイメージを作っちゃうのが一番楽かもしれませんが、これもまだ試してはいません。
STATEパーティションの更新
上記の方法で更新されるのはROOTパーティションのみです。/usr/localなどが置かれているSTATEパーティションを更新する場合は、ターミナルからstateful_updateというコマンドを実行する必要があるということです。が、
chronos@localhost / $ sudo stateful_update Downloading stateful payload from http://xx.xx.xx.xx:8080/static/stateful.tgz HTTP/1.1 404 Not Found Date: Thu, 01 May 2014 13:29:20 GMT Content-Length: 1070 Content-Type: text/html Server: CherryPy/3.1.2 gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now Successfully downloaded update. Missing var or dev_image in stateful payload.
404エラーが出てしまいました。stateful_updateは
http://devserver_host:8080/static/stateful.tgz
というファイルをダウンロードしに行くようですが、devserverのstatic配下にはstateful.tgzがありません。
Dev server上のstaticディレクトリは、ビルドマシンのchroot環境では/usr/lib/devserver/staticにあたります。この下を見ると以下のようになっています。
(cr) chromium@Ubuntu12 /usr/lib/devserver/static $ ls -F cache/ pkgroot@ x86-generic/ xbuddy_UpdateTimestamps/
ビルドイメージはこのディレクトリのx86-genericの下にシンボリックリンクの形で準備されます。
(cr) chromium@Ubuntu12 /usr/lib/devserver/static $ cd x86-generic/ (cr) chromium@Ubuntu12 /usr/lib/devserver/static/x86-generic $ ls -F R35-5712.32.2014_04_20_0902-a1@ R35-5712.32.2014_04_20_2104-a1@ R35-5712.32.2014_04_28_2223-a1@
stateful.tgzはこのバージョン名のシンボリックリンクの下に作られています。
(cr) chromium@Ubuntu12 /usr/lib/devserver/static/x86-generic/R35-5712.32.2014_04_28_2223-a1 $ ls -F boot.config chromiumos_image.bin esp/ pack_partitions.sh* rootfs_dir/ stateful.tgz@ umount_image.sh* update.gz@ boot.desc config.txt mount_image.sh* rootfs/ stateful/ stateful_dir/ unpack_partitions.sh* update.meta@
なので、以下のようにstaticディレクトリ配下に最新ビルドのstateful.tgzへのシンボリックリンクを作ります。
(cr) chromium@Ubuntu12 /usr/lib/devserver/static/x86-generic/R35-5712.32.2014_04_28_2223-a1 $ cd ../.. (cr) chromium@Ubuntu12 /usr/lib/devserver/static $ ln -s x86-generic/R35-5712.32.2014_04_28_2223-a1/stateful.tgz . (cr) chromium@Ubuntu12 /usr/lib/devserver/static $ ls -F cache/ pkgroot@ stateful.tgz@ x86-generic/ xbuddy_UpdateTimestamps/
この状態で実機上でstateful_updateを実行してみます。
chronos@localhost / $ sudo stateful_update Downloading stateful payload from http://xx.xx.xx.xx:8080/static/stateful.tgz HTTP/1.1 200 OK Content-Length: 59005337 Accept-Ranges: bytes Server: CherryPy/3.1.2 Last-Modified: Wed, 30 Apr 2014 09:31:20 GMT Date: Thu, 01 May 2014 13:30:47 GMT Content-Type: application/x-gtar-compressed Successfully downloaded update. Performing standard stateful update. chronos@localhost / $
今度はうまくいきました。公式サイトの解説ページにはこんな作業が必要とは書いてありません。なんでこうなってしまうのかはよくわかっていません。
なお、STATEパーティションの更新はコマンド実行終了時点ではまだ行われていません。ここでダウンロードした内容は/mnt/stateful_partition/の下のdev_image_newおよびvar_newというディレクトリに格納され、リブート時に本来のディレクトリであるdev_imageおよびvar_overlayと置換されます。
なお、stateful_updateコマンド実行時に接続しに行くDev serverは、/etc/lsb-releaseのCHROMEOS_DEVSERVERで指定したアドレスになります。
また、STATEパーティションの更新では/home配下は変更されないのでユーザ固有のデータは更新後でも引き継がれます。
Dev serverから実機にパッケージをインストールする
Dev serverを使うと、OS自体の更新だけでなく、個別にパッケージを指定して実機に取り込むこともできるようになります。パッケージを個別でインストールするには以下のコマンドを実行します。
$ sudo gmerege [-n] パッケージ名 [--accept_stable]
gmergeコマンドを実行すると、デフォルトではROOTパーティションの/usr/binや/usr/libなどにバイナリがインストールされるようです。インストール先を変更できるかどうかはまだ調べていません。
ここで、-nオプションはDev server上でそのパッケージがすでにビルド済みなら改めてビルドせずにバイナリをダウンロードするように指示します。
また、--accept_stableオプションはビルド環境上の~/trunk/src/third_party/chromiumos-overlay配下にあるパッケージの一部をインストールするときに指定する必要が出てくることがあります。
chromiumos_overlay配下の一部のパッケージをインストールしようとすると以下のようなエラーが出ることがあります。
chronos@localhost / $ sudo gmerge -n binutils Sending build request to http://xx.xx.xx.xx:8080 Package is not cros_workon'd on the devserver machine. Either start working on the package or pass --accept_stable to gmerge
このエラーが出たときは--accept_stableオプションを指定して再実行するとパッケージのインストールができます。
このエラーがでるのは、chromiumos_overlay配下にあるパッケージで、ebuildファイルのinheritパラメータにcros_workonの記述があるパッケージです。
あまりこの辺の意味はよくわかっていませんが、この辺のパッケージは基本的にOSインストール時にまとめてインストールされるものですので、あらためて、パッケージ単体でインストールするものではない、ということなのでしょう。
cros_workonはそれらのパッケージに対して修正を加える際に実行するコマンドで、それが実行されているならそのパッケージはカスタマイズされていると判断されて実機に追加インストールできるようになっているが、それ以外はガードがかかっており、ガードを外すのが--accept_stableオプション、ということなのだろうと理解しています。
なお、前回の記事ではbinutilsをChromium OSのイメージに導入するのに非常にてこずりましたが、Dev serverからのインストールなら非常に簡単にできました。Chromium OSをいじるうえではDev serverは欠かせないツールになりそうです。
［関連記事］
[悲報] Chrome R44でffmpegsumoが消えた
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にインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
[0回]
2014/04/28 (Mon) 23:38
今回はChromium OSにもともとインストールされていないソフトウェアを後から組み込む方法を試してみます。
今回追加するのはgnu binutilsとp7zipです。
binutilsに含まれているarコマンドとp7zipに含まれる7zコマンドがChromium OSに入っているとUbuntuなどのDebian系で使われているパッケージ形式であるdebファイルをChromium OS上で直接展開できるようになります。
これができるようになると、Chromeブラウザの最新版をgoogleから直接Chromium OS上にダウンロードして、そこからFlashとPDFのプラグインを抜き出してインストールすることができるようになります。
・・・まあ、スクリプトが公開されているんでそれ使ったほうが早いですがｗ
Flashの話はとりあえず今回はおいておいてパッケージの追加の話だけ書きます。
組み込む方法といっても方法はいくつか考えられます。
一番手っ取り早いのは普通にソースをダウンロードしてきてconfigureしてmakeする、という方法です。
もう一つはChromium OSのSDKにパッケージを追加してSDKの流儀で組み込む方法です。
このほかにDev Serverを使う方法があります。Dev serverについてはこちらの記事でまとめています。
今回はbinutilsを最初の方法、p7zipを２番目の方法でインストールしていきます。ただ、前者の方法は軽く触れるだけにして、後者をメインに書いていきます。
なお、今回も既にChromium OSのビルド環境が手元にあることを前提にして書いていきます。ビルド環境の構築方法はこちらの記事で書いています。
また、パッケージの追加・置換は手順を間違えると最悪ビルド環境が壊れてしまうので、バックアップやVMを使っているならスナップショットの作成を行って作業前に戻せるようにしておくことをお勧めします。
実はx86アーキテクチャ用のarコマンドは
/build/x86-generic/usr/i686-pc-linux-gnu/binutils-bin/2.22/ar
においてあります。なので、別にビルドしなくてもこれをコピーすれば終わりだったりしますが、物は試しということでbinutilsのmakeをやってみます。
といっても、基本的には普通にconfigureしてmakeするだけですのであまり難しいことはありません。ただ、Chromium OS用バイナリをビルドする際の注意点はいくつかあるのでそれを書いておきます。
Chromium OSのビルド環境はUbuntu12.04 LTS 64bitですので、普通にビルドするとビルド環境であるUbuntu 64bit用のバイナリができてしまいます。このブログでターゲットにしているのはx86なのでそれだと困ります。
Chromium OS用のバイナリをビルドするにはターゲットアーキテクチャ向けにクロスコンパイルを行う必要があるので、Configureなどでビルドの設定をする際にはx86用のクロスコンパイラが使われるように指定してあげる必要があります。
そのため、普通にConfigure/makeする場合でも、やはりcros_sdkを使ってchroot環境に移行して、そのchroot環境の中で作業する必要があります。
そのうえでx86用のコンパイラである
が使われるように設定します。
gnu binutilsを手動でビルドする場合は、configureを実行する際に以下のように指定します。
./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
p7zipのようにconfigureがないようなソフトの場合は、makefileを開いてCXXやCCなどのコンパイラ名を指定している変数を探して、該当箇所を上に書いたコンパイラ名に書き換えます。
このあと普通にmakeすれば、うまくいけばx86アーキテクチャのChromium OS用バイナリが出来上がります。
もう一点注意すべきことは、当然ですが
make installしてはいけない
ということです。特にbinutilsのようなビルド処理に直接かかわるツールをmake installすると最悪ビルド環境が壊れてしまいます。
手動でビルドした場合、バイナリはChromium OSのイメージには取り込まれませんので手動でバイナリをChromium OSがインストールされている実機にコピーする必要があります。ただし、コピー先にも注意があります。
Chromium OSではホームディレクトリに置いたバイナリは実行できないようにガードがかかっています。Chromium OSはルートパーティションがリードオンリーでマウントされているので、バイナリはSTATEパーティションにある/usr/local/binに置くのが簡単です。単に
sudo cp ～ /usr/local/bin
とすればOKです。
ここまでの内容を踏まえて、x86アーキテクチャ向けのChromium OS用binutilsのビルド手順は以下のような感じになります。
あとは、Chromium OSインストールマシンからscpなどでarをコピーし、/usr/local/binにコピーすればOKです。
今回の内容は本家サイト"The Chromium Project"以下の各ページを参考にしています。
Chromium OSの情報源は英語ばかりなのでまた間違って理解している可能性があります。詳しいことはこれらの本家サイトをご覧ください。
Chromium OSのパッケージシステムはGentoo Linuxというディストリビューションで使われているPortageというものです。Portageでは各ソフトのダウンロード・ビルド方法を拡張子がebuildのファイルに書いておき、これを実行することでソフトウェアのインストールを行います。debやrpmと違ってバイナリパッケージではなく、基本的にはソースアーカイブをネット経由でダウンロードしてから逐次ビルドするところに特徴があります（バイナリパッケージもあるようですが）。
Chromium OSのSDKでは、このebuildファイルが置かれている場所が大きく分けて以下の２つあります。
~/trunk/src/third_party/chromiumos_overlay
~/trunk/src/third_party/portage_stable
前者はChromium OSの中核をなすパッケージや、Chromium OSに取り込むにあたってカスタマイズが施されているようなソフトのパッケージが置かれているようです。なので、ここにパッケージがあるときは下手に置き換えないほうが得策です。
こっちにおいてあるパッケージでChromium OSに取り込まれていないものはあまり多くないと思いますが、binutilsはこちらにパッケージがあるけどデフォルトではChromium OSに取り込まれないものの１つです。
これに対して、一般に配布されているオープンソースソフトウェアをそのまま取り込むようなケースではportage_stableにあるパッケージが使われます。ここにはGentoo Linuxのパッケージツリーからそのまま持ってきただけと思われるものが多数置いてありますが、必ずしも最新のパッケージになっているというわけではありません。
また、portage_stableには、実際にはChromium OSのイメージに取り込まれないようなパッケージもいくつかおいてあったりします。今回扱うものでは、p7zipがこちらに当てはまります。
上記２つのディレクトリの下には、ソフトウェアのカテゴリを表すサブディレクトリがたくさん作られています。これらのカテゴリを表すサブディレクトリのさらに下に各ソフトウェアのディレクトリが作られ、その中にebuildファイルをはじめとするパッケージの構成ファイルが入っています。
このカテゴリとソフトウェアの対応は、Gentoo Linuxの構成がそのまま踏襲されています。
今回インストールするプログラムはgnu binuitlsとp7zipですが、"binutils ebuild"とか"p7zip ebuild"などでググればGentoo Linuxのパッケージツリーが置いてあるサイトが真っ先に引っかかるので、これらのソフトのパッケージがどこに置かれるべきかはすぐわかります。
結論から言うと、p7zipはapp-archというアーカイバ関係のカテゴリ、binutilsはsys-develという開発ツール関係のカテゴリに含まれます。
p7zipとbinutilsが現状のChromium OS SDKでどこに置かれているかを一応確認しておきます。まずportage_stable配下の現状を見るとこのようになっています。
p7zipのほうは既にパッケージが存在していますが、バージョンが9.13とちょっと古いようです（記事作成時点では9.20が最新）。現状Chromium OSにはp7zipは含まれていませんので使われていないにも関わらずパッケージだけは置いてあるようです。
binutilsのほうはパッケージがありません。
一方、chromiumos-overlayのほうは結論だけ書きますが、p7zipについてはp7zip自体も、その上位カテゴリのapp-archもありません。それに対してbinutilsのほうはsys-develカテゴリの中にパッケージが存在しています。
これらをふまえてパッケージの追加を行っていきます。
p7zipは既にパッケージが存在していますが、バージョンが古いです。この古いバージョンでビルドを試みましたがコンパイルエラーになりました。
p7zipはchromiumos-overlaysのほうにパッケージがないので、思い切ってバージョンをあげてしまいます。
Chromium OS SDKにはパッケージの更新を行うための専用のコマンドが用意されているので、そのコマンドで更新をかけます。
一応、Chromium SDKを起動するところから手順を書いてきます。
今回は~/trank/src/third_party/portage_stableで作業をするので、ここにブランチを作ります。
続けてcros_portage_upgradeというコマンドを実行します。これが上流サイトから最新のパッケージをダウンロードして置き換えるためのコマンドです。
黄色い文字で警告が表示されます。これは、--boardオプションでx86-genericだけを指定したためです。--boardオプションは:で区切って複数のアーキテクチャを指定できますが、私が使っている環境がx86しかセットアップしていないので１つだけ指定しています。 この警告ではパッケージの置換は他のアーキテクチャにも影響を与えるため、１つだけ指定すると他のアーキテクチャでビルドできなくなるかもしれないよ、というようなことを言っているようです。ここはとりあえずyesを入力して先に進みます。
冒頭に
Cloning origin/gentoo at /tmp/portage as upstream reference.
と表示されていますが、要するにリモートのパッケージツリーからパッケージをダウンロードしてきて/tmp/potargeに一旦置いた後に、依存関係などをチェックしながら最終的に~/trunk/src/third_party/portage_stableの下のパッケージを置き換えています。
出力内容からp7zipが9.13から9.20.1-r4に置き換わったことが分かります。
ちなみにChromium OS SDKでは上流のパッケージサイトのURLは
https://chromium.googlesource.com/chromiumos/overlays/portage
になります。
このcros_portage_upgradeコマンドは、コマンド名こそupgradeですが、portage_stableにないパッケージでも上流サイトにあれば持ってくることができます。
一度実行すると/tmp/portageに上流サイトのパッケージツリーのクローンができるので、ここにできるパッケージはとりあえず持ってきてビルドにチャレンジすることはできると思います。うまくいくかどうかはやってみないとわかりませんが。
持ってきたパッケージがそのままコンパイルできるとは限りません。とくにGUI系のツールは多分無理だと思います。今回はコマンドラインツールなので十分期待できます。
コンパイルだけを実行する場合はebuild-${BOARD}というコマンドに引数としてebuildファイル名とオプション"compile"を指定して実行します。
${BOARD}はターゲットアーキテクチャを表す文字列です。今回の場合はx86-genericなのでコマンドはebuild-x86-genericです。GentooLinuxで使われているのebuildコマンドを直接使うことは基本的にはありません。
うまくコンパイルできたようです。
ちなみにパッケージそのものにはソースコードは含まれておらず、ビルド時にリモートからダウンロードするようになっています。ダウンロードしたソースコードは
/build/${BOARD}/tmp/portage/の下に置かれます。
ここまででp7zipのパッケージをコンパイルしましたが、これだけではChromium OSにビルド結果が取り込まれません。取り込まれるようにするためには、~/trunk/src/third_party/chromiumos_overlay/chromeos-baseの下にある以下のいずれかのパッケージのebuildファイルを編集して、追加するパッケージ名を依存関係の一覧に追記する必要があります。
前者に追加した場合、バイナリはChromium OSの/usr/binや/usr/libにインストールされます。後者に追加した場合は/usr/local配下にバイナリが置かれます。
特段の必要がなければ基本的にはchromeos-devのほうにパッケージを追加したほうが簡単です。
chromeosのほうに追加する場合は、以下の２点に気を使う必要があります。
a. ルートパーティションの容量
b. シェアードライブラリの依存関係
まずパーティションの容量ですが、/usr/binはルートパーティションに置かれます。Chromium OSのルートパーティションはデフォルトで1.2GB程度しか確保されていません。そのためあまりこちらにものを入れすぎるとルートパーティションが足りなくなる可能性があります。/usr/localが置かれるSTATEパーティションは他のパーティションを確保した後の残容量全部が割り当てられるため、あまり容量の心配をする必要はありません。
次のシェアードライブラリの依存関係ですが、ルートパーティションにインストールするパッケージは、build_imageでディスクイメージを作成する時にシェアードライブラリの依存関係がチェックされます。このチェックで依存する.soファイルが見つからないとエラーでイメージ作成が失敗してしまいます。
で、このチェックには厄介な問題があります。
シェアードライブラリはプログラムローダーが認識できるようにld.so.confに書かれているパスのいずれかに配置されるのが普通ですが、一部のプログラムではそこにはシンボリックリンクを置いておき、実体をほかの場所に置くことがあります。このシンボリックリンクのリンク先が絶対パス表記になっているとこの依存関係チェックがうまくできずにエラーになってしまうのです。
実はbinutilsのパッケージを/usr/binにインストールしようとするとこの条件に引っかかってエラーになってしまうという問題があります。chromeos-devに依存関係を足して/usr/localにインストールすることは可能ですが、binutilsのパッケージはシンボリックリンクを絶対パスで/usr/binや/usr/libに作るためリンク切れが起きてしまいます。
今回パッケージでインストールするp7zipの場合はどちらでもいいですが、今回はchromeos-devの方に追加してみます。
chromiumos_overlayの方も編集に先立ってrepo startでブランチを作っておく必要があります。
それからchromiumos_overlay/chromeos-base/chromeos-devに移動して、そこにある ebuildファイルに依存関係を追加します。追加するのはRDEPENDという変数です。
ここで、chromeosの下には
chromeos-0.1.0-r94.ebuild
chromeos-0.1.0.ebuild
の２つのファイルがあり、前者は後者へのシンボリックリンクになっています。
編集を加えた後は、ビルドシステムが変更を認識できるようにシンボリックのリビジョン番号をカウントアップします。
ビルドがうまくいったようなので、続けてbuild_imageします。
build_packagesでビルドを行うと、各パッケージのバイナリは
/build/${BOARD}/package/パッケージカテゴリ名
の下にtbz2形式で圧縮されて格納されます。この中から必要なものがbuild_imageの実行時に展開されてディスクイメージの中にコピーされるようになっています。
終わったらイメージをマウントして中を確認し、追加したコマンドが含まれているか確認します。作成したビルドイメージのルートパーティションは/tmp/mにマウントされるので、確認する場所は/tmp/m/usr/local/binになります。ここに7*で始まるファイルがあるかチェックします。
うまくできていたようです。確認が終わったらイメージはアンマウントします。
CPV: chromeos-base/chromeos-dev-0.1.0-rXX
という文字列を検索します。XXはebuildファイルをリネームしたときに指定したリビジョン番号です。すると以下のような内容が見つかるはずです。
このDEPEND:の後に取り込まれるパッケージがずらずら書いてありますので、この中に自分が追加したパッケージが確かに含まれていることを確認します。含まれていない場合はどこかにミスがあります。
うまくいかないケースではリビジョンをあげ忘れて前のリビジョンしかヒットしない場合が多いのではないかと思います。
binutilsはp7zipと違って~/trunk/src/third_party/portage_stableの下にパッケージが置かれていませんが、chromiumos_overlaysの中にはパッケージが存在しています。
このbinutilsパッケージはChromium OSにインストールするためにあるものではなく、SDKのビルド環境を作成するために存在しています。なので、このbinutilsパッケージに対して細工を加えると正しくChromium OSがビルドできなくなります。
emerge-x86-generic binutils --unmerge
などとしてパッケージを削除してしまうと、ビルドに使うldコマンドが消えてしまってバイナリが作れなくなります。上で書いたcros_portage_upgradeコマンドを実行して更新をかけるのも避けるべきです。
どうしてもbinutilsパッケージをChromium OSのイメージに取り込みたいときは、以下のようにbuiild_imageコマンドで引数にdevではなくtestを指定するするのが簡単です。
./build_image --board=${BOARD} --noenable_rootfs_verification test
こうするとビルド環境で使われているbinutilsパッケージがChromium OSに取り込まれます。ただ、この方法ではchromiumos-overlay/chromeos-base/chromeos-testというパッケージに書かれているすべてのパッケージがChromium OSに取り込まれます。いろいろ有益なツールもあるのでこれでもいいかと思います。
この方法で追加されるパッケージはchromeos-devに依存関係を追記したときと同じで/usr/local配下にインストールされます。上でも書いたように/usr/local配下にbinutilsをインストールするとシンボリックリンクが壊れるので後で手作業で直さないといけません。 ということで、binutilsについては今のところスマートにインストールする方法はないみたいです。
［関連記事］
[悲報] Chrome R44でffmpegsumoが消えた
Dev serverによる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にインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ
今回追加するのはgnu binutilsとp7zipです。
binutilsに含まれているarコマンドとp7zipに含まれる7zコマンドがChromium OSに入っているとUbuntuなどのDebian系で使われているパッケージ形式であるdebファイルをChromium OS上で直接展開できるようになります。
これができるようになると、Chromeブラウザの最新版をgoogleから直接Chromium OS上にダウンロードして、そこからFlashとPDFのプラグインを抜き出してインストールすることができるようになります。
・・・まあ、スクリプトが公開されているんでそれ使ったほうが早いですがｗ
Flashの話はとりあえず今回はおいておいてパッケージの追加の話だけ書きます。
組み込む方法といっても方法はいくつか考えられます。
一番手っ取り早いのは普通にソースをダウンロードしてきてconfigureしてmakeする、という方法です。
もう一つはChromium OSのSDKにパッケージを追加してSDKの流儀で組み込む方法です。
このほかにDev Serverを使う方法があります。Dev serverについてはこちらの記事でまとめています。
今回はbinutilsを最初の方法、p7zipを２番目の方法でインストールしていきます。ただ、前者の方法は軽く触れるだけにして、後者をメインに書いていきます。
なお、今回も既にChromium OSのビルド環境が手元にあることを前提にして書いていきます。ビルド環境の構築方法はこちらの記事で書いています。
また、パッケージの追加・置換は手順を間違えると最悪ビルド環境が壊れてしまうので、バックアップやVMを使っているならスナップショットの作成を行って作業前に戻せるようにしておくことをお勧めします。
Configure/makeする
実はx86アーキテクチャ用のarコマンドは
/build/x86-generic/usr/i686-pc-linux-gnu/binutils-bin/2.22/ar
においてあります。なので、別にビルドしなくてもこれをコピーすれば終わりだったりしますが、物は試しということでbinutilsのmakeをやってみます。
といっても、基本的には普通にconfigureしてmakeするだけですのであまり難しいことはありません。ただ、Chromium OS用バイナリをビルドする際の注意点はいくつかあるのでそれを書いておきます。
Chromium OSのビルド環境はUbuntu12.04 LTS 64bitですので、普通にビルドするとビルド環境であるUbuntu 64bit用のバイナリができてしまいます。このブログでターゲットにしているのはx86なのでそれだと困ります。
Chromium OS用のバイナリをビルドするにはターゲットアーキテクチャ向けにクロスコンパイルを行う必要があるので、Configureなどでビルドの設定をする際にはx86用のクロスコンパイラが使われるように指定してあげる必要があります。
そのため、普通にConfigure/makeする場合でも、やはりcros_sdkを使ってchroot環境に移行して、そのchroot環境の中で作業する必要があります。
そのうえでx86用のコンパイラである
- i686-pc-linux-gnu-gcc
- i686-pc-linux-gnu-g++
が使われるように設定します。
gnu binutilsを手動でビルドする場合は、configureを実行する際に以下のように指定します。
./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
p7zipのようにconfigureがないようなソフトの場合は、makefileを開いてCXXやCCなどのコンパイラ名を指定している変数を探して、該当箇所を上に書いたコンパイラ名に書き換えます。
このあと普通にmakeすれば、うまくいけばx86アーキテクチャのChromium OS用バイナリが出来上がります。
もう一点注意すべきことは、当然ですが
make installしてはいけない
ということです。特にbinutilsのようなビルド処理に直接かかわるツールをmake installすると最悪ビルド環境が壊れてしまいます。
手動でビルドした場合、バイナリはChromium OSのイメージには取り込まれませんので手動でバイナリをChromium OSがインストールされている実機にコピーする必要があります。ただし、コピー先にも注意があります。
Chromium OSではホームディレクトリに置いたバイナリは実行できないようにガードがかかっています。Chromium OSはルートパーティションがリードオンリーでマウントされているので、バイナリはSTATEパーティションにある/usr/local/binに置くのが簡単です。単に
sudo cp ～ /usr/local/bin
とすればOKです。
ここまでの内容を踏まえて、x86アーキテクチャ向けのChromium OS用binutilsのビルド手順は以下のような感じになります。
chromium@Ubuntu12:~/chromiumR35$ ./chromite/bin/cros_sdk [sudo] password for chromium: (cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd .. (cr) chromium@Ubuntu12 ~/trunk/src $ mkdir mypackage (cr) chromium@Ubuntu12 ~/trunk/src $ cd mypackage (cr) chromium@Ubuntu12 ~/trunk/src/mypackage $ wget http://ftp.gnu.org/gnu/binutils/binutils-2.24.tar.gz (cr) chromium@Ubuntu12 ~/trunk/src/mypackage $ tar zxvf binutils-2.24.tar.gz (cr) chromium@Ubuntu12 ~/trunk/src/mypackage $ cd binutils-2.24 (cr) chromium@Ubuntu12 ~/trunk/src/mypackage/binutils-2.24 $ ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu (cr) chromium@Ubuntu12 ~/trunk/src/mypackage/binutils-2.24 $ make
あとは、Chromium OSインストールマシンからscpなどでarをコピーし、/usr/local/binにコピーすればOKです。
Chromium OSのパッケージシステム
今回の内容は本家サイト"The Chromium Project"以下の各ページを参考にしています。
Chromium OSの情報源は英語ばかりなのでまた間違って理解している可能性があります。詳しいことはこれらの本家サイトをご覧ください。
Chromium OSのパッケージシステムはGentoo Linuxというディストリビューションで使われているPortageというものです。Portageでは各ソフトのダウンロード・ビルド方法を拡張子がebuildのファイルに書いておき、これを実行することでソフトウェアのインストールを行います。debやrpmと違ってバイナリパッケージではなく、基本的にはソースアーカイブをネット経由でダウンロードしてから逐次ビルドするところに特徴があります（バイナリパッケージもあるようですが）。
Chromium OSのSDKでは、このebuildファイルが置かれている場所が大きく分けて以下の２つあります。
~/trunk/src/third_party/chromiumos_overlay
~/trunk/src/third_party/portage_stable
前者はChromium OSの中核をなすパッケージや、Chromium OSに取り込むにあたってカスタマイズが施されているようなソフトのパッケージが置かれているようです。なので、ここにパッケージがあるときは下手に置き換えないほうが得策です。
こっちにおいてあるパッケージでChromium OSに取り込まれていないものはあまり多くないと思いますが、binutilsはこちらにパッケージがあるけどデフォルトではChromium OSに取り込まれないものの１つです。
これに対して、一般に配布されているオープンソースソフトウェアをそのまま取り込むようなケースではportage_stableにあるパッケージが使われます。ここにはGentoo Linuxのパッケージツリーからそのまま持ってきただけと思われるものが多数置いてありますが、必ずしも最新のパッケージになっているというわけではありません。
また、portage_stableには、実際にはChromium OSのイメージに取り込まれないようなパッケージもいくつかおいてあったりします。今回扱うものでは、p7zipがこちらに当てはまります。
上記２つのディレクトリの下には、ソフトウェアのカテゴリを表すサブディレクトリがたくさん作られています。これらのカテゴリを表すサブディレクトリのさらに下に各ソフトウェアのディレクトリが作られ、その中にebuildファイルをはじめとするパッケージの構成ファイルが入っています。
このカテゴリとソフトウェアの対応は、Gentoo Linuxの構成がそのまま踏襲されています。
今回インストールするプログラムはgnu binuitlsとp7zipですが、"binutils ebuild"とか"p7zip ebuild"などでググればGentoo Linuxのパッケージツリーが置いてあるサイトが真っ先に引っかかるので、これらのソフトのパッケージがどこに置かれるべきかはすぐわかります。
結論から言うと、p7zipはapp-archというアーカイバ関係のカテゴリ、binutilsはsys-develという開発ツール関係のカテゴリに含まれます。
p7zipとbinutilsが現状のChromium OS SDKでどこに置かれているかを一応確認しておきます。まずportage_stable配下の現状を見るとこのようになっています。
(cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable $ cd app-arch/ (cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch $ ls bzip2 cpio libarchive makeself p7zip pigz sharutils tar unzip zip cabextract gzip lzop metadata.xml pbzip2 rpm2targz snappy unrar xz-utils (cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch $ ls p7zip Manifest files metadata.xml p7zip-9.13.ebuild (cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch $ cd ../sys-devel/ (cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/sys-devel $ ls autoconf automake bc binutils-config crossdev flex gettext libperl m4 metadata.xml smatch autoconf-wrapper automake-wrapper bin86 bison dev86 gcc-config gnuconfig libtool make patch
p7zipのほうは既にパッケージが存在していますが、バージョンが9.13とちょっと古いようです（記事作成時点では9.20が最新）。現状Chromium OSにはp7zipは含まれていませんので使われていないにも関わらずパッケージだけは置いてあるようです。
binutilsのほうはパッケージがありません。
一方、chromiumos-overlayのほうは結論だけ書きますが、p7zipについてはp7zip自体も、その上位カテゴリのapp-archもありません。それに対してbinutilsのほうはsys-develカテゴリの中にパッケージが存在しています。
これらをふまえてパッケージの追加を行っていきます。
p7zipのChromium OSへの追加
p7zipは既にパッケージが存在していますが、バージョンが古いです。この古いバージョンでビルドを試みましたがコンパイルエラーになりました。
p7zipはchromiumos-overlaysのほうにパッケージがないので、思い切ってバージョンをあげてしまいます。
Chromium OS SDKにはパッケージの更新を行うための専用のコマンドが用意されているので、そのコマンドで更新をかけます。
一応、Chromium SDKを起動するところから手順を書いてきます。
chromium@Ubuntu12:~$ cd ~/chromiumR35 chromium@Ubuntu12:~/chromiumR35$ ./chromite/bin/cros_sdk [sudo] password for chromium: (cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ export BOARD=x86-generic
今回は~/trank/src/third_party/portage_stableで作業をするので、ここにブランチを作ります。
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd ~/trunk/src/third_party/portage-stable/ (cr) (release-R35-5712.B/(bc67084...)) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable $ repo start my-portage . (cr) (release-R35-5712.B/my-portage) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable $
続けてcros_portage_upgradeというコマンドを実行します。これが上流サイトから最新のパッケージをダウンロードして置き換えるためのコマンドです。
(cr) (release-R35-5712.B/my-portage) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable $ cros_portage_upgrade --board=${BOARD} --upgrade p7zip
You have selected boards for archs ['x86'], which does not cover all standard archs ['amd64', 'arm', 'x86']
If you continue with this upgrade you may break builds for architectures not covered by your
boards. Continue only if you have a reason to limit this upgrade to these specific architectures.
Do you want to continue anyway? (yes/No)? yes
黄色い文字で警告が表示されます。これは、--boardオプションでx86-genericだけを指定したためです。--boardオプションは:で区切って複数のアーキテクチャを指定できますが、私が使っている環境がx86しかセットアップしていないので１つだけ指定しています。 この警告ではパッケージの置換は他のアーキテクチャにも影響を与えるため、１つだけ指定すると他のアーキテクチャでビルドできなくなるかもしれないよ、というようなことを言っているようです。ここはとりあえずyesを入力して先に進みます。
Cloning origin/gentoo at /tmp/portage as upstream reference.
Cloning into 'portage'...
remote: Sending approximately 1.04 GiB ...
（略）
Running with board x86-generic.
Resolved "p7zip" to "app-arch/p7zip-9.13" (local) and "app-arch/p7zip-9.20.1-r4" (upstream).
Copying app-arch/p7zip-9.20.1-r4 from upstream.
Editing u'/mnt/host/source/src/third_party/portage-stable/app-arch/p7zip/p7zip-9.20.1-r4.ebuild' to mark it stable for everyone
Confirmed that all upgraded packages can be emerged on x86-generic after upgrade.
Keeping upstream cache at /tmp/portage.
[my-portage fbe5285] p7zip: upgraded package to upstream
9 files changed, 119 insertions(+), 150 deletions(-)
delete mode 100644 app-arch/p7zip/files/9.04-kde4.patch
rename app-arch/p7zip/files/{p7zip-9.13-QA.patch => p7zip-9.20.1-QA.patch} (91%)
create mode 100644 app-arch/p7zip/files/p7zip-9.20.1-execstack.patch
create mode 100644 app-arch/p7zip/files/p7zip-9.20.1-long_rar_pwd.patch
rename app-arch/p7zip/{p7zip-9.13.ebuild => p7zip-9.20.1-r4.ebuild} (56%)
delete mode 100644 metadata/md5-cache/app-arch/p7zip-9.13
create mode 100644 metadata/md5-cache/app-arch/p7zip-9.20.1-r4
Upgrade changes committed (see above), but message needs edit BY YOU:
cd /mnt/host/source/src/third_party/portage-stable; git commit --amend; cd -
To remove any individual file above from commit do:
cd /mnt/host/source/src/third_party/portage-stable; git reset HEAD~ <filepath>; rm <filepath>; git commit --amend -C HEAD; cd -
If you wish to undo all the changes to portage-stable:
cd /mnt/host/source/src/third_party/portage-stable; git reset --hard HEAD~; cd -
冒頭に
Cloning origin/gentoo at /tmp/portage as upstream reference.
と表示されていますが、要するにリモートのパッケージツリーからパッケージをダウンロードしてきて/tmp/potargeに一旦置いた後に、依存関係などをチェックしながら最終的に~/trunk/src/third_party/portage_stableの下のパッケージを置き換えています。
出力内容からp7zipが9.13から9.20.1-r4に置き換わったことが分かります。
ちなみにChromium OS SDKでは上流のパッケージサイトのURLは
https://chromium.googlesource.com/chromiumos/overlays/portage
になります。
このcros_portage_upgradeコマンドは、コマンド名こそupgradeですが、portage_stableにないパッケージでも上流サイトにあれば持ってくることができます。
一度実行すると/tmp/portageに上流サイトのパッケージツリーのクローンができるので、ここにできるパッケージはとりあえず持ってきてビルドにチャレンジすることはできると思います。うまくいくかどうかはやってみないとわかりませんが。
コンパイルできるかチェックする
持ってきたパッケージがそのままコンパイルできるとは限りません。とくにGUI系のツールは多分無理だと思います。今回はコマンドラインツールなので十分期待できます。
コンパイルだけを実行する場合はebuild-${BOARD}というコマンドに引数としてebuildファイル名とオプション"compile"を指定して実行します。
${BOARD}はターゲットアーキテクチャを表す文字列です。今回の場合はx86-genericなのでコマンドはebuild-x86-genericです。GentooLinuxで使われているのebuildコマンドを直接使うことは基本的にはありません。
(cr) (release-R35-5712.B/my-portage) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch/p7zip $ ebuild-x86-generic p7zip-9.20.1-r4.ebuild compile
>>> Downloading 'https://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/p7zip_9.20.1_src_all.tar.bz2'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found
>>> Downloading 'https://commondatastorage.googleapis.com/chromeos-mirror/gentoo/distfiles/p7zip_9.20.1_src_all.tar.bz2'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3745k 100 3745k 0 0 2190k 0 0:00:01 0:00:01 --:--:-- 2195k
* p7zip_9.20.1_src_all.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]
* Running stacked hooks for pre_pkg_setup
* sysroot_build_bin_dir ... [ ok ]
* Running stacked hooks for pre_src_unpack
* python_multilib_setup ... [ ok ]
>>> Unpacking source...
>>> Unpacking p7zip_9.20.1_src_all.tar.bz2 to /build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work
>>> Source unpacked in /build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work
>>> Preparing source in /build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work/p7zip_9.20.1 ...
* Applying p7zip-9.20.1-execstack.patch ... [ ok ]
* Applying p7zip-9.20.1-QA.patch ... [ ok ]
* Applying 9.04-makefile.patch ... [ ok ]
>>> Source prepared.
>>> Configuring source in /build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work/p7zip_9.20.1 ...
>>> Source configured.
>>> Compiling source in /build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work/p7zip_9.20.1 ...
(略)
make[1]: Leaving directory `/build/x86-generic/tmp/portage/app-arch/p7zip-9.20.1-r4/work/p7zip_9.20.1/CPP/7zip/UI/Console'
>>> Source compiled.
(cr) (release-R35-5712.B/my-portage) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch/p7zip $
うまくコンパイルできたようです。
ちなみにパッケージそのものにはソースコードは含まれておらず、ビルド時にリモートからダウンロードするようになっています。ダウンロードしたソースコードは
/build/${BOARD}/tmp/portage/の下に置かれます。
ビルドしたp7zipをChromium OSに組み込む
ここまででp7zipのパッケージをコンパイルしましたが、これだけではChromium OSにビルド結果が取り込まれません。取り込まれるようにするためには、~/trunk/src/third_party/chromiumos_overlay/chromeos-baseの下にある以下のいずれかのパッケージのebuildファイルを編集して、追加するパッケージ名を依存関係の一覧に追記する必要があります。
- chromeos
- chromeos-dev
前者に追加した場合、バイナリはChromium OSの/usr/binや/usr/libにインストールされます。後者に追加した場合は/usr/local配下にバイナリが置かれます。
特段の必要がなければ基本的にはchromeos-devのほうにパッケージを追加したほうが簡単です。
chromeosのほうに追加する場合は、以下の２点に気を使う必要があります。
a. ルートパーティションの容量
b. シェアードライブラリの依存関係
まずパーティションの容量ですが、/usr/binはルートパーティションに置かれます。Chromium OSのルートパーティションはデフォルトで1.2GB程度しか確保されていません。そのためあまりこちらにものを入れすぎるとルートパーティションが足りなくなる可能性があります。/usr/localが置かれるSTATEパーティションは他のパーティションを確保した後の残容量全部が割り当てられるため、あまり容量の心配をする必要はありません。
次のシェアードライブラリの依存関係ですが、ルートパーティションにインストールするパッケージは、build_imageでディスクイメージを作成する時にシェアードライブラリの依存関係がチェックされます。このチェックで依存する.soファイルが見つからないとエラーでイメージ作成が失敗してしまいます。
で、このチェックには厄介な問題があります。
シェアードライブラリはプログラムローダーが認識できるようにld.so.confに書かれているパスのいずれかに配置されるのが普通ですが、一部のプログラムではそこにはシンボリックリンクを置いておき、実体をほかの場所に置くことがあります。このシンボリックリンクのリンク先が絶対パス表記になっているとこの依存関係チェックがうまくできずにエラーになってしまうのです。
実はbinutilsのパッケージを/usr/binにインストールしようとするとこの条件に引っかかってエラーになってしまうという問題があります。chromeos-devに依存関係を足して/usr/localにインストールすることは可能ですが、binutilsのパッケージはシンボリックリンクを絶対パスで/usr/binや/usr/libに作るためリンク切れが起きてしまいます。
今回パッケージでインストールするp7zipの場合はどちらでもいいですが、今回はchromeos-devの方に追加してみます。
chromiumos_overlayの方も編集に先立ってrepo startでブランチを作っておく必要があります。
それからchromiumos_overlay/chromeos-base/chromeos-devに移動して、そこにある ebuildファイルに依存関係を追加します。追加するのはRDEPENDという変数です。
(cr) (release-R35-5712.B/my-portage) chromium@Ubuntu12 ~/trunk/src/third_party/portage-stable/app-arch/p7zip $ cd ../../../chromiumos-overlay
(cr) (release-R35-5712.B/(49baa0f...)) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay $ repo start my-overlay .
(cr) (release-R35-5712.B/my-overlay) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay $ cd chromeos-base/chromeos-dev
(cr) (release-R35-5712.B/my-overlay) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay/chromeos-base/chromeos-dev $ ls
chromeos-dev-0.1.0-r94.ebuild chromeos-dev-0.1.0.ebuild
(cr) (release-R35-5712.B/my-overlay) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay/chromeos-base/chromeos-dev $ vi chromeos-dev-0.1.0-r94.ebuild
(略)
RDEPEND="${RDEPEND}
pam? ( app-admin/sudo )
app-admin/sysstat
app-arch/gzip
app-arch/tar
app-arch/p7zip ←追加
profile? (
(略)
ここで、chromeosの下には
chromeos-0.1.0-r94.ebuild
chromeos-0.1.0.ebuild
の２つのファイルがあり、前者は後者へのシンボリックリンクになっています。
編集を加えた後は、ビルドシステムが変更を認識できるようにシンボリックのリビジョン番号をカウントアップします。
(cr) (release-R35-5712.B/my-overlay) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay/chromeos-base/chromeos-dev $ mv chromeos-dev-0.1.0-r94.ebuild chromeos-dev-0.1.0-r95.ebuildこれでChromium OSに取り込まれるはずなので、build_packagesします。
(cr) (release-R35-5712.B/my-overlay) chromium@Ubuntu12 ~/trunk/src/third_party/chromiumos-overlay/chromeos-base/chromeos-dev $ cd ../../../../scripts/
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./build_packages --board=${BOARD}
ChromeOS version information:
CHROME_BRANCH=35
CHROME_VERSION=
CHROMEOS_VERSION_STRING=5712.32.2014_04_28_2221
CHROME_BASE=
INFO : Elapsed time (run_chroot_version_hooks): 0m0s
（略）
Calculating deps...
Deps calculated in 0m18.5s
[ebuild N ] app-arch/p7zip-9.20.1-r4 to /build/x86-generic/ USE="pch -doc -kde -rar -static -wxwidgets" 0 kB
[ebuild U ] chromeos-base/chromeos-dev-0.1.0-r95::chromiumos [0.1.0-r94::chromiumos] to /build/x86-generic/ USE="X opengl pam profile usb -cras -tpm" 0 kB
Total: 2 packages (1 upgrade, 1 new), Size of downloads: 0 kB
（略）
Merge complete
Done
Builds complete
INFO : Elapsed time (build_packages): 1m27s
Done
ビルドがうまくいったようなので、続けてbuild_imageします。
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./build_image --board=${BOARD} --noenable_rootfs_verification dev
ChromeOS version information:
CHROME_BRANCH=35
CHROME_VERSION=
CHROMEOS_VERSION_STRING=5712.32.2014_04_28_2223
CHROME_BASE=
（略）
INFO : Elapsed time (build_image): 8m21s
To copy the image to a USB key, use:
./image_to_usb.sh --from=../build/images/x86-generic/R35-5712.32.2014_04_27_2201-a1
To convert it to a VMWare image, use:
./image_to_vm.sh --from=../build/images/x86-generic/R35-5712.32.2014_04_27_2201-a1 --board=x86-generic
build_packagesでビルドを行うと、各パッケージのバイナリは
/build/${BOARD}/package/パッケージカテゴリ名
の下にtbz2形式で圧縮されて格納されます。この中から必要なものがbuild_imageの実行時に展開されてディスクイメージの中にコピーされるようになっています。
終わったらイメージをマウントして中を確認し、追加したコマンドが含まれているか確認します。作成したビルドイメージのルートパーティションは/tmp/mにマウントされるので、確認する場所は/tmp/m/usr/local/binになります。ここに7*で始まるファイルがあるかチェックします。
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./mount_gpt_image.sh --board=${BOARD} -f $(./get_latest_image.sh --board=${BOARD})
1+0 レコード入力
1+0 レコード出力
1 バイト (1 B) コピーされました、 0.000261486 秒、 3.8 kB/秒
Setting up symlinks for /usr/local for /tmp/s/dev_image
INFO : Image specified by /mnt/host/source/src/build/images/x86-generic/R35-5712.32.2014_04_28_2223-a1 mounted at /tmp/m successfully.
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ls /tmp/m/usr/local/bin/7*
/tmp/m/usr/local/bin/7z /tmp/m/usr/local/bin/7za /tmp/m/usr/local/bin/7zr
うまくできていたようです。確認が終わったらイメージはアンマウントします。
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ ./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
もしうまく取り込まれないようであれば、/build/${BOARD}/package/Packageファイルを開いて、CPV: chromeos-base/chromeos-dev-0.1.0-rXX
という文字列を検索します。XXはebuildファイルをリネームしたときに指定したリビジョン番号です。すると以下のような内容が見つかるはずです。
CPV: chromeos-base/chromeos-dev-0.1.0-r95 DEFINED_PHASES: - DEPEND: app-benchmarks/i7z dev-util/turbostat sys-apps/dmidecode sys-apps/pciutils （略）
このDEPEND:の後に取り込まれるパッケージがずらずら書いてありますので、この中に自分が追加したパッケージが確かに含まれていることを確認します。含まれていない場合はどこかにミスがあります。
うまくいかないケースではリビジョンをあげ忘れて前のリビジョンしかヒットしない場合が多いのではないかと思います。
binutilsはパッケージを使ったインストールを避けたほうが良い
binutilsはp7zipと違って~/trunk/src/third_party/portage_stableの下にパッケージが置かれていませんが、chromiumos_overlaysの中にはパッケージが存在しています。
このbinutilsパッケージはChromium OSにインストールするためにあるものではなく、SDKのビルド環境を作成するために存在しています。なので、このbinutilsパッケージに対して細工を加えると正しくChromium OSがビルドできなくなります。
emerge-x86-generic binutils --unmerge
などとしてパッケージを削除してしまうと、ビルドに使うldコマンドが消えてしまってバイナリが作れなくなります。上で書いたcros_portage_upgradeコマンドを実行して更新をかけるのも避けるべきです。
どうしてもbinutilsパッケージをChromium OSのイメージに取り込みたいときは、以下のようにbuiild_imageコマンドで引数にdevではなくtestを指定するするのが簡単です。
./build_image --board=${BOARD} --noenable_rootfs_verification test
こうするとビルド環境で使われているbinutilsパッケージがChromium OSに取り込まれます。ただ、この方法ではchromiumos-overlay/chromeos-base/chromeos-testというパッケージに書かれているすべてのパッケージがChromium OSに取り込まれます。いろいろ有益なツールもあるのでこれでもいいかと思います。
この方法で追加されるパッケージはchromeos-devに依存関係を追記したときと同じで/usr/local配下にインストールされます。上でも書いたように/usr/local配下にbinutilsをインストールするとシンボリックリンクが壊れるので後で手作業で直さないといけません。 ということで、binutilsについては今のところスマートにインストールする方法はないみたいです。
［関連記事］
[悲報] Chrome R44でffmpegsumoが消えた
Dev serverによる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にインストールしようとして挫折した話
VAIO Type PでChromium OSをUSBメモリからブートするときのメモ
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
[0回]
2014/04/19 (Sat) 20:38
もうそろそろ、来月あたりにはChromium OSのStable ChannelがR34からR35に切り替わるんじゃないかなとおもってR35の最新(release-R35-5712.B)をビルドしてみたのですが、これがVAIO Type Pで動きませんでした。
ブートするとChromiumのロゴが出た後にマシンがリブートしてしまい、OSが立ち上がってくれません。
以前こちらの記事でビルドしたときのChromium OS R35はPlatform versionが5682というものでしたが、今時点では5712に上がっています。おそらく何かが変わったのだろうとおもいログを調べたところ、/var/log/chromeの下に大量にログが出ていました。
そのログはどれも以下のようなメッセージを出力して終わっていました。
落ちているのはカーネルではなくChromiumです。どうやらGPU関係で何かエラーが出ていてGUIが起動できないみたいです。ログが大量に出ているのは何度もリトライしてその都度落ちたからっぽい。
とはいえ、最初のロゴは出ているので、全然グラフィックが使えていないわけではないっぽい。
いままでトラブルは全部カーネルでChromiumのトラブルは初だったので、どこをどう調べたらよいかよくわからなかったのですが、ログを見る限りでは/sbin/session_manage_setup.shからChromiumを起動するタイミングで落ちているっぽいので/sbin/session_manager_setup.shが動いていた時と何か変わってないか比べてみると、以下のような差がありました。
GPU_FLAGSの設定で--gpu-sandbox-failures-fatalがnoだったのがyesに変わっています。ものすごくにおいます。さっそくここをnoに書き換えてブートしてみたらあっさり起動しました。
session_manager_setup.shをビルド時に書き換える方法はこちらの記事で触れていますので参考にしてください。
とりあえず解説なしで手順だけ書き連ねると以下のような感じになります。
上記手順と以前書いたPATAドライバの組み込みを行い、後はbuild_imageスクリプトでイメージを作ればOKです。
なお、この辺の修正については以下のURLでアナウンスされていました。
Re: PSA: Chrome GPU sandbox failures are now fatal
日付を見たら3月25日で、まさに私が以前ビルドに成功した翌日でした。一日遅かったらビルドしたものが動かなかった可能性が高いです。 私の以前の記事を参考にしてビルドしてくださった方がコメントで動かないとおっしゃっていましたが、コメントでいただいた現象から見ても多分この問題だと思います。
あの記事を見て試してみた人がことごとく失敗していたのかもしれないと思うと申し訳ない思いです。
今回調べる気になったのも動いた実績があったからです。もし動いた実績がなく今回の現象が起きていたらVAIO Type Pでは動かないんだとあきらめていたでしょうね。そういう意味では運がよかったなぁと思います。
※現時点で最新のChromium OSはR36になっていますが、R36はこちらではまだ確認していません。
［関連記事］
[悲報] Chrome R44でffmpegsumoが消えた
Dev serverによるChromium OSのアップデート
Chromium OSにパッケージを追加する
安定版ソースを使ってChromium OSをビルドする
勝手ビルド版Chromium OSとGoogleドライブの連携
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メモリからブートするときのメモ
ブートするとChromiumのロゴが出た後にマシンがリブートしてしまい、OSが立ち上がってくれません。
以前こちらの記事でビルドしたときのChromium OS R35はPlatform versionが5682というものでしたが、今時点では5712に上がっています。おそらく何かが変わったのだろうとおもいログを調べたところ、/var/log/chromeの下に大量にログが出ていました。
そのログはどれも以下のようなメッセージを出力して終わっていました。
[12328:12328:0419/030144:ERROR:gpu_process_transport_factory.cc(436)] Failed to establish GPU channel. [12328:12328:0419/030144:FATAL:gpu_process_transport_factory.cc(211)] Failed to create UI context, but can't use software compositing with browser threaded compositing. Aborting.
落ちているのはカーネルではなくChromiumです。どうやらGPU関係で何かエラーが出ていてGUIが起動できないみたいです。ログが大量に出ているのは何度もリトライしてその都度落ちたからっぽい。
とはいえ、最初のロゴは出ているので、全然グラフィックが使えていないわけではないっぽい。
いままでトラブルは全部カーネルでChromiumのトラブルは初だったので、どこをどう調べたらよいかよくわからなかったのですが、ログを見る限りでは/sbin/session_manage_setup.shからChromiumを起動するタイミングで落ちているっぽいので/sbin/session_manager_setup.shが動いていた時と何か変わってないか比べてみると、以下のような差がありました。
chromium@Ubuntu12:~$ diff -u chromiumos/chroot/build/x86-generic/sbin/session_manager_setup.sh chromiumR35-stable-5712/chroot/build/x86-generic/sbin/session_manager_setup.sh --- chromiumos/chroot/build/x86-generic/sbin/session_manager_setup.sh 2014-03-21 07:38:52.000000000 +0900 +++ chromiumR35-stable-5712/chroot/build/x86-generic/sbin/session_manager_setup.sh 2014-04-19 10:36:23.604701439 +0900 @@ -382,11 +382,15 @@ HANG_DETECTION_FLAG="--enable-hang-detection=5" # And do it FASTER! fi -GPU_FLAGS="--gpu-sandbox-failures-fatal=no" +GPU_FLAGS="--gpu-sandbox-failures-fatal=yes" if use_flag_is_set gpu_sandbox_allow_sysv_shm; then GPU_FLAGS="$GPU_FLAGS --gpu-sandbox-allow-sysv-shm" fi +if use_flag_is_set gpu_sandbox_start_after_initialization; then + GPU_FLAGS="$GPU_FLAGS --gpu-sandbox-start-after-initialization" +fi + VIDEO_FLAGS= if is_board peach_pit || is_board peach_pi; then VIDEO_FLAGS="--enable-webrtc-hw-vp8-encoding"
GPU_FLAGSの設定で--gpu-sandbox-failures-fatalがnoだったのがyesに変わっています。ものすごくにおいます。さっそくここをnoに書き換えてブートしてみたらあっさり起動しました。
session_manager_setup.shをビルド時に書き換える方法はこちらの記事で触れていますので参考にしてください。
とりあえず解説なしで手順だけ書き連ねると以下のような感じになります。
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cros_workon --board=${BOARD} start chromeos-login
INFO : Started working on 'chromeos-base/chromeos-login' for 'x86-generic'
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ cd ../platform/login_manager/
(cr) (release-R35-5712.B/(eb046e1...)) chromium@Ubuntu12 ~/trunk/src/platform/login_manager $ repo start my_login_manager .
(cr) (release-R35-5712.B/my_login_manager) chromium@Ubuntu12 ~/trunk/src/platform/login_manager $ vi session_manager_setup.sh
GPU_FLAGS="--gpu-sandbox-failures-fatal=no ← yesをnoに書き換え
(cr) (release-R35-5712.B/my_login_manager) chromium@Ubuntu12 ~/trunk/src/platform/login_manager $ cd ../../scripts/
(cr) (release-R35-5712.B/(696ce08...)) chromium@Ubuntu12 ~/trunk/src/scripts $ FEATURES="noclean" cros_workon_make --board=${BOARD} chromeos-login --install
WARNING : Cleaning up stale workdir: /build/x86-generic/tmp/portage/chromeos-base/chromeos-login-9999/work/chromeos-login-9999
（略）
上記手順と以前書いたPATAドライバの組み込みを行い、後はbuild_imageスクリプトでイメージを作ればOKです。
なお、この辺の修正については以下のURLでアナウンスされていました。
Re: PSA: Chrome GPU sandbox failures are now fatal
日付を見たら3月25日で、まさに私が以前ビルドに成功した翌日でした。一日遅かったらビルドしたものが動かなかった可能性が高いです。 私の以前の記事を参考にしてビルドしてくださった方がコメントで動かないとおっしゃっていましたが、コメントでいただいた現象から見ても多分この問題だと思います。
あの記事を見て試してみた人がことごとく失敗していたのかもしれないと思うと申し訳ない思いです。
今回調べる気になったのも動いた実績があったからです。もし動いた実績がなく今回の現象が起きていたらVAIO Type Pでは動かないんだとあきらめていたでしょうね。そういう意味では運がよかったなぁと思います。
※現時点で最新のChromium OSはR36になっていますが、R36はこちらではまだ確認していません。
［関連記事］
[悲報] Chrome R44でffmpegsumoが消えた
Dev serverによるChromium OSのアップデート
Chromium OSにパッケージを追加する
安定版ソースを使ってChromium OSをビルドする
勝手ビルド版Chromium OSとGoogleドライブの連携
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メモリからブートするときのメモ
ランキングに参加してみました。クリックしていただければ嬉しいです。
にほんブログ村 |
パソコン ブログランキングへ |
[1回]
プロフィール
ＨＮ：
zui
性別：
非公開
カテゴリー
最新記事
(09/28)
(09/03)
(08/26)
(07/23)
(05/24)
PR
忍者カウンター