かけまわる子犬。

と、いうことで、ちょっと前に掲載した「FreeBSD/arm のクロスコンパイル環境をもっと簡単に作る。」では ports のクロスコンパイル環境が整ったので、早速 X と xfce4 のコンパイルに挑んでみました。

Raspberry Pi 2 で X を動かすためにインストールした主なものは以下の通り。あ。 ports の枝番は削っています。

・xorg-7.7
・xfce-4.12
・emacs24-24.5
・zh-fcitx-4.2.8.6
・ibus-1.5.9
・ja-mozc-server-2.17.2106.102

X はウィンドマネージャも含めてフルスペックで、更に日本語入力もできないとダメだよね。と、いうことで ibus と fcitx と mozc までコンパイルしました。あと、xfce4 は Thunar をインストールし、デスクトップに必要なマルチメディア系のアプリまでインストールしています。
コンパイルした ports の総数は 大体 490 個くらいっ!! 自分でいうのもなんだけど、すげーすげー;-)。

ちなみに FreeBSD/arm は 8GB の MicroSD に Xorg と xfce4 をインストールして / パーティションは約 30% ほど消費しています。

クロスコンパイル環境では portmaster -D -a も動作するのでバージョンアップにも対応しています。コンパイルしたバイナリは以下の URL にあるので良かったら持って行ってください。

http://distfiles.icmpv6.org/packages/All.armv6/
ftp://ftp.icmpv6.org/packages/All.armv6/

今後、 ports-CURRENT を追いかけて行って portmaster -D -a してバージョンアップしたものもどんどん追加していく予定です。

 
さてと。先に ports/packages の内容を書いてみましたが、実際にクロスコンパイル環境でコンパイルしたので、そのことについてちょっと書いてみます。

 
1). クロスコンパイル環境の準備
以前のエントリで ports の ports-mgmt/poudriere-devel/ を試したと書いているのですが、そのとき

# poudriere jail -c -j CURRENT-armv6 -m svn -a arm.armv6 -v head

 
を実行したので FreeBSD/arm CURRENT の jail 環境ができてしまいました。これを tar で固めて、最速の仮想マシン上に持って行ってクロスコンパイル環境を構築しました。FreeBSD/amd64 10.1-RELEASE-p16 の環境に tar で固めた FreeBSD/arm 環境を展開し、前回記載した chroot 用スクリプトで環境を整えて、実際に ports の make install を行いました。

母艦の FreeBSD/amd64 10.1-RELEASE-p16 上に qemu をインストールして FreeBSD/arm CURRENT に chroot します。 /usr/ports は母艦側のディレクトリを mount_nullfs して利用し、ひたすら make という、以前書いたのを実際にやってみた。と、いうことですね。

環境の作り方は前回のエントリを参考にしてください。

 
2). chroot はネットワークが使えない
chroot した FreeBSD/arm の環境で ports を make しようとしても make fetch でエラーになりソースコードを取りに行ってくれません。
chroot した状態で ifconfig -a とか打つと解りますが qemu が Qemu unsupported ioctl などというメッセージを出します。と、いうことで chroot した環境ではネットワークは使えないと認識したほうが良いでしょう。

では、ports のソースコードはどうやって取りに行くかというと、母艦側で揃えるしかありません。そもそも /usr/ports/ は母艦側のディレクトリを FreeBSD/arm のディレクトリに mount_nullfs しているので見ているところは一緒です。

母艦側でコンパイルしたい ports で以下のコマンドを打ちます。以下は editors/emacs/ のコンパイルの例です。

# cd /usr/ports/editors/emacs
# make fetch-recursive

 
ports のコンパイルのオプションには fetch-recursive というのがあるんですね。依存関係でインストールされる ports も含めてソースコードをダウンロードして来てくれます。 make config-recursive ってのは依存関係にある全ての ports の make config を実行しますが、それと似たようなモノですね。それにしても嬉しい make のオプションです。

