弊宅には2018年に購入したアーロンチェアがある。貧乏なのでもちろん中古品。アーロンならどれでも一緒だろうと何も考えずに買ったら座面昇降機能だけの梅モデルで、ひじ掛けが固定なのだけはどうしても許せなくて、ランバーサポートタイプのフル機能モデルに買い替えたというアホらしい経緯がある。

コロナ禍の在宅勤務で座ってる時間が著しく長くなっているので、ポスチャーフィットに交換することにした。ランバーサポートが健在なうちに交換しとけば、売っぱらってポスチャーフィットキット費用の足しにできるという目論見もあった。

検索するとキットを個人輸入して交換する事例がいくつも出てくるが、古めの情報しかないので、最近のポスチャーフィットキット事情としてまとめておく。

2021年3月現在、ポスチャーフィットキットの入手方法は、転送サービスを使った個人輸入する方法しかなさげ。以前は国内の業者が並行輸入したものを販売していたようだが、軒並み在庫切れとなっている。

キットは現行品で、海外ではハーマンミラー公式直販でも売っているものの、日本から買うのは無理っぽい。クレカの支払い情報入力で弾かれる。現地のクレカしか使えないっぽい？PayPalも対応してることになっているが、どう頑張ってもクレカ払いしか選べず完全なる無駄足に終わった。会員登録までしたのに！

となると再販業者（普通の販売店）からの購入となるが、よさげな販売店が見当たらなかった（信用できるか不明、日本に送ってくれない、送料が高いなど）。幸いAmazon.comマケプレで取扱があるので、そこで買うのがお手軽かつ一定の安全性も担保されててよさそう。

日本に送ってくれるマケプレ業者は少ないため、基本的には転送サービスを使うことになる。直送してくれるところでも、転送サービスを使った方が送料が安上がりだったりする。

転送サービス業者選定のポイントは、オレゴン州の倉庫を使えるかどうか。

アメリカでは州によって消費税（売上税）がまちまちで、最大10%ほどとなる。そんな中、オレゴン州は0%なのでオレゴン以外を使う理由がない。消費税がかかる州の倉庫、たいていサンフランシスコやカリフォルニアの倉庫だけど、日本までの送料が少し安かったり、配送時間が短かったりというメリットがあるにはある。まぁ、目先の金の方が大事なのさ～。

そんなわけで、今回はスピアネットを使った。使ったことのあるGooppingを使おうとしたけど、今はShipitoに吸収され肝心のオレゴンの倉庫が月額会員じゃないと使えなくなったようなので、お役御免。

• FreeBSD 12.2-RELEASE

FreeBSD 8時代のいにしえのRoot on ZFSなデータセット構成と、現在のBoot Environmentな構成を下表にまとめる。

• プロパティの凡例
  • (L) … SOURCEがlocal（自ファイルシステムで明示的に設定された値）
  • (i) … SOURCEがinherited from … （親ファイルシステムから継承した値）
  • 無印 … SOURCEがdefault
  • “従来のRoot on ZFS構成”の方は省略
• 灰色の項目は当方の独自構成

いにしえ構成とBoot Environment構成のzroot/ROOTは名前が一緒なだけで、意味するところは明確に違うので混同に注意。前者は“ルートディレクトリのルート”、後者は“Boot Environmentでルートディレクトリ(/)となるデータセット置き場”のニュアンスである。

なお、いにしえ構成でROOTを噛ませているのは「トップレベルにデータセットを1つ作り、その下に他のデータセットを置くべし」という教えに従ったため。トップレベルに直接ファイルを置いたり、複数のファイルシステムがあると、スナップショットやzfs send/redvの取り扱いが少し面倒なため、こうした言い伝えがある。

今回のBoot Environemt化にあたっては、教えを無視して公式構成に準拠することとする。

Boot Environmentでは、zroot/ROOT以下に複数のシステム用データセットが格納でき、起動スプラッシュで選択した環境がファイルシステムの/となってシステムが起動する。標準のシステムはzroot/ROOT/defaultとなる。カーネル起動後、zroot/usrやzroot/tmpなどのzroot/ROOTと同列にあるデータセットがmountpointプロパティに従いマウントされることで、OSが想定するファイルシステム構造が出来上がるという仕掛けになっている。

注意すべきはcanmountプロパティがnoのデータセットたち。FreeBSD 12.2-RELEASE時点で該当するのは、zroot/usrとzroot/varである。

子データセットのcanmountはonなのに親がoffというのは一見不思議だが、なんて事はない、親は子供のための単なる“コンテナ”としての存在に過ぎない。逆に言うと、/usrの実体は各々のBoot Environmentに存在するため、zroot/usrがマウントされると都合が悪い。下表のように、同じ/usrでもパスによって格納先のデータセットが変わってくるため、移行作業では気を付ける必要がある。

以上をふまえ、下記の手順で移行を試みる。

1. 独自データセットの解消
2. Boot Environment環境にないデータセットの解消
3. Boot Environment環境の構築
4. 既存環境とBE環境を差し替える

要はzpoolのデータセット構成をBoot Environment構成に合わせ、適切なデータセットに適切にファイルを移動すれば晴れてBE環境になる、ハズ。

Boot Environment構成になく、かつ旧Root on ZFSの公式構成にもない、自分が勝手に切り分けたデータセットを解消する。上表でいう所のzroot/ROOT/usr/includeである。

解消と大層な言葉を使ってみたものの、単にincludeがzroot/usrの1フォルダとなるようファイルをコピーするだけ。

# rsync -aX /usr/include/ /usr/include2
# diff -r /usr/include /usr/include2
# zfs destroy zroot/ROOT/usr/include
# mv /usr/include2 /usr/include

/usr/homeも独自構成ではあるが、BE環境には影響しないので特に何もしない。

Boot Environment構成にない旧Root on ZFS構成のデータセットを解消する。作業内容は独自データセットの解消と同じで、対象は次のとおり。

• zroot/ROOT/usr/ports/distfiles
• zroot/ROOT/usr/ports/packages
• zroot/ROOT/var/db
• zroot/ROOT/var/db/pkg
• zroot/ROOT/var/empty
• zroot/ROOT/var/run

稼働中のシステムで/varをこねくり回すのは怖いので、FreeBSDのインストーラのシェル（Live環境）で作業する方が安全だろう。というわけで、今後のコマンド例はLive環境を想定している。

普通にzpool importするとLive環境の/に上書きマウントされてしまうので、-Rオプションでルートを指定してマウントすべし。

# mkdir /tmp/altroot
# zpool import -R /tmp/altroot zroot
# rsync -aX ...
# zfs destroy ...

この作業を終えた時点で、zrootのデータセット構成がBoot Environemtの構成と同一になっていることが重要。

BE環境構築用のデータセットを作り、既存環境を生かしつつ移行環境の作成に挑む。

幸い旧Root on ZFS環境はzroot/ROOT以下に全てが収まっているので、BE構築をzroot/ROOT2/defaultあたりで行えば旧環境を破壊することなく実施することができる。どのデータセットがどこにマウントされているか意識しながら作業を行う必要がある。

一旦プールをエクスポートし、自動マウントはせずにインポートする。

# zpool export zroot
$ zpool import -N -R /tmp/altroot zroot

ダミーのBEデータセットを作成。

<code> # zfs create