あっきぃ日誌

ラズピッピブログのようなオタクブログのようななにか

MacPortsを卒業してツール整備をやり直してみる

長らくMacのツール整備周りではマイナー?なMacPortsを使ってきましたが、なんとなくそろそろモダンな感じにしたくなったので、ガラリと入れ替えることにしてみました。

MacPorts周りで直近も使っていそうなものとしては、aws-vault git sshpass iperf3 zstd xz libusbあたりでしたが、どれもHomeBrewで代替可能なので、HomeBrew化します。

別途asdfを、aws-cliとOpenTofuのバージョン管理に利用していたのですが、使っているMacによってはこれらを手動インストールをしていたので、ここはasdfに統一しました。また、asdfの導入もHomeBrewでするようにしました(ここはまだ統一できてない)。

MacPortsで導入していたPythonについては、uvで代替してみることにしました。uv独自のプロジェクト系のコマンドはまだあまり使いこなせていないので、現状は単にPythonの導入と、uv toolでAnsibleを入れる程度になっています。uvの導入もHomeBrewでやりました。

以下は自分向けメモ。3台分あるので手順書として。

MacPortsのアンインストール

port listコマンドで、必要なツールをメモしてから、ドキュメントに従ってアンインストールします。

2.4. Uninstall MacPorts

HomeBrewの導入

何回目かの導入。XとかQuartzの要件がなくなったので今度こそいけるとおもう。

Homebrew — The Missing Package Manager for macOS (or Linux)

そしてMacPortsで使用していたツール+asdf+uvを導入します。

$ brew install aws-vault git sshpass iperf3 zstd xz libusb asdf uv

asdfで管理しているツールの整備

まずはインストール済みのものを削除します。

# aws-cli
$ sudo rm /usr/local/bin/aws
$ sudo rm /usr/local/bin/aws_completer
$ sudo rm -rf /usr/local/aws-cli

# OpenTofu
$ sudo rm -rf /opt/tofu_1.6.2_darwin_arm64

次にプラグインを追加して、最新版を導入。

# aws-cli
$ asdf plugin add awscli
$ asdf install awscli latest

# OpenTofu
$ asdf plugin add opentofu
$ asdf install opentofu latest

~/.tool_versionsにバージョンを書いて固定します。

$ vi ~/.tool_versions

awscli 2.34.18
opentofu 1.11.5

uv

Pythonも気づけば3.14がリリースされていたので、3.14を導入します。このあたり、MacPortsでは3.10〜3.12が混在するカオスになっていました……。

$ uv python install --default  3.14

Ansibleの導入はuv toolコマンドを使うと、Python環境全体で使えて良いらしいので、これを使いました。Ansibleが時折ライブラリを必要としてくるので、そういうときは--withオプションで指定すると良いようです。requestsを追加しました。おそらく今後も必要になるパッケージはありそう。

$ uv tool install --with requests ansible-core
$ uv tool install ansible

環境変数周り

MacPorts周りを消して、homebrew、asdf、uv周りのパスが追加されしました。また、pip/pip3コマンドはuv pipコマンドのエイリアスにしました。

eval "$(/opt/homebrew/bin/brew shellenv zsh)"

export PATH="${ASDF_DATA_DIR:-$HOME/.asdf}/shims:$PATH"

export PATH="$HOME/.local/bin:$PATH"
alias pip="uv pip"
alias pip3="uv pip"

さっぱり

バージョン管理ツールが増えた(asdf、uv)ので、さっぱりしたのかと言われるとよくわからんですが、環境によっては手動で入れていたものがバージョン管理できるようになったり、uvでpipの高速化が出来たりと良いことは多いので、いい感じになったかなと思います。

Rasperry Pi OSのカーネルがそろそろ6.18になるのでRealtek RTL8127 10GbE NICを試す

先日のRaspberry JAMの発表資料にも書いたとおり、ぼちぼちRasperry Pi OS Trixieのカーネルが6.18系に移行するようです。

https://forums.raspberrypi.com/viewtopic.php?t=394580

6.18になるということは……そうです、前に買ったRealtek RTL8127搭載の10GbE NICが試せます。

akkiesoft.hatenablog.jp

久しぶりにPCIeスロット変換ボードを取り出して準備。Pi 5のPibowを外すのが手間なのが難点……。

というわけで、Pi 5でRTL8127なNICを試していくブログです。が、先にいうとまだ性能を出し切れておらず。ぐぬぬ。

カーネル導入

まずはrpi-updateを実行して6.18のカーネルを導入します。カーネル周りがaptの道から外れるため、試すときはこれ用の環境を用意することをおすすめします。

