3月 112017
 

僕が持っている ThinkPad e145 は FreeBSD がインストールされていて、 suspend/resume するんだけど、resume 時、それはつまり目覚めたとき、パカっとフタを明けたときに default gateway が消えていたりして、ネットワーク的にはちょっと問題があったんですね。
まぁ、目覚めたあとにいつも route add していたんですけども。

そんなこんなで、resume 後に route add が必要なわけ、挙動をいよいよ調査してみることにしたんですね。

僕の FreeBSD の環境は以下です。

・FreeBSD/amd64 10.1-RELEASE
・ネットワーク環境は USB 接続の run0 -> wlan0

OS はまたもっと面白いことになってます。カーネル は 10.1-RELEASE でユーザランドが 10.3-RELEASE です。やってはいけない環境で動かしている。と、いうことですね。どうしてこんな環境で動かしているかについてはあとで少しお話します。

今の話題は resume 後に routing テーブルが消えている点についてですね。話を元に戻しましょう。

 
suspend して、その後 resume したときに起き上がってきた FreeBSD の動作ですが、だいたい以下のようになっているようです。

0. 実は suspend 時に USB デバイスが全部抜去される
1. resume 後に USB を認識してデバイスが接続される
2. resume 後に /etc/rc.resume が動く
3. devd が色々良きに計らってくれる (僕の環境では webcamd の再起動と pccard_ether のすーたと)
4. 自分で記述したスクリプトの動作
5. /etc/rc.resume の終了

まぁ、こんな感じですが、問題は 5. ですかね。

suspend で USB 機器が外されたということはつまりは wlan0 が無くなった。と、いうことなので、これで routing テーブルは全て消えます。
その後 resume して USB 機器が接続され wlan0 が認識され、wpa_supplicant が動き出してネットワークインターフェースには IP アドレスが付加されるようになります。

じゃぁ /etc/rc.resume の中で route add すりゃいんじゃね?

とか思うんですが /etc/rc.resume 内で route add してもそのときはまだ wlan0 に IP アドレスが付く前なので意味無いんですよね。

じゃぁ /etc/rc.resume の中で route add する前に sleep 30 とかすりゃいんじゃね?

とか、次に思いますよね。ところがっ!! /et/rc.resume はちょっとおかしな動作をしていて、 /etc/rc.resume が動作し終わったあとに wlan0 に IP アドレスが付加されるようです。

なので /etc/rc.resume の中で

sleep 30
route add default 192.168.1.1
route add -inet6 default fe80::1

 

などと書いても全く意味ない状態です。では、どうするか?と、いうと、上記の部分をスクリプト、例えば /usr/local/bin/routeadd.sh などとして準備します。
/etc/rc.resume には以下のように書きます。

/usr/bin/logger -t $subsystem route add default.
/usr/local/bin/routeadd.sh &

 

ここで注意しなければならないのは、スクリプトを記載したあと、最後に “&” を付けてバックグラウンドで処理させる必要があります。
動作的には /etc/rc.resume の実行後に wlan0 に IP アドレスが付くので /etc/rc.resume が実行中に sleep 30 してもまるで意味なくて route add されない状態です。なので “&” を書いてバックグラウンドに飛ばして、バックグラウンドのスクリプトが sleep 30 している間に /etc/rc.resume が終了して wlan0 に IP アドレスが付いたあと、 sleep 30 が終わり route add されるようにしないとダメなのであります。

この現象は USB NIC を利用しているからかもしれません。
動作的に resume 後に routing デーブルが消えていて、毎回、自分で route add 打つのが困難な人は上記のようにすれば良いのではないかと思います。

 
で、もう一個のネタを簡単に。

上のほうにも書きましたが、僕の ThinkPad e145 上で動作している FreeBSD はカーネル は 10.1-RELEASE でユーザランドが 10.3-RELEASE です。これ、FreeBSD の動作保証対象外の構成らしいですね。カーネルは新しく、ユーザランドが古い場合には問題ないらしいですが・・。

どうしてこんな環境で動かしているかというと ThinkPad を使っている人は 10.2-RELEASE 以降、suspend して resume したら LCD の明るさが最大になってしまい変更できなくなってしまったんですね。
10.1-RELEASE までだと Fn7,8 などで明るさが変更できた。 acpi_ibm や acpi_video がなくとも変更ができた。しかし、10.2-RELEASE 以降では Fn7,8 ボタンが効かなくなって、acpi_ibm の dev.acpi_ibm.0.lcd_brightness も有効にならなくて acpi_viode の hw.acpi.video.lcd0.brightness も使えなくなった。
resume 後に明るさを変えることができなくなったので、僕はいつまでもカーネルは 10.1-RELEASE を使い続けている。と、いうことです。

