家鯖の消費電力がとある時点から急に増えた。その差は実に30Wで明らかに誤差ではない。

FreeBSDな仮想マシンを起動すると増えるのは明白だったが、原因として思い当たることはなかった。が、ふとProxmox VEのCPU使用率グラフを見たら、FreeBSD 13.0-RELEASEに更新したタイミングでCPU利用率が大幅に上がっているのに気付いた。

FreeBSD内でtopしても特段高負荷なプロセスはなかったものの、よーく見てみるとSystemが4～5%となっており、何かがCPUを使ってるのは間違いない。そこでtop -SPでシステムの個別の状態を見てみると、rand_harvestqが定常的に1CPUの40～80%を食っていた。

プロセス名から察するに、乱数のエントロピー収穫用のプロセスである。エントロピー収穫の詳細は、手前みそながらこちら。

関連するシステム変数を見ても、特に変な個所はなさげ。しいて言えば、乱数源としてVirtIO Entropy Adapter (VirtIO RNG)とIntel Secure Key RNG (RDRAND)の2種類が使われてる点が仮想マシン特有ってところかな。

$ sysctl kern.random
kern.random.fortuna.concurrent_read: 1
kern.random.fortuna.minpoolsize: 64
kern.random.rdrand.rdrand_independent_seed: 0
kern.random.use_chacha20_cipher: 1
kern.random.block_seeded_status: 0
kern.random.random_sources: 'VirtIO Entropy Adapter','Intel Secure Key RNG'
kern.random.harvest.mask_symbolic: VMGENID,PURE_VIRTIO,PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
kern.random.harvest.mask_bin: 100001001000000111011111
kern.random.harvest.mask: 8683999
kern.random.initial_seeding.disable_bypass_warnings: 0
kern.random.initial_seeding.arc4random_bypassed_before_seeding: 0
kern.random.initial_seeding.read_random_bypassed_before_seeding: 0
kern.random.initial_seeding.bypass_before_seeding: 1

で、まぁ、色々と試してみたら、VirtIO Entropy Adapterが高負荷の原因だった。

その名の通り、VMでホスト側の乱数デバイスを使うための準仮想化デバイスなんだけど、ふつーに考えたら負荷は低くなるハズ。VirtIO RNGの乱数源は/dev/urandomにしてあるので、ブロックすることもないハズだし…。この辺、特にいじってはないんだけどなー、謎。

準仮想化で負荷が高くなっては本末転倒なので、VMからVirtIO RNGを取り除いて運用することにした。FreeBSD側ではIntel Secure Key RNGが動いてるので問題はないでしょう。

これで消費電力は無事元の水準に戻り、お財布の平和は保たれたのであった。

FreeBSDのMariaDB 10.3を10.5に更新し起動しようとしたら、以下のメッセージが出て起動できなかった。

$ sudo service mysql-server start
Please merge existing /usr/local/etc/my.cnf file with /usr/local/etc/mysql/conf.d/server.cnf
/usr/local/etc/rc.d/mysql-server: WARNING: failed precmd routine for mysql

my.cnfとserver.cnfをマージしろとな。

/usr/ports/UPDATINGを探ると以下の文言を発見。

20200526:
  AFFECTS: users of databases/mariadb104-client, databases/mariadb104-server
  AUTHOR: brnrd@FreeBSD.org

  The ports now add sample configuration files to /usr/local/etc/mysql. You
  must merge your client configuration with the conf.d/client.cnf and your
  server configuration with conf.d/server.cnf.

MariaDB 10.4から設定ファイル置き場が/usr/local/etc/mysqlになったっぽい。今までmy.cnfに一緒くたで書いていたサーバ、クライアントの設定は、それぞれconf.d/server.cnfとconf.d/client.cnfに分ける流儀になった模様。一応、my.cnfも存在するので、そこに書いても問題はないだろうけど…

とりあえず目マージで対応し、/usr/local/etc/my.cnfを消したところ、無事起動することを確認。

最初に謝っておこう。復旧と言ってるけど、実態としては殆ど新規インストールなんだ、すまない。

誤って家鯖のFreeBSDを飛ばしたわけだけども、13.0-RELEASEの完全クリーンインストールはやめ、既存環境を上書きする形で12.2-RELEASEを起動できる状態にいったん戻すことにした。FreeBSD標準の自動インストールでは、ストレージの現在のパーティションを生かす方法がなく、結局手動でアレコレする羽目になる。だったら、手っ取り早く上書きインストールした方が簡単かなと。