母艦側でソースコードがゲットできたら FreeBSD/arm 側で実際に ports の make に入ります。
以前のエントリでも書きましたが遅いのでひたすら待ちましょう・・。

 
2). クロスコンパイル環境でコンパイルできないモノがある
いやー。さすがに 490 個くらいコンパイルすると qemu+chroot の環境でコンパイルが通らない ports が何個かありました。以下はそのリストです。

・emacs-nox11-24.5,3
・emacs24-24.5_1,3
・jsoncpp-0.6.0.r2_2
・py27-cairo-1.10.0_2
・tdb-1.3.4,1
・talloc-2.1.2
・tevent-0.9.24
・ja-mozc-server-2.17.2106.102

有名どころでは emacs ・ mozc 辺りでしょうか。 samba 辺りで利用される t シリーズ(tdb ・ talloc ・ tevent)も make が通りませんでした。

原因としては chroot 下で動作している qemu が make の実行時に core dump してしまいます。なのでクロスコンパイル環境では make が通りませんでした。

上記の ports の場合、実機 (Raspberry Pi 2 上の FreeBSD/arm) では make が通ったので、実機で作成した packages をクロスコンパイル環境に pkg add してあげて make を続行します。

 
クロスコンパイル環境で make が通らなくても実機でコンパイルが完走すれば良いのですが、実機でもコンパイルが通らないものがありました。
lang/spidermonkey170 です。これは困った。 FreeBSD の ML でも話題に上がっているようです。

FreeBSD/amd64 では問題なくコンパイルが通るのに FreeBSD/arm では通らない。なんでやねん?! と、いうことで試行錯誤を重ねた結果 FreeBSD/arm でむりくりコンパイルを通しました。

以下、手順です。

o. FreeBSD/arm 側で以下のコマンドを実行

# cd /usr/ports/lang/spidermonkey170
# make configure

 
o. 母艦側で続けて実行

# cd /usr/ports/lang/spidermonkey170/work/mozjs17.0.0/js/src
# gmake clean
# configure

 
FreeBSD/arm で実行した make configure の結果を母艦側で全てぶっ飛ばしてソースに対して FreeBSD/amd64 側で configure を実行します;-)。
その後 FreeBSD/arm 側に戻って make install を実行すると無事に make が通ります。これで ports 自体はインストールできるので、まぁヨシとしておきましょう;-)。

あ。僕は mozjs17.0.0 ってのはどこで利用されているのか知らないので実際に正しい動作をしているのか、よく判りませんf(^^;;。

関連性でインストールされるので必要だからとりあえず ports でコンパイルを通すワザを発見した。と、いう感じですf(^^;;。

 
と、ここまで書いたと、いうか、コンパイルを通したのですが、その後、原因が判明したようですね。どうやら llvm のバグで ARM の場合に発生するようです。

FreeBSD では gcc を使うようにするとコンパイルが通るようですね。

再度書きますが、僕の make の方法は ports の関連性に必要な他のプログラムのコンパイルを進ませるためにむりくりの方法を編み出した。と、いうことにしておいてくださいf(^^;;。

http://comments.gmane.org/gmane.os.freebsd.devel.cvs.ports/349757

ちゅーこって FreeBSD/arm 用に gcc-4.8.5 を make しないと・・。 orz

 
とまぁ、こんな感じで地道に qemu+chroot の環境で ports をじっくりと make していきます。 490 個程度の ports をコンパイルするのに、途中で make fetch やコンパイルエラーで止まることもあるので、大体一週間程度でしょうかねぇ。 ひたすらがんばります。

 
3). Raspberry Pi 2 で X 起動
一通り packages 化された ports が出来上がったので全てを実機にインストールして実際に X を起動してみます。
今回、僕がチョイスしたバージョンは FreeBSD 11.0-CURRENT r286285 です。このバージョンの CURRENT は HDMI にディスプレーを接続するとフラッシュのようにブラックアウトする場合があるのでちょっと困りもの。 OS と、いうか CURRENT の問題なのか、ハードウェアの問題なのかは良く判りません。
あと、 r286285 は default の root のパスワードが設定してない!! ので シングルユーザに落として /etc/master.passwd の :*: の * を消してあげる必要があります。 orz
ちなみに r286893 では root のパスワードが設定してありました;-)。

 
さてと。気を取り直して ~/.xinitrc に xfce4 を起動するように記述して startx です。

おぉーーっ!!

ディスプレーのすぐしたにあるのが Raspberry Pi 2 の FreeBSD で HDMI で表示しております。

xorg.conf のディスプレードライバには scfb を指定します。 ports 的には x11-drivers/xf86-video-scfb をインストールしてあげます。 vesa ではないです。

xfce4-terminal で文字を打つとぬるぬると動いていく感が良いですね。 NoAccel 感満載です;-)。