あと、別の手段としては ports から sysutils/acpi_call/ をインストールして ACPI のパラメータを表示したり変更したりできるようですが \_SB_.PCI0.VGA.LCD._BCM なパラメータなどをいじったりするなど、ちょっと試してみましたがダメでした。

acpi_call のコマンドイメージをちょっと書いておきます。使うには kldload acpi_call.ko する必要があります。

# acpi_call -vp '\_SB_.PCI0.VGA.LCD._BCM' -o i -i 50
Path: \_SB_.PCI0.VGA.LCD._BCM
Number of arguments: 1
Argument 1 type: Integer
Argument 1 value: 50
Status: 0
Result: 1

 
acpidump -d の結果を確認すると _BCM ってのが “Brightness Control Method” らしいです。他にも _BCL ってのがあって、こいつは “Brightness Control Levels” らしいです。
acpi_call で _BCM の値を 50 に変更してあげる。ってのが上記のコマンドと、その結果です。
しかし、値は反映されない・・。 orz

 
ThinkPad でも Nvidia のグラフィックスカードを利用しているヤツは Nvidia のツールで画面の明るさを変えられたり Intel の場合は graphics/intel-backlight/ などで画面の明るさを変えられるらしいです。
僕の ThinkPad e145 は Radeon のチップなので・・。orz

多分 10.2-RELEASE 以降で ACPI 周りに変更が入ったのでしょうなぁ。

ThinkPad e145 は BIOS モードと UEFI モードの両方で 11.0-RELEASE で試しましたが画面の明るさは変えることができませんでした・・。

と、いうことでももうしばらく、ってか、壊れるまで? 10.1-RELEASE の利用は続きそうです・・。

2月 222017
 

ある意味悲しいのかもしれないですが、僕は今も昔も IPv6 を利用するときに IPv6 Over IPv4 トンネルを利用する機会が多いです。
そもそも FreeBSD をずっと利用しているので dtcp を利用すると簡単に接続できます。 FreeBSD の ports 的に言うと net/dtcp になりますが、サーバ側とクライアント側の両方がインストールされます。通常、サーバ側に net/dtcp をインストールして dtcpd を利用し、クライアント側には net/dtcpclient をインストールしたりしますが、まぁ、とりあえずは net/dtcp をクライアント側にもインストールすることで、グローバルアドレスがあれば簡単に IPv6 Over IPv4 なトンネルが掘れるのであります。

が、そろそろ FreeBSD でのルータ機能は引退させたいものだ。などと思っていて、 NTT-X で超格安の Cisco841J を買いそびれた今、 VyOS で実装するしかなんかべ。と、なり IPv6 Over IPv4 トンネル で利用する dtcp を引退することにしたのでありました。

今回は VyOS と FreeBSD との間で IPv6 Over IPv4 トンネルを掘る設定を書いてみたいと思います。何を今更。感が満載ではありますがf(^^;;。

 
まずは構成図を。

真ん中の黄色いのが IPv6 ゲートウェイなルータでで FreeBSD/amd64 10.3-RELEASE から VyOS-1.1.7 にネットワーク機能を変更しました。
周りのピンクのセグメントは dtcpclient が動いていたのですが、これを VyOS に接続するために設定変更しなおします。

 
1. ゲートウェイスイッチ側の設定
FreeBSD から VyOS にリプレイスしたので設定は VyOS の設定になります。だいたいこんな感じ。

    tunnel tun10 {
        address 2001:470:fe36:1111::1/64
        description "# IPv6 Tunnel No1 #"
        encapsulation sit
        local-ip 192.168.1.210
        multicast disable
        policy {
            route mss
        }
        remote-ip 172.16.1.211
    }

 
VyOS は基本的に Linux なので sit なんてのが見えますが、こんな感じの設定ですね。

・local-ip で自分の IPv4 アドレスを設定
・remote-ip には接続先 IPv4 アドレスを設定
・policy route mss は IPv6 Path MTU Discovery にはまらないためのおまじない

以下の設定で MSS の値を調整しています。

policy {
    route mss {
        rule 5 {
            protocol tcp
            set {
                tcp-mss 1386
            }
            tcp {
                flags SYN
            }
        }
        rule 10 {
            protocol tcp
            set {
                tcp-mss 1386
            }
            tcp {
                flags SYN,RST
            }
        }
    }
}

 
簡単ですねぇ;-)。
ただ、 IPv6 Path MTU Discovery にハマると http とか接続できない問題が発生するのでその対応が必要になります。 tcp-mss 1386 の数値の部分は自分の環境によって変わるので過去に書いた記事を参考にしてみてください。

 
1. dtcpclient 側の設定
ルータ側の設定が終わったので、次にクライアント側の FreeBSD の設定になります。

