先日Super-microDXにインストールした河豚板をfiupdateでアップデートしようとしたところ、すこしつまづいてしまったので、メモを残しておく。
前提というか背景を書いておくと、Super-microDXにはコンパクトフラッシュのドライブ（リーダ？）が内蔵されている。OSはコンパクトフラッシュにインストールして運用することが多い*1。なお河豚板というかOpenBSDはコンパクトフラッシュをIDE（パラレルATA）として認識していて、転送モードとしてPIOモード4とUltra DMAモード2が選択されている。
「Super-microDXにインストールした河豚板」と書いているが、これはSuper-microDX上でUSBメモリから河豚板を起動して、usbfadmのnewdriveコマンドを使用してコンパクトフラッシュ上に河豚板のLiveUSB版*2を書き込んだ後、コンパクトフラッシュからブートして使用しているのだ。
さて本題。河豚板はOpenBSDのパッチ適用などに合わせてアップデート版がリリースされる。LiveDVD版の場合はメディアを作り直すしかないのだが、LiveUSB版の場合はfiupdateというコマンドを使用して中身を直接更新することができる。
で、このfiupdate、少なくとも河豚板 7.1のi386版では、少しやり方を工夫しないと失敗する。私の環境ではgzip(1)に「No space left on device」と言われてしまった。
河豚板ではRAMディスク上にホームディレクトリ等が展開される。河豚板 7.1ではRAMディスクを実現するためにmfs（Memory File System）を使用しているのだが、i386でのmfsの最大サイズは約1GBである。
つまりホームディレクトリでfiupdateする場合、どう頑張っても1GBのディスクスペース上で作業することになってしまう。で、fiupdateするには1GBでは足りない。
mfsの最大サイズはアーキテクチャごとに異なるようで、amd64では32GB、arm64では16GBと河豚板ガイドに記載されている。だからamd64とarm64では、mfsの割り当てを工夫すればfiupdateがディスクフルで失敗する問題は回避できる。でもi386ではmfsの割り当ての調整ではどうにもならない。
なので、河豚板 i386版でfiupdateする場合は、別途書き込み可能な作業用パーティションを用意して、その中でfiupdateの手順を実行する必要がある。
手元の環境の場合、16GBのコンパクトフラッシュの大半をデータ保存用領域（noasksファイルとかが置いてあるパーティション）に割り当てている。そこで今回はデータ保存用領域を作業用パーティション代わりにしてfiupdateを実行した。
# rootで作業していると仮定： mount /dev/wd0d /mnt cd /mnt ftp https://jp2.dl.fuguita.org/{MD5,FuguIta-7.1-i386-202205061.iso.gz} fiupdate 202205061
更新はうまくいったようだ。
ただしSuper-microDXの個体の問題なのか、アップデートの最後にデータ保存用領域がうまくアンマウントされなかったようだ。そのため後で「fsck /dev/wd0d」とチェックを走らせることになった。この件はハードウェア側の問題だと思う。
2022-05-31追記：アンマウントの件は、河豚板 7.1 202205161まで存在していた「fiupdateの最後に実行されるrebootが失敗することがある問題」が原因だった模様。この問題は202205161と202205241の2回に分けて修正されたようだ。