上書きインストール、というかFreeBSDのインストール自体は/usr/freebsd-distにあるアーカイブをファイルシステムに展開するだけ（と少々の起動設定）なんだけど、せっかくなのでbsdinstallを使ってみた。

必要な環境変数を設定し、bsdinstall distextractを実行するとアーカイブを展開してくれる。

まずはFreeBSDのインストーラでマシンを起動し、Shellに落ちて、破損したシステムをマウントする。うちはRoot on ZFS環境なので↓のような感じ。

# mkdir /tmp/zroot
# zpool import -f -R /tmp/zroot zroot

続いて環境変数の設定。

# export BSDINSTALL_DISTDIR=/usr/freebsd-dist
# export DISTRIBUTIONS="base.txz kernel.txz lib32.txz"
# export BSDINSTALL_CHROOT=/tmp/zroot/

でもってbsdinstallを実行。

# bsdinstall distextract

すると見慣れたFreeBSD Installer画面になって展開が進む。終わるとシェルに戻ってくる。

ZFS起動に必要な設定を書き込む。

# echo 'zfs_load="YES"' >> /tmp/boot/loader.conf
# echo 'zfs_enable="YES"' >> /tmp/etc/rc.conf

念のためプールをエクスポート＆再起動

# zpool export zroot
# reboot

これで、新規12.2-RELEASEが立ち上がった。以前のデータの残り具合次第では、ある程度、設定済みの環境も戻ってくるだろう。自分の場合、/usrと/etcが完全に消えたので、殆どクリーンインストールと一緒だけどな！気持ち的には、秘伝の家鯖の血脈は保たれた。まっさらな環境だけどな！

ベニクラゲのように若返ったとでも思っておこう。

(2021/04/26 追記)

環境構築を進めてみると/usr/local/etcがほぼほぼ残っていることが判明。これは名実ともに血脈が保たれたと言ってもいいのでは…！？しかしあれだ、ちゃんとバックアップは取っておきましょうね。

• bsdinstall(8)
• freebsd/zfsboot at master · lattera/freebsd · GitHub

家鯖のFreeBSDをミスってrm -rf /してしまった。ぼくも流石にそこまでアホではないので、rm -rf /を直接実行したわけではなく、結果としてそうなったという感じ。いにしえのRoot on ZFS環境からBoot EnvironmentなZFS構成に変更していた際の出来事である。

幸い/usr/homeは別プールでマウントもしていなかったので最悪の事態は免れた。しかし、FreeBSD 9-BETA3の頃から連綿と続いてきた環境が飛んでしまった。途中で気づいたので全損ではないが、何がどこまで残ってるのかも分からないし調べるのも面倒。ここは素直に出たばかりの13.0-RELEASEで構築し直しですかね…。

システムの安らかな成仏を願いつ、本システムにまつわる昔話をしてみる。

本システムを組んだのは2011年10月頃。実際には夏頃から作り始めてた気がする。

当時動かしていた家鯖はポリカMac miniにUSB-SATA変換でHDDを繋いだものだった。HDDが足りなくなってきたこと、もう少し自由な環境にしたかったこと（BSDベースとはいえMacは何だかんだクセがあって大変だった）が理由で、移行先の調査をしていたところにFreeBSDとZFSを使う方法を見つけた。このころのHDDは容量の増加が伸び悩んでて、3TBのモデルが出回り始めた時世である。容量を稼ぐにはRAIDが必然だった。信頼性を取るとH/W RAIDになるが値段も消費電力も敷居も高く、一方チプセRAIDは身近でいい話を聞かなかったし、汎用性に欠けるので使いたくなかった。

こんな状況でZFSに出会ったものだから、まさに渡りに船状態、その衝撃たるや半端なかった。FreeBSDには多少の覚えがあったし、ちょうど放出品のMicroServerでNASを作るのが流行ってたこともあって、すぐさまFreeBSDとZFSな家鯖作りを始めたという具合。Root on ZFSな環境を作るのに、何回もFreeBSDをインストールし直し、幾度となくzpool, zfsコマンドを叩いた。めげずによくやったもんだわ。

それから10年、大きく5回のハードウェア構成変更、システムプールのHDD→SSD化、データプールの構成変更（RAID-Z [HDDx4]→RAID-Z+0 [HDDx3x2]→RAID-Z [HDDx4]→RAID-Z2 [HDDx5]）や物理と仮想を行ったり来たり、時にはカーネル更新に失敗してbuildworldする羽目になりながらも、途中での環境作り直しもなくやってきた。

• ProLiant MicroServer (AMD Turion II NEO N36L)
• H77 Pro4/MVP (Xeon E3-1240L)
  • ESXiでP2V