とりあえず、以下のコマンドを打てばトンネルは掘ってくれます。

ifconfig gif0 create
ifconfig gif0 tunnel 172.16.1.211 192.168.1.210
ifconfig gif0 inet6 2001:470:fe36:2222::1 2001:470:fe36:1111::1 prefixlen 128
route -n add -inet6 default 2001:470:fe36:1111::1
ifconfig gif0 up

 
起動時に IPv6 トンネルを自動的に掘りたい場合はどうしますかねぇ・・。 /etc/rc.conf に色々設定するのが大変なので、僕の場合は /etc/rc.local というファイルを作って、そこに記述して起動時にどうにかしてもらっていますf(^^;;。

3. 確認方法
両方で設定が完了するとあとは確認になります。FreeBSD 側から以下のコマンドが有効ですね。

$ ping6 ff02::1%gif0
PING6(56=40+8+8 bytes) fe80::a1f:29ff:fefe:9696%gif0 --> ff02::1%gif0
16 bytes from fe80::a1f:29ff:fefe:9696%gif0, icmp_seq=0 hlim=64 time=0.089 ms
16 bytes from fe80::ccaa:f1d2%gif0, icmp_seq=0 hlim=64 time=8.663 ms(DUP!)
16 bytes from fe80::a1f:29ff:fefe:9696%gif0, icmp_seq=1 hlim=64 time=0.047 ms
16 bytes from fe80::ccaa:f1d2%gif0, icmp_seq=1 hlim=64 time=7.081 ms(DUP!)
^C

 
二つのリンクローカルアドレスから ping6 の応答があれば無事に接続しました。これで IPv6 Over IPv4 トンネルが掘れました。
グローバル IPv6 に ping6 を打って返ってこない場合はルーティングに問題があるので、ゲートウェイ側の設定を見直すなどしましょう。

 
と、いうことでゲートウェイ側を FreeBSD から VyOS に移行し、更に dtcp の利用をやめて接続しても、いとも簡単にトンネルが掘れました。良かったですぅ;-)。

2月 022017
 

IT 系のニュースサイトを会社でお昼休みに見ていたら Amazonセール速報:本日限りの特価! と、いうのを発見。かねてより会社で使うためのマウスを探していたので、すかさず購入しました。

購入後、次の日には届いたので早速使ってみることに。が・・。あたたたたた。使えることは使えるんだけど、ホイールが軽すぎて真ん中ボタンを押したら上下にホイールしてしまう状態である意味全然全く使えない。

例えばブラウザでとあるサイトのアンカータグを真ん中ボタンでクリックすると新規タブで開いてくれるんだけど、真ん中ボタンを押した表示されているコンテンツが上下にズズズと動いてしまう状態。全然使えないじゃん・・。

と、いうことで届いたその日のうちに分解。何とかカスタマイズできないかなぁ?などと思うわけです。分解の手順は至って簡単。

1. 電池を抜きます。
2. すると電池の溝の影のところにネジが一本あるのでそれを抜きます。
3. 裏ブタを下にずらしつつ上のほうのロックが外れる。
4. 上ブタのボタンのコネクタを爪などで抜きます。

以上で分解完了。

ホイールの部分を眺めてみるとどこかでテンションというか抵抗を付けてあげるとホイールの回転が渋くなるのになぁ。と思います。それに相当するのが、あったー。

写真でいう針金のようなものがホイールを回り込んているようです。

これを曲げてホイールに対して抵抗を作ってあげるとクルクル回る現象はある程度回避できそうです。
針金は本体プラスチックの爪で固定さているので横 (右ボタン側) にずらして外します。このときスプリングがびよーーんっ!! とどこかに飛んでいってしまうので注意が必要です。

抜き出した針金はこんな感じ。

これを、ちょうど良い硬さのホイールになるように曲げてあげます。僕はラジオペンチで曲げつつ調整しました。ビタっとしたちょうど良いホイールの硬さにするために三回くらいトライしました。もし、このエントリを読んだ人が同じことをする場合は、自分の感覚を信じて色々曲げてみてください;-)。

と、いうことでホイールは無事にちょうど良い硬さになり、ホイールの真ん中ボタンを押してもコンテンツが上下にブレる。と、いうことから開放されたのでありました;-)。

 
と、いうことで、これだけで終わってしまったらただ単にフツーの、そこいら中にある分解・改造の記事になってしまうので一歩踏み込みます;-P。