hald を動かすと USB のキーボード・マウスも無事に動作します。なので X の環境で利用する分には問題は無いですね。あとは細かいところの設定をしていくと xfce4 は無事に動作するようになるのではないでしょうか。

あ。mozc がどうも起動しないんですよね。 core dump する。まだ深くは追ってないのですが、環境整わせつつ、おいおい見ていきたいと思います。

多分 mozc_server を FreeBSD/arm でコンパイルして動かしたのは、僕が世界初ではないかなぁ;-)。

 
と、いうことで今回は ports のクロスコンパイル環境で make したものを利用して Raspberry Pi 2 上の FreeBSD/arm で X まで動かしてみました。

これでバリバリと Raspberry Pi 2 を利用するようになるかな？ データセンタに行った時とかに NotePC の代わりに Raspberry Pi 2 を取り出してバリバリ仕事する。とか、良いかも;-)。

 
Raspberry Pi 2 に FreeBSD/arm インストールしたけど ports のコンパイルが大変なので断念している方、 packages を作ったので是非 X が起動するところを見てみてください。ただ、さすがに KDE4 を packages 化しようとは思わないですがf(^^;;。

僕はこのあと、どうしようかなぁ・・。

前回のエントリは「FreeBSD/arm の ports コンパイル環境の作成。」というヤツを書きました。

ports の ports-mgmt/poudriere-devel/ というのを利用すると FreeBSD/arm のクロスコンパイル環境ができますよ。っていうやつです。

しかし、環境構築が大変すぎる。もっと簡単にできないのか？などと思うわけですね。環境構築に時間が掛かり過ぎる点は以下の辺り。

・FreeBSD のソース一式を svnweb から取ってきて make buildworld する。
・ports ツリー一式を portsnap で取ってきてインストールする。

時間が掛かり過ぎるよー。ってんで、今回はもっとお気楽に環境を構築する案を思いつきました。

ports-mgmt/poudriere-devel/ は jail に FreeBSD/arm のバイナリの環境を構築して qemu でエミュレートして動作しているようです。そのためにソースコード取ってきたり ports ツリー取ってきたりしているんですが、既にあるものを使おう。ってのが今回の趣旨です。

 
1). 準備するモノ
まずは Raspberry Pi 2 に FreeBSD をインストールします。多分 CURRENT が良いのかもしれないです。
Raspberry Pi 2 用の img を用意して SD カードに dd したら、同じバージョンの FreeBSD/amd64 の iso イメージもダウンロードしてきて、仮想環境に FreeBSD/amd64 をインストールします。あ。実機にインストールしても全然良いんですけどね;-)。

僕の場合、は以下のような環境を作りました。

o. Raspberry Pi 2 の FreeBSD/arm

FreeBSD wanchan.running-dog.net 11.0-CURRENT
FreeBSD 11.0-CURRENT #0 r284544: Thu Jun 18 19:36:01 UTC 2015
root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2  arm

 
o. 仮想環境上の FreeBSD/amd64

FreeBSD nyanchan.running-dog.net 11.0-CURRENT
FreeBSD 11.0-CURRENT #0 r284544: Thu Jun 18 12:24:12 UTC 2015
root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

 
ちなみに、仮想環境上の FreeBSD/amd64 が母艦になります。ここで FreeBSD/arm の ports の make をする予定です。

この後、母艦側で ports の emulators/qemu-user-static/ をインストールします。

これで、ほぼ九割の環境が整いました;-)。

ports-mgmt/poudriere-devel/ とかインストールする必要はありません。 jail 環境用に make buldworld もする必要はありません。

