R86S U1のファンはいかにも貧弱でいつ壊れても不思議がなかったので、壊れる前にもうちょいマシにしようと試行錯誤したログ。
やろうとしたこと
既存のケースを外し、ラズパイ用の大型クーラーをつけて適当なケースを作って冷やせるようにしようとした。
R86S U1の分解像
外観
裏ブタを開けたところ
本体を開けたところ
手前からCPUボード、NIC、NICの裏板の三層構造になっている。
各ボードを繋ぐケーブルが邪魔なので、作業するときは外すとやりやすい。
FPC(フレキシブル基板、フレキシブルケーブル)は以下の手順で外せる。左右についている爪を触ると折れるので触らない方がいい。但し折れても支障はない。
CPUボードを開けたところ
グリスが酷い。閉じ直すときは、ここまで塗る必要はなく、注射器から1mmほど出しておけばよい。
CPUヒートシンク?
蓋側にはケースに熱を伝えるための銅の板がついており、やはりグリスがたっぷりついている。
CPUファン
銅板やヒートシンクを冷やしているというよりはケース表面のヒートシンク形状を浸すための装置に見える。40 x 40 x 7mmの2pin形式なら互換性があるものと思われる。
ピンの形状は検証していないが、調べた限りJST SH1.0MMらしい。ハウジングはこの手の製品が使えると思われる。
耐久性が心配になるサイズだが、この方式であれば上に60mmファンを雑に置いておいても成立しそうな気はした。
CPUボード単体
CPUにはヒートスプレッダが二つ付いており、ノートPCによくあるタイプに見えた。
NIC側を開けたところ
NIC本体と裏板は特殊なコネクタで繋がっており、上に引っ張ると抜ける。調べた感じOCP2.0という規格らしい。
OCPはOpen Compute Projectの略で、ラックサーバー用の規格のようだ。一般的にOCP2.0メザニンカードと呼ばれているらしい?
このコネクタを備えた変換PCIeカードも流通しており、普通のPCに繋ぐこともできるようだ。
R86S U1の寸法記録
CPUボード
Autodesk Fusionで描いたもののスクショ。誤差+-0.50mm程度と思われる。
CPU本体
Autodesk Fusionで描いたもののスクショ。誤差+-1.00mm程度と思われる。
Rが付いて盛り上がった形をしているヒートスプレッダのサイズが上手く取れなかったので、大まかな図。特に上下のスプレッダの間隔は怪しい。
NIC
手描きのスケッチ。ネジ穴の直径を書いているが、実際はすべて3.00mmと思われる。
「チ」とあるのはNICのチップ。「チ」2.44mmはチップの高さ。
NICの裏板
NICがのっかってる板。NVMeSSDを挿すやつが載ってるやつ。ケース固定用のネジ穴とヒートシンク固定用のネジ穴で直径が異なる。
左にある凸型の図はNICを支えるスペーサーと、それが載った基板の寸法。
下にある「内側のネジがヒートシンク用」「ファンのネジ」とあるのはネジの寸法。
ラズパイクーラーの足回りの寸法
GeeekPi ICE Tower Plus クーラー Raspberry Pi 5、Raspberry Pi 5 4GB/8GB 用冷却ファン付き Pi 5 アルミニウム アクティブクーラーの寸法。
鍵束をいい感じに運用するでは、カラビナ付きのキーホルダーを使い、自転車の鍵を着脱可能にして管理しやすくしたり、旅先で得たコインロッカーの鍵を管理したりしたことを書いたが、今回はその続きとして、カバンの運用整備について書いていく。
すべてのカバンに鍵束管理システムを装着できるようにした
普段のバッグ、PCバッグ、登山ザック、トートバッグに至るまで全てのカバンに例の鍵束システムを実装した。
悩んだのはトートバッグだった。これまでトートバッグには鍵を裸で放り込んでおり、特に自転車のかごに入れて運んでいるときに紛失リスクが高かった。しかしこれは次のグッズによって解決した。
それは第一鋼材のマーキー・ストラップだ。このグッズはプラスチック製のバックル付きのベルトで出来ていて、トートバックに後からつけることが可能な便利な品だ。
しかも鍵をつけることが想定されているので一般的なベルトと比べると短くうえに、小さく使いやすい。鍵以外にもキーホルダーをぶら下げてもよさそうだし、これに缶バッジやピンバッジをつければカバン本端を傷めずにデコレーションできる可能性もあり、色々便利そうな一品である。
神戸ではコーナンで買うことができた。元々キーホルダーのリングを探している時に偶然見つけて、それ以来これを使い続けている。
カバン装備の共通化
複数カバンを持っていると、別のカバンを使ったときにあれがない、これがないというのが起きがちなので、必需品は共通化することにした。
但しトートバッグは、その形状や特性から対象外にしている。そもそもトートバッグをメインバッグにして長時間行動することがないためだ。鍵さえ紛失できずにぶら下げられていればいい。
内容としては普段のバッグ、PCバッグ、登山ザックの全てに靴ベラ、眼鏡ケース、ティッシュ、絆創膏、頭痛薬を入れている。
靴ベラは靴を長持ちさせるための必需品だ。ないとすぐに傷んでしまう。
眼鏡ケースはバスや電車で寝るときに重宝する。眼鏡をかけたままもたれ掛かって寝ているとフレームが歪んだり傷がついてしまう。私の使っている眼鏡は特殊なフレームで、替えが見つからないためその保護のために持ち歩いている。他にも眼鏡をはずす様々なシーンで活躍する。
かつて眼鏡ケースを持ってこなかったばかりに寝られなかったり、変なところにおいてた製で落としてしまったなどがあったため、眼鏡ケースも重要なアイテムだ。
ティッシュについては私が年中鼻炎なので必須である。
絆創膏もあると便利だ。若い時はまだいいが、年をとってくると怪我の直りが悪いのであるとよい。
そして最後の頭痛薬だが、個人的に頭痛持ちということもあるが、頭痛薬は鎮痛剤でもあるため、登山で下山するときに足を痛めてしまったときにも重宝する。足が痛いので山岳救助を呼ぶなんてやっていたら破産してしまう。
登山以外にも旅行先で割と歩くので、足が痛くなった時によく使っている。
mont-bellの登山靴の一つにトレールウォーカーという靴があり、幅広版にはワイドという名前がついている。
これが最近リニューアルされたようで、だいぶ靴の形が変わってしまって履けなくなった話。
以下はリニューアル後のトレールウォーカーワイド(品番:1129773)と、リニューアル前のトレールウォーカーワイド(品番:1129652)の比較だ。青い方がリニューアル後、灰色がリニューアル前。
リニューアル後はつま先が曲がっており、つま先の高さも低くなっており、真ん中の紐が横断している隙間も1cmほど狭くなっているように思う。これによって私の幅広甲高な足だと指が圧迫され、指の第一関節が押し付けられ、かなり苦しかった。
試着の時はそこまで気にならなかったが、実際に路上を歩くと五分で違和感を覚え、数時間歩くと痛みで歩行が困難になるほどだった。
余談だがワイドでない方にも同様の変更がありそうだった。
リニューアル前のトレールウォーカーワイドは通常店舗では手に入れることが出来ないが、公式通販やアウトレットショップには型落ち品として在庫があるため、手持ち品を更新する場合はこちらを買うと良い。また、公式の店舗在庫はかなりリアルタイムに更新されているようで、購入して30分後に確認した時には既にサイト上で店舗在庫が消えていたので、店舗で購入する場合は有力な指標になると思う。恐らく目の前の客が今買った以外以外のケースでは概ねアテになるのではなかろうか。
Google Analyticsを廃止してMatomoを導入してから集めていたIPv6のアクセス比率を集計した結果をメモしておく。
集計期間は2025/08/17~2025/10/21。
| サイト | IPv6ビジット | IPv4ビジット |
|---|---|---|
| lycolia.info | 56 (55.0%) | 77 (45.0%) |
| ブログ (blog.lycolia.info) | 2,018 (43.4%) | 2,644 (56.7%) |
| ECO-Wiki (eco.lycolia.info/wiki) | 7,946 (40.5%) | 11,291 (59.4%) |
| ツールサイト (tool.lycolia.info) | 13 (65.0%) | 7 (35.0%) |
| 合計 | 10,033 (41.7%) | 14,019 (58.2%) |
以上の結果からIPv6は約四割、v4は約六割ということが分かった。また最もアクセスがあるのはECO-Wikiで、ツールサイトにはほぼアクセスがないことも明確になった。まぁツールは私が使えればいいので仕方ないね。
lycolia.infoは突出してIPv6のアクセスが多いが、実数が少なすぎるので余りアテにならない。ただ恐らく、リンク元の特性的に、ITオタク周りのアクセスが多いことが想定されるため、この結果はある程度妥当かもしれない。ツールサイトもそういう人が興味を持って踏んでるのだとしたら納得だ。ブログも技術記事がある関係で比率が高い可能性がある。
逆にECO-Wikiは比較的一般向けのサイトなので比率が少なくなっていると思った。
あとがき
まだまだIPv4の環境は多く、IPv6シングルスタックへの移行はやや戸惑うレベルだ。GitHubのWebhookもIPv4だったりするので、しばらくはデュアルスタックで運用していくのが無難だろう。
現状さくらのレンタルサーバー上にある資源を自宅サーバーにフル移行する場合、DNS側の制約でマルチドメインのDDNSが面倒な問題があるため、専用のスクリプトを作る必要が出てきそうだ。
これは契約しているDNSサーバーのDDNSが1回に1レコードしか更新できず、レートリミットが60秒に1回という面倒な仕様なため、ドメインが複数あると厄介なのだ。現状Mastodonだけが自宅サーバーにある状態なのでどうにかなっているが、どうにかして対処しないといけない。
契約しているDNSサーバーにはDDNS API以外にも、DNSレコードを全部書き換えられるAPIがあり、こちらは1回に複数レコードを触れるため、比較的レートリミットを気にする必要がなくなる。なので、これを使って自力で書き換えるスクリプトを組めばDDNS APIのレートリミットは無視できるようになる。まぁ、こっちのAPIはレートリミットが緩いので何度でも叩けるのだが、バルク編集できるAPIを何度も叩く意味もないので…。
これとは関係なく、将来的には自宅サーバー側に権威DNSを立てて、レジストラのDNSサーバー側にはNSレコードだけというのもやってみたさがある。この場合、ドメインの追加や削除で一々レジストラの管理画面にアクセスする頻度が減らせ、管理が楽になるメリットがありそうだし、レジストラのDNSでは実現できないことが出来るようになる可能性もあるだろうから面白いかもしれない。
luci-app-statisticsとcollectdを入れて下図のように各メトリクスのグラフを見れるようにした。collectdは、システム情報を定期的に収集し、さまざまな方法で値を格納するメカニズムを提供する小さなデーモンで、luci-app-statisticsはそれをLuCI上に表示するためのものっぽい。
確認環境
| Env | Ver |
|---|---|
| OpenWrt | 24.10.0 |
セットアップ
- LuCIを開く
- System→Software
- luci-app-statisticsを入れる
- 画面リロード
- Statics→Graphからグラフが見れることを確認
この時点で幾つかのプラグインが導入されたが、消したり入れたりして、結果として以下のものを導入した。
Collectdのプラグイン設定
/etc/collectd.confをいじると変更できる。
基本的にはLoadPlugin hogeでhogeプラグインを読み込み、以下の書式で設定するようだ。設定がなければLoadPlugin hogeだけでよい。
<Plugin hoge>
Foo true
Bar 1
Baz "fuga"
</Plugin>
Collectdのプラグイン
collectd-mod-cpu:CPU使用率
| 設定 | 内容 | デフォルト |
|---|---|---|
| ValuesPercentage | trueであれば、パーセンテージで取れる |
true |
| ReportByCpu | trueであれば、コアごとに取れる |
true |
| ReportByState | trueであれば、システム、ユーザー、アイドルなど、状態ごとに取れる |
true |
設定はデフォルトのままで良さそう。
collectd-mod-interface:ネットワーク転送量
Network→Interfaces→Deviceにあるものが見れる。
br-lanとMAP-E、PPPoEが見たいので以下のようにした。
LoadPlugin interface
<Plugin interface>
Interface "br-lan"
Interface "map-wanmap"
Interface "pppoe-wanppp"
</Plugin>
collectd-mod-load:負荷(Load Average)
uptimeコマンドで出てくる内容と思われる。1を超えていれば過負荷、割っていれば余裕がある。
Wikipediaによると、1ならその時間平均で全てのプロセスが実行され、1.73なら73%のプロセスが実行待ちになったと言う事のようだ。これを1分、5分、15分の平均で出しているとのこと。
設定項目がない。
collectd-mod-memory
メモリの使用量を取れる。
| 設定 | 内容 | デフォルト |
|---|---|---|
| ValuesAbsolute | 物理メモリ使用量の絶対数で報告するかどうか(つまりどういうこと?) | true |
| ValuesPercentage | メモリ使用量をパーセンテージで報告するかどうか | false |
設定はデフォルトのままで良さそう。
collectd-mod-thermal
デバイスの温度を取れる。
| 設定 | 内容 | デフォルト |
|---|---|---|
| ForceUseProcfs | Linuxインターフェースではなく、procfsから熱源を取得する | false |
| Device | 温度を取得するデバイス名 | |
| IgnoreSelected | trueにするとDeviceで指定したデバイスを集計外にする |
false |
R86S U1の場合、thermal_zone1以外無価値に見えたので、thermal_zone1のみとした。thermal_zone0はマザーボードの温度のようだが、固定値しか出てこない。
LoadPlugin thermal
<Plugin thermal>
Device "thermal_zone1"
</Plugin>
これだけだと余計なグラフが出てくるため、設定後に余計なグラフデータを削除する。
collectd-mod-uptime
公式にマニュアルはなさそうだが、起動時間を見れる。
LoadPlugin uptime
collectd-mod-rrdtool
collectdが取得したメトリクスを保存したり、メトリクスのグラフを書くのに使われている模様。特に設定せずとも勝手に設定されるため設定を気にする必要性はなさそう。
ログは標準では/tmp/rrd/OpenWrt/に保存されているようなのでストレージの摩耗は気にしなくていい。(/tmp/はオンメモリストレージ)
トラブルシューティング
Thermalタブに壊れて表示されていない画像や、集計対象外のグラフが表示される
上図の青枠のように壊れて表示されていない画像や、集計対象外のものが表示されている場合、/tmp/rrd/OpenWrt/配下にある不要なメトリクスを削除することで非表示にできる。
例えば上図にあるthermal-cooling_device*にはまともにデータが入っていないため、画像が壊れて表示されている。rm -Rf thermal-cooling_device*で消すと出てこなくなる。
上図の状態になると、下図のように不要なグラフが表示されなくなる。
但しcollectd.confで以下のようにデバイスを絞っていないと、再び出てくると思われるので、設定で表示したいものだけに絞ってから消した方がよい。
LoadPlugin thermal
<Plugin thermal>
Device "thermal_zone1"
</Plugin>




