まず、僕の PC の環境についてですが、キーボードとマウスは二台の PC で共有しています。 USB 切替器で FreeBSD と Widnows10 を行ったり来たりしている状態です。

で、この Logicool の M5454 というマウスはホイールが前後に回転する他に左右に倒すことによってイベントが発生するようです。しかも右側には更にボタンが二つあります。

パッっと思いつくのは『このボタン達は FreeBSD で使えないのかな?』と、いう点。 Windows10 の場合は専用ドライバをインストールすると、ホイールの左右方向と左側の二個のボタンには色々な動作を割り当てられます。

これを FreeBSD+Xorg で似たようなことできるのかな?とか思い、ちょっと調べてみました。

まずは Xorg のマウスの設定。

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/dev/sysmouse"
        Option      "ZAxisMapping" "4 5 6 7"
        Option      "ButtonMapping" "1 9 3 2 2"
EndSection

 
最後に ButtonMapping と、いうオプションを付けてみました。

オプションの数値はボタンの番号を表しています。ボタンの番号は xeve で取得できます。数値が “1 9 3 2 2” となっていますが、これは “左 左横前 右 ホイール ホイール” の各ボタンを指しています。
動作的には “左ボタン 真ん中ボタン 右ボタン ホイールの前 ホイールの後” ということになります。 FreeBSD のマウスによるペースト動作を左横前ボタンで代用する。と、いう設定ですね。

さてと。X を再起動して /var/log/Xorg.0.log を眺めてみましたが X からは ButtonMapping の設定がまるで無視されていました・・。orz

 
次に FreeBSD の ports で何かないんかい?と思い調べたのですが x11-drivers/xf86-input-evdev という、 X のドライバでマウスの様々なボタンに対応できるらしい。とのことで調査開始。