• Z77A-GD65 (Xeon E3-1260L)
  • 物理に戻した
• C2750D4I (Atom C2750)
• X10DRi (Xeon Xeon E5-2648Lv3 → E5-2673v3)
  • 当初物理、2021年2月からPVEでP2V

そんな秘伝のシステムを不注意でポアしてしまって本当に悲しい…。

Legacy ZFSブートからUEFIブートへの変更を乗り越え、今度はBoot Environment化を目論んでいたのに……そのための手順と記事をチマチマ書いてたのに………。ZFSなんだから、破壊的操作の前にスナップショット取っておけって話である。実際、取ろうかどうか迷った挙句、取らなかったんだよね…………。後悔先に立たず。

今北産業用。

• REALFORCE R2ではCaps Lock, Ctrl入れ替え時の交換用キーキャップはAPCモデルにしか付属しない。
• モデルによってはカラーリングを含めた完全互換の交換用キートップの個別入手は不可能。
• Aキーの左側だけならHHKB用キーキャップが使える。
• ちなみにCaps Lock/Ctrlの入れ替え方は次のとおり：
  • R1 → キーボード裏面のDIPスイッチの1番をON（ファンクションキーがある方向にスライド）
  • R2 → Fn+F11押下後、Fn+F9で設定を保存

以下、チラ裏。

超PayPay祭のポイント還元に釣られてREALFORCE R2を買った。初代を2台（自宅用にアイボリー、会社用に黒）を持ってたりするんですけど、やっぱりR2気になるじゃないですか。だってオタクだもの。

自分は英語配列/テンキーレス/変荷重/A横Ctrl派閥に属している。R2から通常ラインナップ入りした静音モデルが気になるので、機種は自ずとR2TLS-USV-IVかR2TLS-USV-BKに定まった。アイボリーと黒、悩ましいところだが、経験的にアイボリーを選んだ。初代の両色をそれなりに使ってきて、黒には以下の難点があることが分かったからだ。

1. キートップの印字が見づらい
2. テカリが目立つ
3. ホコリが目立つ

印字が見づらいのは、完璧にタッチタイピングできる人なら問題にならないだろう。でも僕ちゃんは無理なの。特に最上段の数字キーらへん。おおむね大丈夫ではあるが、列ずれして意図しない文字が入力された時に手元を見て補正するクセがあり、その時に文字が見えないと厳しい場合がある。

テカリは「アイボリー比で」という注釈が付くくらいに些細な問題ではある。REALFORCE自体、安物キーボードと比べると全くと言っていいほどテカらないが、それでもアイボリーと比べると、よく使うキーで黒はテカりが目立つ傾向にある。

ホコリ目立つのは掃除の目安になって、ある意味いいこととも言えるし、逆にアイボリーは手垢が目立ったりするので一長一短だったりはする。自分的には、手垢は気になりだすのに数か月かかるのに対し、ホコリは掃除したそばから気になりだす。

そんなわけでR2TLS-USV-IVを購入。昔ながらのツートーンの配色も割と好きだったりする。

R2到着後、さっそくCaps Lockと右Ctrlのキー設定を入れ替え、キートップも交換しようとしたら、あれれー交換用のキートップがないぞ？箱の中をひっくり返しも見当たらず。よくよくメーカーサイトで各モデルの仕様を比較すると、交換用キートップはAPCモデルにしか付属しないっぽい？。初代では（たぶん）全モデルに付属してたのに、そりゃないぜ東プレさんよお。

単品販売はしてないし、交換用の色付きキーキャップ全セット（青/赤/緑/橙/黄/紫）は用意されているものの、本体の半値という高額設定なうえ、通常カラーのアイボリーと黒がないので完全に詰んだ。

APCで変荷重なモデルって日本語配列しかないし、APC付きの英語配列は固定荷重のPFU Limited Editionしかないし、APCなし変荷重英語配列モデルをチョイスした時点で詰んでた。そりゃないぜ東プレさんよお！

Aキー左のCtrl用（元の配列ではCaps Lock）だけならHHKB用の交換用キートップ、すなわち初代REALFORCEのものが使えるらしい。

こっちもかわいくした pic.twitter.com/xpOeRnRgQk

— yuki (@_yuki1217_) February 3, 2021

左下CapsLock（元の配列ではCtrl）はR2からの新サイズっぽいので、現状互換品は見当たらず。色（と価格）に我慢して交換用正規のキートップ全セットを買うか、APCモデルを買ってニコイチするしかなさそう…。

こうした細部への拘りもREALFORCEの売りの一つだと思ってたので、正直ガッカリですわ。割高でもいいから単品販売してくれないかなー。