と、いうことでここでだいたいの構成がわかってきたと思いますが;-)。

 
2). 環境構築
まず、 Raspberry Pi 2 側の FreeBSD/arm で nfsd を起動します。

以下は /etc/exports の設定内容。

/   -network 192.168.1.0 -mask 255.255.255.0 -maproot=root
/   -network 2001:470:fe36:1234::/64 -maproot=root

 
強引ですねぇ。 / を NFS mount するようにします;-)。
あ。/etc/rc.conf の設定は今回は書かないです。

 
続いて母艦側の FreeBSD/amd64 側で nfs client を有効にします。こちらも /etc/rc.conf の設定は書かないですが、大丈夫ですね？

あとは母艦側で mount_nfs を実行します。

# mount_nfs -o rw wanchan:/ /home/armv6

 
うひょー。これで ports-mgmt/poudriere-devel/ でいうところの jail 環境ができてしまいました。ちょっと強引ですが。しかし、 make buildworld したのと一緒の状態ですね;-)。

一個、そして一回だけ、以下のコマンドを打ちます。

# cp -pr /usr/local/bin/qemu-arm-static /home/armv6/usr/local/bin/

 
FreeBSD/arm 側の /usr/local/bin/ に FreeBSD/amd64 上でコンパイルした qemu-arm-static をコピーしてあげます。これで準備は全て整いました。

 
まぁ、FreeBSD/arm の環境一式は色々抜き出すことができます。例えばインストールの iso イメージを mount して抜き出すとか、 ports-mgmt/poudriere-devel/ をインストールしてできた jail 環境を tar で固めて持ってくるとかですね。

しかし、 make buildworld を走らせるのは辛すぎる・・。ってのが今回の根本にあります。
make buildworld するより OS 二つインストールしたほうが速くないかい？ みたいな;-P。

 
3). 環境構築スクリプト
まずは下に起動用のサンプルを書きますね。

#!/bin/sh

HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin/:/usr/local/bin
export HOME PATH

export LC_CTYPE=ja_JP.UTF-8
export LANG=ja_JP.UTF-8

ARMV6DIR='/home/armv6'

kldload imgact_binmisc.ko

binmiscctl add armv6 --interpreter "/usr/local/bin/qemu-arm-static" --magic "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff" --size 20 --set-enabled

mount_nullfs -o rw /usr/ports ${ARMV6DIR}/usr/ports
#mount -t devfs devfs ${ARMV6DIR}/dev

chroot ${AMD64DIR}

 
解る人は何をしているか解ると思います。

jail 環境作るの大変なので直接 Raspberry Pi 2 の FreeBSD/arm の環境を利用してしまいます。
そして chroot しています。 jexec でなくとも chroot で十分なのでそうしているんですが。

ちと説明をすると、

kldload は自動的にしてくれると思います。

binmiscctl add armv6 の行は qemu を使うおまじないです。このコマンドを叩かないと chroot したときに /bin/tcsh えぐぜっくふぉーまっとえらー。とか言われます。

FreeBSD/arm 側に母艦の /usr/ports を mountしてあげます。これで portsnap で ports ツリー一式取ってくる必要がなくなります;-)。

mount -t devfs は多分必要ないと思います。 jail 環境の場合は必要なのですが、今回は nfs mount した環境なのですねぇ。

と、いうことで最後に chroot します。

うひひ。これで FreeBSD/amd64 上に FreeBSD/arm の環境が整いました。ports のコンパイルや(多分)カーネルのコンパイルなど、もう何でもできます;-)。

このスクリプトは別途置いといたのでダウンロードしてください。ブログだと binmiscctl add armv6 の行が全部表示できないので・・。

 
ちなみに FreeBSD/arm 側が CURRENT で母艦側が 10.1-RELEASE だったりすると ports のコンパイル時に uname -r のチェックでエラーになってしまいます。 chroot した FreeBSD/arm 側で uname -r すると母艦側のバージョン情報を返してしまいます。あたたた。なので、 FreeBSD/arm 側と母艦側では FreeBSD のバージョンを揃える必要があります。