Linux では動作するらしいですね。 /dev/input/* なデバイスを利用するとマウスで色々なボタンが利用できるようになったり、Logicool M565 などは専用カーネルモジュールがあるようで。

FreeBSD ではまだ evdev.ko なるカーネルモジュールがないので実質的に xf86-input-evdev は利用できないようです。 CURRENT で現在検証中らしいのですが、それ以上は追うのはやめました。

 
と、いうことで FreeBSD においてはフツーの無線の USB マウスとして利用しようとおもった矢先、ブラウザでとあるサイト見ているときにホイールを左右に振ってみると。あれれ?

ホイールを左に振ると戻るボタン
ホイールを右に振ると進むポタン

と、して動作するようですねぇ。あれれ? X で制御しているのかな? KDE 側で対応しているのかな?あれあれ? ソースコード追ってません。すみません。ただの動作確認のみですf(^^;;。
一応 firefox rekonq では上記のように動作しました。 konqueror では動作しませんでした。

xmodmap で進む・戻るボタンが設定できるようですね。詳細は書きませんが。 evdev が動かなくても xinput などでも色々設定が可能らしいです。ここでは詳細は書きませんが。

まぁ、珍しい機能が動くモノだ。と、いうことで Windows10 側でもドライバユーティリティで設定を FreeBSD に合わせた。と、いうことで、二つの OS で動作が一緒になったのでありました;-)。

 
今回はマウスを一個購入して、エントリを書いていますが、タネは二つ。

・ホイールクルクルがイヤな人は分解して針金曲げてみましょう
・FreeBSD ではホイール左右で戻る・進むが動作する

と、いうことですね。中々楽しめた一品だったのでありました;-)。

あ。お約束ですが、『分解』することになるので、自己責任でお願いしますね。

7月 112016
 

今年の四月くらいに FreeBSD でも Let’s Encrypt が利用できるようになった。と言う話を耳にして、当時は letsencrypt コマンド(当時の ports 的には security/py-letsencrypt) を利用するとサクサクっと Let’s Encrypt な証明書を利用したSSL サーバが利用可能な状態となりました。
それから約三ヶ月が過ぎて Let’s Encrypt 的にもコマンドが letsencrypt-auto から certbot-auto になって、 FreeBSD の ports 的には security/py-certbot もしくは security/letsencrypt.sh という二つの実装が提供されるようになりました。

さて。今年の四月くらいに letsencrypt コマンドで生成した証明書が有効期限切れになるのでアップデートしようと思い、普段からこまめに portmaster -D -a している環境においては既に letsencrypt がなくなっていたので certbot で実行したら以下のようなエラーが出てまるで動作しなくなってしまった・・。 orz

SSLError: ("bad handshake: Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')],)",)

 

なんかねぇ。おかしいんですよ。で、色々聞いたり調べたりしたところ、どうやら security/ca_root_nss のインストールが変なんじゃないか? という結論に達したのであります。

security/ca_root_nss をインストールするときの make config で 以下のように ETCSYMLINK のオプションを [X] にしてあげないとダメなようです。

ca_root_cert

上記オプションを有効にして make install すると /etc/ssl/cert.pem が sysmlink で生成されるようになります。 ETCSYMLINK のオプションは以前は [ ] な時期(それはつまりはオフになっている状態。と、いうことです)もあったりしたので古い make config の情報を使いまわしている人は ずっとオフのまんまで来ていたりするので『自分の make config の結果はどっちだったかな?』などと、確認するのも良いかもしれないです。

letsencrypt コマンドのときは /etc/ssl/cert.pem が無くとも大丈夫だったのに certbot コマンドを利用するようになったら /etc/ssl/cert.pem が必要になりました。ふむー。

/etc/ssl/cert.pem と同じファイルは全部で以下が存在します。

/usr/local/share/certs/ca-root-nss.crt
/usr/local/openssl/cert.pem
/usr/local/etc/ssl/cert.pem
/etc/ssl/cert.pem

うーむ。 ports からインストールしたものは素直に /usr/local/etc/ssl/cert.pem を参照してくれれば良いのになぁ。などと思うのですが、この辺り、見事に『はまり道』です。

ports から security/py-certbot をインストールして上記のようなエラーメッセージが出てまともに動作しない場合には是非 /etc/ssl/cert.pem があるかを確認してみてください。

 
あと、 /etc/ssl/cert.pem はあるけど、それでも上記のエラーメッセージが出て certbot コマンドが動作しないことがあるかもしれませんが、それは多分、過去に letsencrypt コマンドで既に証明書を発行してもらい、その後の証明書ファイルの更新時にcertbot コマンドを利用しようとすると発生するのではないかと思われます。
その場合は悲しいけれども、一旦 /usr/local/etc/letsencrypt/ ディレクトリを削除もしくは名前変更してから再度、新規に /usr/local/etc/letsencrypt/ ディレクトリを作成すると無事に動作します。古いコマンドを実行したときに参照した cert.pem ファイルの情報を保持しているのでしょうなぁ。

以上、FreeBSD において certbot を使ったときの『はまり道』についてなのでありました。

あ。 certbot の使い方とか書いてないですが、大丈夫ですよね?;-)。

2月 202016
 

いやぁ。一月は全くエントリがなかったのに二月はドドドと連チャンになってしまいました;-)。

と、いうことで本題。

FreeBSD で Thunderbird を利用していると、一緒にカレンダーアプリである Lightning を make config の時に指定することができます。あ。ports で make するときのお話です。
しかし、ports から Thunderbird と一緒にインストールした Lightning は日本語化されてないんですね。 Windows 版などはインストール後に Lightning も日本語表示できるのに・・。

と、いうことで以前「Lightning の自動日本語化。」と、いうエントリを書いてしばらくは対応できていたのですが thunderbird-38 系になって、このスクリプトを動かしても日本語化してくれなくなりました。モロモロ状況が変わったのでしょうなぁ。

と、いうことで久しぶりに Thunderbird と Lightning を調査した結果、以下のことが解りました。

  • FreeBSD の ports からインストールした Thunderbird は Lightning が以下のディレクトリにインストールされる。

    /usr/local/lib/xpi/lightning@thunderbird.mozilla.org/

  • この中の chrome.manifest をいじって chrome/ ディレクトリの中に locale ファイルをほーりこんでも日本語化されない。
  • FreeBSD の ports からインストールした Thunderbird は Lightning が上記ディレクトリにインストールされる他に、以下のディレクトリにも合わせてインストールされる。

    $HOME/.thunderbird/乱数.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/

以上の調査結果から、日本語 locale ファイルをインストールするのは ~/.thunderbird/ の中の Lightning エクステンションの中にインストールして上げなければならない。と、いうことが解りました。

いやぁ。ハマりますなぁ。これは・・。まさか二箇所にインストールされている(もしくは、バージョンアップした Thunderbird の最初の起動時に $HOME 配下にコピーする)とは思っていなかった。

 
と、いうことでサクっと日本語するスクリプトを更新したので、必要な方は以下の URI からダウンロードして試してみてください。

http://icmpv6.org/Prog/lightning-ja-20160219.tgz

簡単なスクリプトなので、詳しい説明はしません。中を覗いてください;-)。

スクリプトの lightningversion=’4.0.3.1′ は狙い撃ちしています。 install.rdf のバージョンを確認すると 4.0.6 になっているのですが、そのディレクトリが ftp.mozilla.org のサイトに見当たらないんですよね。
なので、新しいバージョンが出たら lightningversion=’4.0.3.1′ を変更してください。

 
と、いうことでカレンダーの日本語化、復活です;-)。

10月 182015
 

ちょっと前のエントリで「Zeroconf 考察。」というのを書きました。デスクトップで利用する場合には Avahi を、サーバで利用するなら mDNSResponder+howl で。って感じのエントリでした。

さて。サーバ側で利用している mDNSResponder (正確には mdnsd のこと) ですが、こいつは非常にお行儀の悪いプログラムですねぇ。さすがは Apple 謹製って感じでしょうか;-P。

どの辺りがお行儀悪いのか?

mdnsd は起動してからのログが随分と出力されます。例えば、サーバの場合は複数のインターフェースを持っていて、アクセスされたくないインターフェースには ipfw などで止めたりします。しかし、 mdnsd はそんなのお構いなしにサーバの全てのポートにマルチキャスト DNS パケットを port:5353 に流しまくりなんですね。

挙句の果てには『bge1 にパケット投げたら Permission denied だった。』とかログを出しまくりで、ヘタしたら /var/log/messages は mDNSResponder のログで溢れかえっしまいます。

これは非常にウザいので今回はログを一つのファイルに集約するようにして /var/log/messages には出力しないようにしてみましょう。
まずは syslog の設定から。あ。ターゲットは当然 FreeBSD です;-)。

 
o. syslog の設定
今回は mdnsd のログは今回は LOCAL4 に出力するようにします。なので、LOCAL4 に飛んできた syslog の扱いについて設定します。

まずは /etc/syslog.conf の設定変更です。

        :
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err;local4.none       /var/log/messages
        :
#
local4.*        /var/log/mdns.log
#
        :

 
/var/log/messages に出力されたくないので local4.none を追加します。そして LOCAL4 ファシリティ用のログファイルを設定してあげます。

次に /etc/newsyslog.conf も編集しましょうかね。

        :
/var/log/mdns.log                       644  7     100  *     JC
        :

 
まぁ、こんな感じで登録します。あとは syslod と newsyslog を restart すると準備は完了です。

 
o. mDNSResponder のソース改修
mDNSResponder は ports 的には net/mDNSResponder/ になります。ここでまず make patch とか打ってソースを展開したうえでソースコードを覗いてみます。今回は syslog に関わる部分ですね。

と、いうか mDNSResponder (バイナリ自体は ports の net/howl/ でインストールされる) と、いうか mdnsd (こちらが ports の net/mDNSResponder/ がインストールする) は syslog プライオリティなどを変更するオプションが無いんですね。なのでソースコードを眺めんですけども。

それで、ソースコードを眺めいたらありましたね。 syslog の openlog は mDNSShared/PlatformCommon.c でやっているようですね。

以下はパッチです。

--- mDNSShared/PlatformCommon.c.orig    2012-06-30 13:52:35.000000000 +0900
+++ mDNSShared/PlatformCommon.c 2015-10-16 10:57:01.595162000 +0900
@@ -184,7 +184,7 @@
             fflush(stderr);
         }

-        if (!log_inited) { openlog(ident, LOG_CONS, LOG_DAEMON); log_inited++; }
+        if (!log_inited) { openlog(ident, LOG_CONS, LOG_LOCAL4); log_inited++; }

 #if APPLE_OSX_mDNSResponder && LogTimeStamps
         if (ident && ident[0] && mDNSPlatformClockDivisor)

 
openlog() のオプションで LOG_DAEMON と書かれているので syslog.conf では daemon.none を設定すれば良いような気がしないでも無いですが LOG_DAEMON なプライオリティは他のアプリケーションもドカドカと利用しているような気がするので、今回は LOG_LOCAL4 に変更してみます。

上記パッチは net/mDNSResponder/files/ の中に patch-mDNSShared-PlatformCommon.c としてほーり込むと ports の make 時に毎回有効になるかと思われます。自分の好みでどうにかしてください。

また、僕は LOG_LOCAL4 にしましたが、自分の都合のようプライオリティに変更しても良いのではないかと思われます。

あとは make して deinstall して reinstall 、そしてデーモンを再起動すると全ては完了です。 /etc/syslog.conf に指定した情報の通り、 /var/log/messages 以外のファイルに蓄積されるようになるかと思われます。

 
mDNSResponder と mdnsd は非常に良いのですが、出力されるログが非常に気になるのですが、これで問題解決;-)。

ports の Makefile 自体を改修して make config でログのプライオリティを変更するようにもできるなぁ;-)。
機会があれば書いてみよう;-)。

10月 162015
 

FreebSD の ports-CURRENT を追いかけていると、時々はまります。今回は graphics/dri のコンパイルが通らないので、その回避策について書いておきます。

まぁ、こーいうネタは時間が経つと解決するので、エントリを書いてもあまり意味は無いとは思うのですけどね。

今どきですと /usr/ports/ 辺りで svn update を実行すると dri 周りは 10.6.9 になります。 libGL 周りなど mesa-10.6.9 を利用する ports は全部で六個くらいでしょうかね。

FreeBSD/amd64 ではコンパイルの途中で止まってしまいます。 FreeBSD/arm ではとあるライブラリがねーぜ。とか言われて configure 辺りで止まってしまいます。今回は両方のアーキテクチャの回避策について書いてみたいと思います。

 
o. FreeBSD/amd64
mesa-10.6.9 からなる dri 系の ports は llvm36+clan36 が必要になりました。関連性で devel/llvm36 と lang/clang36 がインストールされるのですが、こいつらのインストールがちゃんとできていても失敗しているような感じでコンパイルが途中で止まるようです。

以下のエントリで話し合われていて、既にクローズになっているようですね。

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203192

手順としては

# pkg delete -f llvm36-3.6.2_2
# pkg delete -f clang36-3.6.2
# rm -r /usr/local/llvm36/

 
してから再度インストールして、それから graphics/dri をコンパイルすると無事に通るようです。

どーしてこうなるんだろうなぁ? と、思うのですが、思い当たる点としては llvm35 既にインストールされている状態で llvm36 がインストールされて、『二個もいらねーじゃん。』とか思い llvm36 は残して llvm35 だけ削除したのですが、もしかしたらそれが原因かもしれません。

と、いうことで llvm* の痕跡を全て削除してから再インストールすると mesa-10.6.9 系の ports 一式がインストールされるようになります。

めでたしめでたしですね。

 
o. FreeBSD/arm
こちらのほうは、まず、上記の問題を解決し、llvm36+clang36 をサラな状態でインストールしてあっても、 make が通りません。

以下は graphics/dri を make したときのログですが、

# cd /usr/ports/graphics/dri/
# make
        :
checking for RADEON... no
configure: error: Package requirements (libdrm_radeon >= 2.4.56) were not met:

Package libdrm_radeon was not found in the pkg-config search path.
Perhaps you should add the directory containing `libdrm_radeon.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libdrm_radeon', required by 'world', not found
        :

 
こちらについても以下の URL で既に問題提起されているのでその内に解決されるかと思いますが、どーしても最新版を使ってみたい方はコンパイルを通した packages を作ったのでダウンロードしてみてください。

https://www.mail-archive.com/freebsd-pkg-fallout@freebsd.org/msg247413.html

この件の問題点としては FreeBSD/arm においては lib/libdrm_radeon.so がインストールされない点にあります。
では、そもそも lib/libdrm_radeon.so はどの ports がインストールするのだ? と、うことになるのですが、 graphics/libdrm でインストールされます。 Makefile を見てみると以下の部分になります。

.if ${ARCH} == amd64 || ${ARCH} == i386
PLIST_SUB+=     INTEL_DRIVER=""
PLIST_SUB+=     RADEON_DRIVERS=""
.elif ${ARCH} == ia64 || ${ARCH} == powerpc || ${ARCH} == powerpc64
PLIST_SUB+=     INTEL_DRIVER="@comment "
PLIST_SUB+=     RADEON_DRIVERS=""
.else
PLIST_SUB+=     INTEL_DRIVER="@comment "
PLIST_SUB+=     RADEON_DRIVERS="@comment "
.endif

 
FreeBSD/arm のアーキテクチャは armv6 なので .else のロジックを走り pkg-pllist を見ると INTEL 系と RADEON 系がインストールされないんですね。たけど、 FreeBSD/arm 上で graphics/dri をコンパイルしようとすると libdrm_radeon.pc がねーよ。って言われます。

なので上記の Makefile の部分を変更してあげる必要があります。雰囲気的には ia64 や powerpc などと同じ処理をして上げる必要があります。

.elif ${ARCH} == ia64 || ${ARCH} == powerpc || ${ARCH} == powerpc64 || ${ARCH} == armv6

 
この一行だけ直してあげると libdrm_radeon 絡みのファイルが一式インストールされるようになります。

http://distfiles.icmpv6.org/distfiles/packages/All.armv6/libdrm-2.4.60,1_add_radeon.tbz

に上記の改修を入れて libdrm_radeon* がインストールされる packages を用意しておきました。最新版を利用してみたい方はご利用ください。

 
とわ言いつ、 FreeBSD/arm に radeon は必要ないので ports のメンテナは libdrm の ports を直すのか mesa-10.6.9 系の ports 一式を直すのか、わかりませんね。 mesa 系 ports を直すのは大変そうなので、多分 libdrm 系を直して libdrm_radeon 周りをドドドとインストールするようにするかもしれませんが。

実際に OpenCL とか利用できない Raspberry Pi 2 の FreeBSD/arm なのに、なんか冗長ぎみなインストールのような気がしないでもありませんが・・。

 
以上、今回は FreeBSD の ports-CURRENT で dri 周りの ports のコンパイルが通らない人用のてっぷすでした;-)。

9月 302015
 

僕は VMWare ESXi 5.1 上で何個かの FreeBSD/amd64 を動かしているのですが、 9.2-R -> 10.0-R -> 10.1-R と来て、今回いよいよ 10.2-R にしてみました。

しかし、 10.2-RELEASE にした途端 powerd が動かなくなりました。あれ? 9.2-R から 10.1-R まで利用しているときには powerd が動いていて sysctl の dev.cpu.0.freq や dev.cpu.0.freq_levels が見えていたのですが、 10.2-R にした途端に見えなくなりました。おかげで powerd を起動すると以下のような感じ。

# service powerd start
Starting powerd.
powerd: no cpufreq(4) support -- aborting: No such file or directory
/etc/rc.d/powerd: WARNING: failed to start powerd

 
cpufreq.ko はロードしているのに有効になっていないようですね。あたたた。

そもそもハイパーバイザの上で動作する OS では cpufreq は見えないんじゃね? という話があります。例えばさくらの VPS では、その上で動く FreeBSD は powerd は動かないし Virtualbox 上の FreeBSD でも powerd が動かない。 dev.cpu.0.freq_levels が無いからですね。

しかし、 VMWare ESXi ではその上で動作する FreeBSD で cpufreq.ko が有効になって dev.cpu.0.freq_levels が生えてきて powerd が動作します。

powerd が動かないと CPU が最速でブン回って地球に優しくないよねぇ。などと思うので何とかしたいのであります。

 
で、色々調べたり、人に聞いた話だと FreeBSD 10.2-RELEASE ではとあるパラメータが追加になって、物理マシンではない場合には default で disable になったようです。なのでそのパラメータを変更して上げると以前のようになるらしいです。

/boot/loader.conf に以下の行を追加して上げると 10.2-R は 10.1-R の頃のように cpufreq.ko が有効になり dev.cpu.0.freq_levels が生えてきて powerd が動くようになります。

hint.acpi_throttle.0.disabled="0"
hint.p4tcc.0.disabled="0"

 
/boot/device.hints の最後に上記の行が追加になってますね。それも “1” で。これを “0” にすると cpufreq.ko が利用可能な状態になってくれます。

この設定が有効なのは今のところ VMWare ESXi のみのようです。実機では必要ありません。実機では default の設定でも cpufreq.ko が有効になります。
また、上記設定を書いても KVM や Virtualbox では dev.cpu.0.freq_levels が無いままだと思われます。

 
参考になる URL としては https://svnweb.freebsd.org/base?view=revision&revision=276986 を見るのが良いかと思われます。

それにしても VMWare ESXi (僕は 5.1 を利用) で FreeBSD を動かしていたけど 10.2-R にしてから powerd が動かなくなったとお嘆きの方は上記の行を /boot/loader.conf に書いてみることをおすすめします。

 
2015/10/04 加筆
上記の設定は VMWare ESXi のときのみの設定ではなく、物理マシンにおいても有効のようです。 10.2.-RELEASE では default で 1 なので、とりあえず powerd をどうにかしたいとか、 dev.cpu.0.freq_levels で表示される数を増やしたいなどあったら上記の設定を入れて試してみるのも一つの手でアルと思われます。

8月 302015
 

と、いうことで、ちょっと前に掲載した「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 です。

おぉーーっ!!

IMG_2407_RPi2_FreeBSD_X_1

ディスプレーのすぐしたにあるのが 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(^^;;。

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

8月 172015
 

前回のエントリは「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 をサクっと開けてしまうすぐれものです;-)。