15-May-2022
[OpenBSDでmrefd(M17リフレクタ)を立ち上げる]

無線機無いしあったとしてもどう変更申請書くんだよ(仕様書の和訳が要るのでは?)という状態ではあるのですが、ソフトウェアを試すことに対しては免許が要らないのでまずは手を動かしてみます。

mrefdは基本的にxlxdのコードに由来しているようなので、考え方はxlxdのインストールと似てはいるのですが、

  1. bash rconfigでconfigure.h, configure.mkを作成
  2. CXX=c++ gmakeのように使用するコンパイラを指定してからmake
  3. dashboard(ref-dash)を別途インストール

という流れになるでしょうか。

あまり細かいことを書かなくても分かると思いますが、rconfigは必須となる項目(M17-で始まるリフレクタのコールサインと、IPv4 Listen Addressを設定しておけば十分です)を埋めておかないとWrite configuration files and quitできません。

これを書いている時点(mrefd-0.3.6)のMakefileでは、make installで以下のファイルを配置します。

OpenBSD標準のディレクトリ構成と違いますがその辺りは無視するとして(下手に変えると面倒です)、systemd用の設定ファイルを勝手に突っ込んでsystemctlを呼ぶというのは流石に面倒なのでこれは潰してからgmake installする方が良さそうです。なお、Makefileに関するPRで、mrefdの作者はDebian系以外は対応しないとコメントしていますので、systemd非採用のLinux distro(Slackware/void/Obarun)で構築する場合も注意してください。

また、/usr/local/etcに配置されるblacklist, whitelist, interlink関連のファイルはシンボリックリンクなのでこれも注意が必要です(これも意図的にこうしていると作者は言っています)。

ref-dashの設定は、xlxdのdashboard2と大体同じです。include/config.inc.php.distをconfig.inc.phpにコピーし、

辺りを設定すれば足ります。自分の場合、xlxdの時と同様に$PageOptions['ContactEmail']にURLを記述してこれに対応できるようindex.phpに手を入れ、$PageOptions['PageRefreshDelay']を10000から60000に増やしています。

あとは/etc/rc.localに


if [ -x /usr/local/bin/mrefd ]; then
	echo -n ' mrefd'
	/usr/local/bin/mrefd &
	top | grep mrefd | awk '{print $1}' > /var/run/mrefd.pid
fi

を追加すればとりあえず動く感じです。xlxapiのようなものがM17には今のところないようなので、$CallingHome['HashFile']に関する問題も気にしなくて良さそうです(という訳で、どうやって稼働中のM17リフレクタをM17 Reflectorsに伝えるのでしょうかね…?)。

MMDVMHostは比較的Linux以外の対応に寛容なようですが、xlxd/mrefdについては塩気が強いです。今後の状況次第ではOpenBSD上での動作を諦める可能性も考えておく必要があるのかもしれません。56.8kg(19:30)

08-May-2022
[流石に参りましたね…]

24-Apr-2022に書いた、i5-4690+H81MHV3がメモリを選ぶのか手元のDDR3メモリでは何を使ってもmemtest86+で必ずエラーが出てしまうという事態のその後。なんとなく、メモリの問題というよりも長時間動作させた場合の安定性に難があるような感じ。

tp55064526.jpg tp55074527.jpg tp55074528.jpg

マザーボードの動作確認を販売店にお願いし、マザーボードの動作には問題がないとの回答を得たのでメモリを買い替えようかな…と相談したところ「むしろ他を疑った方が良いのでは?」とのアドバイスがありました。中古で買ったCPU、これは流石に動作の確認は取れているだろうと思っていたのですが念のためCPUの動作確認もCPUの販売店にお願いすることにしました。※マザーボードとCPUを買ったお店は異なっています

こちらは保証期間の7日間が過ぎてしまっていたものの、とりあえずの動作確認はしてもらえました。とはいえ、memtest86+での長時間動作ではなくPassMark Memtest86(Free)の4-passで問題無しとの回答でした。こちらと同じ手法での再テストをお願いしたところ時間が無いという理由でテストを拒否されてしまったので(送料の都合もあり)同じ販売店でCore i3-4130を購入し、以下のメモリでテストしてみました。

tp55084529.jpg tp55084530.jpg

…どちらも12時間以上放っておいても全く問題が無かったので、i5-4690の問題と考えるしかなさそうです。マジか。

この件、お店のチェックが甘いと言うことは非常に簡単なのですが(そりゃあお金を返してもらえるなら返してほしいです)、それに対してチェック体制をどう強化すると良いかという提案をしづらいところでもあります。お店の立場で考えるに、全ての買い取ったCPUに長時間動作のテストを行うというのも難しい話でしょう。

既に動作の確認が取れているシステムでCPUのみ交換するようなケースであれば、おそらく保証期間内に問題を見つけて対処することはできたと思われます。しかし、新調したマザーボードに部品箱に眠っていたメモリと適当な中古のCPUで、という組み合わせで起きた今回のトラブルは…どうやれば7日という制限時間内にCPUが原因であると突き止められるのか、自分には全く方法が分かりません。※電源を交換しても問題が解決しなかったため、電源の問題ではないと考えています

オーバークロックに伴う殻割や電圧上昇等により痛め付けられている個体が出ている可能性が高そうだという理由でi5-4690Kを敢えて避け、i5-4690を選んでいたのですが、それでもこのような事態に遭遇するのは複雑な気分です。その一方で、長時間の連続動作を行わないと問題が分からないような呪われし品をどうやって作り出したのかについては興味があり、元のi5-4690の持ち主に詳しくお伺いしたいところです。56.8kg(18:55)