が、uname には裏ワザがあるようで、

$ uname -r
10.1-RELEASE-p16
$ setenv UNAME_r 11.0-CURRENT
$ uname -r
11.0-CURRENT
$

 
おやおや。環境変数で uname -r が変更できるのね。と、いうこで母艦が 10.1-RELEASE-p16 で FreeBSD/arm 側は 11-CURRENT の状態で ports を make してみましたが ports のコンパイルが始まって configure の実行中に「存在しないシステムコール (core dumped)」などと言われてコンパイルが途中で止まってしまうのでありました。

ふむ。10.1-RELEASE から 11-CURRENT で機能が追加された分があったりして、その辺りが問題となってしまうのでしょうなぁ・・。まぁ、取り合えずはこの環境で利用するのはやめて、母艦側も FreeBSD/arm 側もバージョンは揃えた。と、いうことになります。

 
2015/08/18 加筆
母艦側の FreeBSD/amd64 と FreeBSD/arm 側でバージョンが違っていてもコンパイルできることが解りました。 母艦側の /usr/local/bin/qemu-arm-static と FreeBSD/arm 側のヤツを同じモノにすると無事に動作します。
母艦側の /usr/local/bin/qemu-arm-static は 10.1-RELEASE-p16 で make したモノ、 FreeBSD/arm 側のヤツは 11.0-CURRENT で make したモノ。と、いうふうに異なるバージョンで make したものがインストールされていると「存在しないシステムコール (core dumped)」と出て動作しません。
/usr/local/bin/qemu-arm-static は母艦側で make したものを FreeBSD/arm 側に cp してあげましょう。

 
4). 実際に使ってみると
ports の make は一応問題無しですね。母艦側で make install したやつは FreeBSD/arm で pkg info で見るとちゃんと見えます。 portmaster -D -a も無事に動きます。

しかし、遅い・・。今回の母艦側仮想マシンは CPU 4Core に 1GB のメモリを用意したのですが遅いです。
FreeBSD/arm を NFS しているし SD カード上に入っているのでディスクアクセスが遅いのかもしれません。

それにしても chroot した先で色々動かすと全て qemu がワンクッション入るのでそれが遅いのかもしれません。僕はまだ本格的に qemu を使ったことが無いのでアレですが、パフォーマンスチューニングすればもっと速くなるのかな？

28468 1 I  0:01.76 /usr/local/bin/qemu-arm-static /bin/tcsh -i
28672 1 S+ 0:00.83 qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/make install
28689 1 R+ 0:00.48 qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/make config

 
母艦側で ps -ax するとこんな感じで chroot 先の全てのプロセスが qemu 経由で動いております。

 
母艦側で ports のコンパイルとかすると、遅いけど律儀に進んでいきます。そのとき FreeBSD/arm 側では CPU ロードアベレージは低いままなので、頑張っているのは母艦側。と、いうことになり、遅いけど Raspberry Pi 2 は無傷な状態ですね。

 
とまぁ、こんな感じの FreeBSD/arm のクロスコンパイル環境なのですが、それにしても qemu が絡むと遅くてしょうがない(と、僕は思っているんだけど、本当に qemu が原因なのか、僕はまだ特定していません・・f(^^;;)。

その昔、 Linux で BB ルータ作っていたんですが、組み込み Linux の ARM のバイナリを i386 の Linux 母艦で作っていたときは qemu 使ってなくて、もっとサクサクとコンパイルができていたんだけど・・。
qemu を使わずに ports をコンパイルする方法をやっぱり見つけないとダメっぽい。ってのが、今回の結論でしょうかねぇ。

それにしても ports-mgmt/poudriere-devel/ で色々仕掛けが解ったので良かったです。そして、それを参考にして ports-mgmt/poudriere-devel/ を使わない、もっと楽したコンパイル環境構築がこうして解ったわけですしね。ネタになったかぁ？ ;-)。

次回、qemu を使わない ports のコンパイル環境の構築について掲載できるか?! (多分無理;-)

実は某所で発表した FreeBSD/arm に関する資料があるのですが ports のコンパイル環境構築についても触れています。その時は qemu を使わずに頑張ったのですが、結局ダメでした。その資料を一応おいておきますね。