$ sudo rpi-update

カーネルを入れ終えたら電源を切り、NICを搭載して、電源を入れます。LANケーブルもRTL8127に刺しちゃいましょう。

起動したらSSH接続。普通に接続できて使えています。ワクワクですね。ipコマンドを見るとeth1が生えています。アツい。

$ ip a
(略)
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 88:c9:b3:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 192.168.29.***/24 brd 192.168.29.255 scope global dynamic noprefixroute eth1
(略)

erhtoolコマンドでみると、10000baseT/Fullという夢のある文字列も並びますが……

$ ethtool eth1
Settings for eth1:
	Supported ports: [ TP	 MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	                        10000baseT/Full
	                        2500baseT/Full
	                        5000baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	                        10000baseT/Full
	                        2500baseT/Full
	                        5000baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Half 1000baseT/Full
	                                     2500baseT/Full
	                                     5000baseT/Full
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 5000Mb/s
	Duplex: Full
	Auto-negotiation: on
	master-slave cfg: preferred slave
	master-slave status: slave
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	MDI-X: Unknown
netlink error: Operation not permitted
	Link detected: yes

「Speed: 5000Mb/s」。「Link partner advertised link modes」=スイッチがこの速度でリンクできまっせと言ってきたモードに10000baseT/Fullがないようです。どうして……。

ドライバーを変える

調べてみると、RTL8127 NICに対してカーネル標準のr8169ドライバーが使われるのですが、動作不安定など色々あるもよう。代替案については、r8168-dkmsパッケージを入れるか、それもイマイチなのでRealtek公式からソースコードをダウンロードしてコンパイルするかが良いようです。

r8168-dkmsパッケージのやりかたはなんか微妙にうまく行かなかった(たぶんやり方がだめだった?)のと、パッケージが新しくなかったのとで、ソースコードからコンパイルすることにしました。

カーネル系のコンパイルをするので、必要なツールと、rpi-updateで導入したカーネルに合うソースコードを取得するためのツールrpi-sourceを導入します。導入手順はrpi-sourceのREADMEの手順相当です。

$ sudo apt install git bc bison flex libssl-dev libncurses5-dev -y
$ sudo wget https://raw.githubusercontent.com/RPi-Distro/rpi-source/master/rpi-source -O /usr/local/bin/rpi-source && sudo chmod +x /usr/local/bin/rpi-source && /usr/local/bin/rpi-source -q --tag-update

そしてソースコードの取得。ホームディレクトリに~/linuxとか~/linux-(なんか長いやつ)が生成されます。

$ rpi-source

Realtekのサイトからドライバーのソースコードを取得します。今回は「10G Ethernet LINUX driver r8127 for kernel up to 6.15」を選択。ダウンロードしたらRaspberry Pi環境に転送して展開します。

www.realtek.com

$ tar xf r8127-11.016.00.tar.bz2 

コンパイルはautorun.shを使用せずに、srcディレクトリでmakeコマンドを実行します。autorun.shはうまく使えないので。というのも、インストール後に、6.18.18-v8-16kのmodulesにインストールされたr8127.ko.xzを、6.18.18-v8-16k+のmodulesにコピーする必要があります。なんか、makeファイルの中で変数の展開がうまく行っていないのか、+がない方にしかドライバーが作られないんですよね。これが解決できたらautorun.shでも良いような気がします。

$ cd r8127-11.016.00/src
~/r8127-11.016.00 $ make -j 6
~/r8127-11.016.00 $ sudo make install
~/r8127-11.016.00 $ sudo cp /lib/modules/6.18.18-v8-16k/kernel/drivers/net/ethernet/realtek/r8127.ko.xz /lib/modules/6.18.18-v8-16k+/kernel/drivers/net/ethernet/realtek/r8127.ko.xz

ここまでできたら、depmodしてからドライバーを読み込めば、r8127でNICが認識するようになります。ダメそうならOS再起動でもOK。

$ sudo depmod -a
$ sudo modprobe r8127
$ ethtool -i eth1
driver: r8127
version: 11.016.00-NAPI-DASH
firmware-version: 
expansion-rom-version: 
bus-info: 0001:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

改めてethtoolのオプション無しで。10000Mb/s、きたああああああああああ!!!!

$ ethtool eth1
Settings for eth1:
(略)
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Half 1000baseT/Full
	                                     10000baseT/Full
	                                     2500baseT/Full
	                                     5000baseT/Full
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 10000Mb/s
(略)

ちなみに、使用するドライバーを常にr8127にするためには、/etc/modprobe.d/以下の適当なファイルにブラックリストを追加する必要があります。見たらちょうど8192cuのblacklistがいたので、同じRealtekのドライバー同士ということで、ここにでも追記しておきました。これでOSを再起動してもr8127が使われるようになったはずです。

$ sudo vi /etc/modprobe.d/blacklist-8192cu.conf

blacklist 8192cu
blacklist r8169  ←追記

スピードがでない

というわけで早速iperf3を叩いてみます。対抗は自作PCな自宅サーバーです。どん!

$ iperf3 -c 192.168.29.**
Connecting to host 192.168.29.**, port 5201
[  5] local 192.168.29.*** port 42642 connected to 192.168.29.** port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   435 MBytes  3.65 Gbits/sec    0   1.14 MBytes       
[  5]   1.00-2.00   sec   434 MBytes  3.64 Gbits/sec    0   1.27 MBytes       
[  5]   2.00-3.00   sec   434 MBytes  3.64 Gbits/sec    0   1.27 MBytes       
[  5]   3.00-4.00   sec   432 MBytes  3.63 Gbits/sec    0   1.27 MBytes       
[  5]   4.00-5.00   sec   434 MBytes  3.64 Gbits/sec    0   1.27 MBytes       
[  5]   5.00-6.00   sec   433 MBytes  3.63 Gbits/sec    0   1.27 MBytes       
[  5]   6.00-7.00   sec   434 MBytes  3.64 Gbits/sec    0   1.27 MBytes       
[  5]   7.00-8.00   sec   433 MBytes  3.63 Gbits/sec    0   1.33 MBytes       
[  5]   8.00-9.00   sec   434 MBytes  3.64 Gbits/sec    0   1.33 MBytes       
[  5]   9.00-10.00  sec   433 MBytes  3.63 Gbits/sec    0   1.33 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  4.23 GBytes  3.64 Gbits/sec    0            sender
[  5]   0.00-10.00  sec  4.23 GBytes  3.63 Gbits/sec                  receiver

3.6Gbpsを記録。あれ、スピードがでない。実測のMaxでは6.3Gbpsくらい出せるはずなので、何かがおかしいですね。2.5Gbpsは超えているので、これでも十分早くはありますが。

akkiesoft.hatenablog.jp

……あーわかった。PCIe3.0x1を有効にしてなかった!

PCIe3.0x1を有効にでき……ない

/boot/firmware/config.txtにdtparam=pciex1_gen=3を書くか、raspi-configコマンドでPCIeの設定をして、PCIe3.0x1を有効にします。

$ sudo vi /boot/firmware/config.txt

[all]
dtparam=pciex1_gen=3 ←末尾に追加

そして再起動。……あれ、起動してきませんね。起動画面をキャプチャーで確認すると、ウーンなんですかね?

ASPMは、そういや前に試した時に、cmdline.txtに設定の追記が必要だったりしました。上の自分のブログ記事から引用。

(1) どちらも共通して、/boot/firmware/cmdline.txtに「pcie_ports=compat pcie_aspm=off」を追加しないと、PCIeのリンクエラーが大量に出てなんかシステムがめちゃくちゃ不安定になったりする

これを試すと、起動はしそうなのですが、スプラッシュ画面で止まってしまいます。おしい。

cmdline.txtから「quiet splash」を削って様子を見ます。あと、ここまで不精をして公式電源を使っていなかったので、公式電源に交代して試します。起動すると、ズラズラメッセージが出ましたが……

ああ、なんかダメそうですね。

r8127 0001:01:00.0: of_irq_parse_pci: failed with rc=-22
r8127 0001:01:00.0: Unable to change power state from D3cold to DO, device inaccessible

他にもいくつか試してみましたが、PCIe3.0を有効にした状態ではOSを起動すらできませんでした。ぐぬぬ。

まとめ

RTL8127がハード的にまだという感じなのか、Pi 5のファームウェアでPCIe周りに改善の余地があるのかは不明ですが、残念ながらPi 5でパフォーマンスを出し切るのは難しいようでした。それでも3.6Gbps(450MB/s)を出せていて、PCI2.0x1の片方向理論値である500MB/sに近いので、PCIe2.0としてはかなり優秀っぽそうです。

現実的にはまだ2.5GbEからこれからというかんじなので、アリエクとかで買える2.5GbEのやつ(RTL8125)とかを使うのが良いんでしょうね。

https://ja.aliexpress.com/item/1005010471978840.html

でもこれ(Pi 5で10GbE NIC)はロマンだから……などと。

Raspberry JAM 2026.3レポート(自ブログ編)

今週木曜はRaspberry JAM 2026.3でした。ちゃんとした(?)レポートはraspi.jpの方に書きました。

www.raspi.jp


スライドの解説

私の発表資料はこちら。基本的に値下がる要因がない昨今の万物に例外なく含まれるRaspberry Piの、なんかすごい妥協みたいになるんじゃ……みたいな1GB RAMモデルを実際に使うとしたら、どんな感じなんだろうというのをやってみました。

speakerdeck.com

config.txtにtotal_mem=1024を書くと、メモリが多い環境でも1GBに制限できるので、これで検証をしてみた次第。実際買ってもいいっちゃいいんですが、既に8GB RAMだの何だの、すでに台数が揃っている我が家では余してしまうので……。

当初の目論見としては、まあブラウザは厳しいっすねって言って、水野さんがインプレスに記事を書いていたChawanを使う流れにしようかと思っていたのですが、なんか全然予想よりもRaspberry Pi OSが1GB RAMな環境で普通に使えてしまい、紹介できませんでした。

pc.watch.impress.co.jp

というのも、ためしているとちゅうで swapの様子がおかしいことに気づき、zramとか言う知らんやつがしれっと使われていたおかげで、1GB RAMでもなかなか快適に使えることがわかりました。すごいね。

あとはスライドにも書いたとおり、Waylandコンポジターの変化によってデスクトップ要件も変わってきたのも影響している可能性はありそうです。

発表

raspi.jpのレポートでも書いた通り、Pi 5で発表をしてきました。せっかくのバースデーにラズパイも使わず何がラズパイのユーザー会だ、っていう気持ちがあったので……。

この環境ももちろん1GBに制限済みだったのですが、問題なくPDFの資料を開いてプレゼンができました。資料の中にある通り、LibreOfficeで発表することも可能ですが、今回はどちらかと言うと、先に作成した資料がMac上のパワポで、互換性の都合で崩れるためPDFとしています。

いうて2GBか4GBでは

発表では1GBで十分動きますよと書きましたが、実際買うなら2GB、さらに余裕を見るなら(かつお財布に余裕があれば)4GBが良さそうかなと言う感じがします。

8GBとか16GBに関しては、元々上級者向けとして出てきているもので、それ以下では快適な性能を得られるものではない……というものではありません。「ラズパイったら今や2.5万とか4万とかしちゃってねえ!」はそれはそうですが、上級者向けのモデルの話です。昨今のメモリ価格大爆発中にもかかわらず価格を維持してくれている1GB RAMモデルが、7,000円(Pi 4)とか9,000円(Pi 5)でまだ踏ん張っていますよと言うのは、覚えていてほしいなと思うところです。あるいはZero 2Wもまだ価格を維持していますし。

さて、メモリ価格大爆発に残念ながら巻き込まれた方となる2GB RAMモデルは、現状は1万(Pi 4)とか1.3万(Pi 5)という感じです。案外悪くない。

きびちいね

"パンがなければケーキを食べればいいじゃない"みたいな話っぽいよねって話もしてたんですが、Pi 4なら当初7,000円で4GBが買えてたのが今や1GBになっちゃってね〜って感じで、なかなかおつらい昨今ですが、この先良くなる要因がないどころか、中東情勢という新たな悪化要素すら増えているので、「買いたい時が買い時」という状況はまだまだ続きそうだなと思っています。

メダカメラの外カメラ修理

メダカメラの外カメラが、たぶん雨水等々で基板をやられたのか死んでしまいました。基板の部品から吹き出した何かが目立っていたので、だめかと思いましたが、無水エタノールで拭いてきれいにしたら復活しました。吹き出た何かでショートしてしまっていたんでしょうかね。

というわけでついでに外カメラを改善しようとしました。と思って、ここに過去の記事を貼ろうとしたら、そもそも書いてなかったという。ウソでしょ……。ただ、メダカメラのaboutページには貼ってるので、比較できますね。

shrimp.marokun.net

夏にArducamの"CSIをHDMIに変換するやつ"を購入したという話は書いていましたが、その先を書いてなかったという。

akkiesoft.hatenablog.jp

その後、部屋のダクトにHDMIケーブルを通して、外カメラを水槽ビタ付けできるようにしていました。

この時なぜか面倒くさがって、カメラを外出しにする愚行をしてしまったのですが、ヤモリグリップに表面実装部品がいい感じに埋まったので、それでヨシということにしていました。ただ、全部は埋められていなかったので、そこが主にやられたようです。


ちゃんとケースに収める

ケースに穴を開けました。IKEAのドリルビットセットに入っていたのは6mmと8mmで、カメラの先端は7mmという惜しい感じでしたが、8mmで穴をオープン。

ヨシ。

裏側はこんな感じで、絶妙に足場が必要でしたが、ホットボンドごつ盛りでくっつけて対応。

ホントはこんな感じの足場を設計してみたのですが、会社まで3Dプリントを使わせてもらいに行くのも面倒なので、上記雑工作となりました。やっぱ家に3Dプリンター置こうかなあ……?

カメラ穴の隙間をホットボンドで埋めます。眉みたいなのは、水がたれてきたらここを伝って横に流れてくれないかな……?ってやつです。たまに電車のドア上にもいますよね(突然のオタク語り)

あとはケース内に一通りを収め、固定します。強力磁石をホットボンドでケースに貼り付けて、ブックスタンドにくっつけられるようにしました。便利。

そして設置。いやあ良かった良かった。

ただ、改善前の状態から引き続き課題なのは、HDMIケーブルがやや足りないというところ。50cmくらい延長すれば良いのですが、そうすると延長コネクター部分に待たケースが必要になるので、面倒だなあというお気持ちです。足を引っ掛けたことは1〜2回ほど……。

カメラが壊れていなくて本当に良かったです。古くて余っているとは言えV2のカメラなので、さすがに大事に使おうと思いました。半年ちょっと外でむき出しで動かしててなんですが。

Raspberry Pi M.2 HAT+ Compactはアクティブクーラー実装のPi 5と組み合わせられるか?

KSYさんでPimoroniのMicro Dot pHATがまだ売られていたので、赤バージョンを購入しました。Pimoroniでは終売していて、販売しているところは貴重だったりします。このあと寝る前に組み立てようか、明日にするか……。


Raspberry Pi M.2 HAT+ CompactってアクティブクーラーなPi 5と組み合わせられる?

Micro Dot pHATだけ買うのもなんなのでRaspberry Pi M.2 HAT+ Compactも買ってみました。M.2を載せられるやつは足りてるんですけど、気になってたので……。ついで買いはしていますが、別に送料が無料になったわけでもないです。なぜ買った。

基板の表面。コンパクト版は公式のPi 5ケースと組み合わせて使用できるバージョンとしてリリースされたもので、ファンを避けるように基板がデザインされています。結果、FPCがよくわからん飛び出し方になっており、なんか引っ掛けて壊しそうなのがやや怖です。しかも、ケーブルは基板から直接飛び出しているので、FPCが破断したらボード全体が終了するハードモード仕様。どうしてコネクターにしなかったんだろう。

裏面。こちらにチップ部品類が実装されています。ピンソケットもこちら側です。

さてこのボード、公式のPi 5ケースとの組み合わせについては書かれていますが、アクティブクーラーを付けたPi 5と組み合わせられるのかについては特に言及がなく、まあなんとなくそのままではダメそうとは思っていましたが、誰も試した写真を上げてすらいないようだったので、試してみました。ググり方が悪いだけかもしれんけど。

だめでした。でしょうね。

もちろん、GPIOの延長ヘッダーを使えば搭載は可能です。ノーマルのM.2 HAT+から延長ヘッダーとスペーサーを拝借すると、こんな感じで使えそうです。

横から見るとこんな感じ。スペーサーがないとクーラーの金属部分に部品類が乗っかる感じになるので、スペーサーは付けたほうが良さそうです。ただし、ここで言うスペーサーはコンパクト版に付属のものではなく、ノーマル版に付属の16mmのものを指しています。

いちおう、比較用にノーマル版のM.2 HAT+の写真も。こちらは全体が覆われて公式ケースが使えなくなる代わりに、MIPIポートにアクセスしやすい形状になっています。給排気の面で有利・不利が変わりそうな気がしなくもないですが、正直誤差のような気もしています。どうなんでしょうね。


フーム

ここまで書いて公式ケースとの組み合わせは撮らないんかいって言われそうですが、だって、面倒だし、ググればでてくるし……。

公式ケースでNVMeを使いたい方はコンパクト版一択なのはさておき、アクティブクーラー派の人が、足りない延長ヘッダーと脚を別途用意してまでコンパクト版を使う意味があるかと言われると、そうでもなさそうという感想でした。

なんとなく、WaveShareとかが出している、アクティブクーラーのヒートシンク部分にM.2がくっついたやつの方が、コンパクトさを追求する意味ではアリなのかなあと思いました。いや、Pi 5とかそんなに何個もないので、これ以上M.2 HAT系は増やさないけど……。

Waveshare Raspberry Pi 5用 PCIe-M.2 SSD変換基板(ヒートシンク&ファン付属) — スイッチサイエンス

明日すぐに役立つわけでもない感じも小ネタみたいなレビュー記事でした。私の疑問は解消したからいいの!!!