LinuxでGPTを作ると、First usable LBAとして512バイトセクタドライブで2048、4kセクタドライブで256が設定されることに気づいた。これだと、パーティショニングツールからはGPTとして1MiBが確保されたかのように見える。
GPTの実際のサイズは16.5KiBであるから、本来は33セクタ@512Bまたは5セクタ@4KiBで事足りる。FreeBSDの39セクタ@512Bに慣れた身からすると、無駄とも思えるサイズだ。
理由を調べてみると、どうもWindowsとの互換性のためっぽい。
WindowsではVistaとWindows Server 2008から、パーティションの先頭を1MiBアライメントで揃えるようになったそうだ。Linuxはこれに追従したとのこと。1MiBアライメントなら、512バイトと4kBの両方の倍数なので所謂AFTアライメント問題が解消でき、将来、より大きなセクタサイズが登場した時に対応できる可能性も高まる。
言われてみれば納得の理由だ。逆にFreeBSDが20KiBしか確保しないことが不安になってくる…。パーティション追加時にgpart create -a 1Mで1MiB境界に揃えてやればいいんだけではあるが、これだとパーティション一覧に“未使用領域”として計上されてしまうのが、ちょっとカッコ悪い。
どうでもいいけど調査の過程で、今更ながらCHSやらセクター63やらシリンダ境界規定やらを調べてしまった。
（2021-01-16 追記）
Linuxのfdiskで切ったパーティションをFreeBSDで見てみた。
> gpart show
=> 6 234423115 nvd0 GPT (894G)
6 131072 1 efi (512M)
131078 26214400 2 freebsd-zfs (100G)
26345478 208077643 - free - (794G)
=> 256 468843345 nvd1 GPT (1.7T)
256 131072 1 efi (512M)
131328 26214400 2 freebsd-zfs (100G)
26345728 375914496 3 !6a898cc3-1dd2-11b2-99a6-080020736631 (1.4T)
402260224 13107200 4 !6a898cc3-1dd2-11b2-99a6-080020736631 (50G)
415367424 53476177 - free - (204G)
nvd0がFreeBSDのgpart、nvd1がLinuxのfdiskで作成したもので、どちらも4kセクタである。
FreeBSDのgpartもFirst usable LBAをちゃんと見ているようで、nvd1のESPの開始セクタ256セクタ＝1MiB地点を正しく認識している。
将来のことを考えると、GPTを作るところまではLinuxまたはWindowsでやった方がいいかもしれないなぁ。
FreeBSD 12.0-RELEASEあたりから、UEFIのブートローダとして従来のboot1.efiに代わりloader.efiが使われるようになった。
どちらもZFSまたはUFSからシステムを起動する役割を持つが、boot1.efiは複数のストレージからファイルシステムを探すのに対し、loader.efiは自身が読み込まれたストレージのみが対象となる。簡単に言えば、loader.efiだと別HDDのFreeBSDシステムを起動できないというわけ。まぁ、ブートローダのプロンプトで手動で起動デバイスを指定してやれば出来るんだけど、毎度行うのは現実的ではないよね。
どうにか自動化できないかと各種文献あさりとGooglingをしてみるも、それらしい情報はなく…。仕方なくソースコードを眺めてみると、loader.envでrootdev変数を指定してやれば行けそうと分かった。
loader.efiにせよboot1.efiにせよ、最終的に起動対象はcurrdev変数の値が使われるが、loader.efiの場合rootdev変数の値が問答無用でcurrdevとして採用される。
でもって、rootdevの設定はEFIシステムパーティションの/efi/freebsd/loader.envファイルで行う。これは比較的最近作られた機能で、12.2-RELEASEから使えるようだ。
同ファイルに以下の一行を追加。ルートディレクトリとなるファイルシステムを指定する。UFSならdisk0p1という具合。末尾のコロンは誤字じゃないのでござる。
rootdev=zfs:zroot/ROOT/default:
2021-01-09現在、これらはドキュメント化されてないので、将来変わるかもしれないし動作の保証も致しかねる。
ま、こんな面倒なことしなくても、従来どおりboot1.efi使えばいいんだけどね！
UEFI環境でのFreeBSD (x64)のブートは、下表の手順で行われるとされている。manにも書かれている由緒正しい手順だ。
ファームウェア(UEFI)がEFIシステムパーティションのBOOTX64.EFIを起動し、それがboot1.efiを起動し、さらにloader.efiに処理が移り、最終的にカーネルが立ち上がる流れとなっている。スタンドアローンなFreeBSD環境では、boot1.efiがBOOTX64.EFIとしてコピーされるので、実際はBOOTX64.EFI→loader.efi→カーネルの順で起動、、、ということになっている。
言葉を濁してるのは、まぁお察しのとおり、manの説明と現状の実装が異なってるから。どうやらFreeBSD 12.0-RELEASEあたりで、BOOTX64.EFIとしてloader.efiが使われるようになったらしい（当該コミット）。この辺は現在絶賛過渡期のようで、ESP生成まわりを大きく作り変えたパッチも存在している。
試しにFreeBSD 12.2-RELEASEのインストーラが作ったESPをマウントし、BOOTX64.EFIとloader.efiのハッシュを比較すると見事に同じということが分かる。
というわけで、現実はファーストステージをすっ飛ばし、ファイナルステージブートローダがいきなり動き出す。
これでも大抵の環境では問題ない一方、現状、loader.efiは別ディスクのFreeBSDパーティションの探索を行わないようなので、そのようなストレージ構成だとFreeBSDのブートができない。こいつぁ困ったぜ。
回避策としては、手動でBOOTX64.EFIをboot1.efiにするか、あるいはloader.efiのままプロンプトでcurrdevを手動で指定し、zfs.koをカーネルを手動で読み込んでやればいい。前者の方が明らかに簡単ですな。
loader.efiのソースを見てたら、まだmanに載ってない方法が使えそうな気がするので、後日試す予定。
本日、ついにOpenZFS 2.0がリリースされた！！
リリースノート：Release OpenZFS 2.0.0 · openzfs/zfs · GitHub
Today we released OpenZFS 2.0, based on the unified code for Linux and FreeBSD. New features include sequential resilver, persistent L2ARC, zstd compression, and lots of performance improvements! https://t.co/SOHgzMln94
— OpenZFS (@OpenZFS) November 30, 2020
ZFS環境的には、なんといってもLinuxとFreeBSD向けの実装が統合され、1つのソースツリーからビルドされるようになったのが大きい。実態としては、以前から書いてきたとおり、ZFS on LinuxプロジェクトがOpenZFSプロジェクトとなり、FreeBSD向けの修正が行われたという感じで、“統合”って感じではないんだけど、いずれにせよZFSを取り巻く環境は今後ますます発展していくことだろう。
機能面では、永続的L2ARCと圧縮アルゴリズムとしてZStandardが追加されたのが大きいかな。
これを書いている時点で、PortsのOpenZFSの方はまだ更新されてないが、遅かれ早かれ2.0になると思われる。FreeBSDのベースシステムのZFS実装が置き換わる具体的な時期は不明だが、当初の計画では13.0-RELEASEで置き換わることになってたはず。こちらも無事に進んでくれることを祈りたい。
FreeBSD 12.1-RELEASEのvirtioドライバは何かしら不具合があるようだ。仮想環境のゲストとして動かした際に、virtio経由のデバイスが認識されなかったり正しく動かなかったりする模様。もしかすると、12.0-RELEASEや11.3でも同様かも。
このところProxmox VEにお熱で、自宅のFreeBSDサーバをP2Vすべく調査や実験を行っている。P2Vと言ってもPCIパススルーやRaw Device Mappingなどを使い、本来の仮想化とは少々毛色が違うのだが、この構成にしとけばいつでもV2P出来るというメリットがある。
そんなわけで、起動ディスクのNVMe SSDをPCIパススルーし、VMを起動して無事FreeBSDの起動シーケンスが流れてktkrと思ってたら、忌まわしき「Mounting from zfs:zroot/ROOT failed with error 5.」で止まってしまった。
ZFSでこのエラーになってしまったら、ここから復旧できる見込みはまずない。
仕方ないのでProxmoxやVMの設定、KVMのパススルーまわりのあれこれの見直し、FreeBSD側の/boot/loader.confのチェックにzpool.cacheの再生成など、知る限りのあらゆることを試しても症状は変わらず。
起動メッセージをよーく確認すると「ptnetmap-memdev0: cannot map I/O space」「device_attach: ptnetmap-memdev0 attach returned 6」がチラホラ出ていた。
それらしい単語でググるとVirtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTSがヒットした。試したVMは確かにQ35で作ってるし、自分と同じくルートプールが見つからなくて起動できない報告もあるし、このバグを踏んだか？
スレを読んでも修正されたんだかされてないんだか分らなかったが、ふと、先行実験でパススルーしたNVMe SSDにインストールした12.2-RELEASEは問題なく起動してたのを思い出した。それならばってことで、いったん通常環境でFreeBSDを起動し、12.2-RELEASEに更新。その後、改めてVMの方で試したら何事もなかったかのように動いた。マジかよ…(ヽ'ω`)