FreeBSD/arm Raspberry Pi 2 ModelB で動作確認

 
ちなみに文章は Microsoft Office2013 で作りましたが、資料の発表は okular (KDE 4 universal document viewer) で行いました。 calligrastage (KDE graphic art and office suite) では文章を作成するのに苦痛でして・・f(^^;;。
そして、okular は pptx をサクっと開けてしまうすぐれものです;-)。

以前のエントリで「SVN サーバを構築して FreeBSD のソースをミラーする。」と、いうのを書いたのですが、これはプロトコル的には http:// にしか対応していないんですね。svn co には http: とか https: で十分なのですが、そーではなく、ちゃんと port 3690 に対応したデーモンも起動してあげる必要がある。と、いうことですね。

と、いうことで今回は port 3690 で svn co できるようにします。

なお、 svn のミラーサイトの構築に付いては上の「SVN サーバを構築して FreeBSD のソースをミラーする。」をまず初めに読んでたください。その環境ができあがったあとの話として、今回のエントリとなります。

 
1), /etc/service の確認
default の FreeBSD の設定で入っているので、どーでも良い話なのですが、一応、以下のコマンドを叩いて確認します。

$ grep svn /etc/services
svn             3690/tcp   #Subversion
svn             3690/udp   #Subversion

 
大丈夫そうでしょうかね。

 
2), デーモンの設定
subversion をインストールすると svnserve というのが /usr/local/bin/svnserve としてインストールされています。こいつに -d オプションを指定してあげるとデーモンモードで起動して port 3690 に対してアクセスできるようになります。

/usr/local/etc/rc.d/svnserve と、いうファイルがあると思うので、そこの上の部分を持ってきて /etc/rc.conf に設定します。

僕の場合は以下のように指定しました。

svnserve_enable="YES"
svnserve_flags="-d --listen-port=3690 --listen-host 0.0.0.0"
svnserve_data="/home/svnweb"
svnserve_user="svn"
svnserve_group="svn"

 
svnserve_data で svn 用のディレクトリを指定します。
svnserve_user と svnserve_group の svn というのは存在していなかったのでユーザとグループを作成しました。

以上で設定は完了。あとは service svnserve start とすれば起動することでしょう。
telnet で port 3690 が開いているか確認します。

 
3), inetd での起動
svnserve は inetd 経由でも起動できるようです。 /etc/inetd.conf には以下の行を追加してみてください。

svn stream tcp nowait svn /usr/bin/svnserve svnserve -i
svn stream tcp6 nowait svn /usr/bin/svnserve svnserve -i

 
なんとっ!! svn は IPv6 には対応してないようで、実際には tcp6 という行は必要ないですね・・。orz
と、いうことで inetd を再起動して再度 telnet で port 3690 が開いているか確認します。
無事に接続できるようなのですが svn で取ってこようとするとエラーになるんですね。どうやら svnserve.conf という設定ファイルを用意すると、それを参照してくれるようなのですが FreeBSD の ports の devel/subversion は svnserve.conf を無視しているようです。

ports やソースコードを眺めたのですが conf/svnserve.conf というのが曖昧で、どこを指しているのか解らないんですね。あたた・・。

と、いうことで inetd モードは断念しました。

 
4), と、いうことで
デーモンモード起動して、とりあえずはヨシとしておきました。

今までは svn のミラーサイトは以下があったのですが、

http://svnweb.icmpv6.org/
http://svnwebv4.icmpv6.org/
https://svnweb.icmpv6.org/
https://svnwebv4.icmpv6.org/

これからはここに以下の URL も加わります;-)。

svn://svnweb.icmpv6.org/
svn://svnwebv4.icmpv6.org/

全部で三つのプロトコルに対応しました。ただし、 https の場合はヲレヲレ証明書なので、「証明書を無視する」オプションを有効にして利用して頂ければと思います;-)。

 
さてと。どうして svn:// に対応するようにしたか？ というと、このあと書くであろうと思われるエントリで利用して行きたいと思います;-)。