青木 様 丸山です。内容が当初の話題から何か発散しつつあるように思いますが、、、。
>> Sun, 11 Jan 2026 17:58:57 +0900 >> Tomoaki AOKI <[email protected]> writes: >> >普通にインストールする場合、恐らくですがメモリが潤沢でない場合を >> >考慮して媒体中のファイルシステムにZFSを使うのは考え難いですし、 >On Mon, 19 Jan 2026 02:17:50 +0900 >丸山直昌 <[email protected]> wrote: >> そうかな？今時新品で売っているノートパソコンは最低でもメモリは8GB搭載さ >> れいるし、一年程前にハードオフで買った中古品lenovo X220(6,000円＋消費税） >> でも 8GB載っていましたよ(4GB DDS3メモリの中古品がハードオフで 330円で買 >> えてしまいますし)。zfsで運用して何の問題もないと思いますし、実際私がブロ >> グに書いた方法で、 32GB USB上に zfs で FreeBSD13.5amd+KDEを zfsでインス >> トールしたシステムが実用的な応答速度で動きます。 >> >> ま、これで installworld や、 release の full build ができるかどうかは知 >> りませんが。 Mon, 19 Jan 2026 20:37:46 +0900 Tomoaki AOKI <[email protected]> writes: >amd64のノートでは概ねそうと思います。 が、各種（まだサポート >されている）RISC系等やamd64のCPUであってもサイズ的にメモリ >拡張スロットを搭載できない組込用等をFreeBSDで復活させたい！と >いう場合等はその限りではないのです。 そりゃそうですね。どのようなマシンで使うのか、を考えてインストール方法は 変えないといけません。私はamd64の普通に市販されているWindowsパソコン(及 びその中古品)を想定して書いていました。そのような場合には zfs で良いでしょ う、という話が出発点。 >そういったリソースの限られた状況ではメモリも4Gやそれ以下である >こともままあり、ZFSを使うには特殊なチューニングを行う必要が出て >きますので、汎用を前提とした公式インストーラには適さないのです。 私は「汎用を前提とした公式インストーラ」の話などしていなかったのです が、、、。元々の話は私自身が、普段使っているシステム上で、他の仕事を止め ずに、bsdinstallを使ってUSBメモリスティックにシステムをインストールする 場合に遭遇したバグの話で、そのUSBメモリスティックは8GBメモリ以上を搭載し たamd64のごく普通のWindowsパソコンの起動に使うためのものです。なお、この ような bsdinstallの使い方をしたい人は私だけではないだろうと思っています。 >組込用で初めからFreeBSDベースのファームウェアを焼き込む前提の >場合は、通常、開発環境で各製品専用のイメージを作成してラインで >書き込んでしまうのでそもそもインストーラを使いません。 >更新も専用のものを新造するかfrebsd-updateをベースに加工するなり >かと。 私の守備範囲を完全に外れていますので、コメントできません。 >私の場合、ここ数回は、新しいPCに移行するときもインストーラを >使っていません。 過去の青木さんの記事でそれは知っています。「インストーラを使っていない」 だけではなく、 「bsdinstall も使っていない」ということですね。私自身も自 分用のマシンのセットアップには使っていなかったのですが、最近はブログの記 事を書くために「公式インストーラ」を何回も使って実験をしているわけです。 >・次期PCに入れる予定のメディア（2.5inchのSATAドライブだったり >NVMeのSSDだったり）をUSB接続用アダプタで接続し、 > >・現用PCでパーティショニング、ブートコード関係（UEFIの場合は > ESPにBug 207940のパッチを当てたboot1.efiをEFI\boot\bootx64.efi > としてコピー）を書き込んで、 > >・/にする予定のパーティションに現用機で生成したリリース用ディストリ > ビューション（base.txzやkernel.txz等）を適切な順番で展開し、 > >・必要な設定を行う 似たような作業手順は私もやります。ここでの肝は、releaseで配布されている インストーラーを使うには「現用システムの運用を一時的に止める」ことが必要 になるので、それは使えないということでしょう。つまり「現用システムの運用 を止めたくない」いうのはインストーラーを使わない理由にはなりますが、しか し bsdinstallを忌避する理由にはならないと思うのです。一連の手順中のzfs poolの作成とリリース用ディストリビューション (base.txz,kernel.txz,lib32.txz)の展開のところでbsdinstallを使って手間を 省けると楽なのだがなー、と常々感じています。 >流れ...でしたが、直近は現用PCが既にRoot on ZFS、かつGPUも世代は >違えどnvidia GPU同士だったこともあり、poolの構成を済ませたところで >zfs send / zfs recvでスナップショットを送り込んでしまい、最低限の >設定書き換えを行ってexportするだけで済ませてしまいました。 「公式インストーラー」が作成するzfs poolと同じ構成・レイアウトのzpoolを 作成するには zpool create を一回、zfs create を13回、その他chmod などの コマンドで、合計23行の shell scriptが必要になります。それがzfs send / zfs recv を使ってやると大幅に簡単になることは知っています。で、実際にやっ たこともありますが、どうも好きになれません。やはりbsdinstallで面倒を見て 欲しい。ufsのパーティション指定のインストールのように。 >このやり方ではそもそも「デフォルトのプール名」などありませんので >自分で競合しないプール名やパーティションラベル等を設定します。 > >念のため、ZFSのpoolを作成する以前のパーティショニングの段階で >全てパーティションラベルを設定し、それを使ってZFSのpoolや >/etc/fstabを設定し、NVMe SSDをUSBアダプタで繋いで作業する >場合に作成時は/dev/da*だったものが運用時に/dev/nda*に化けて >いても問題が出ないようにしています。 うーん、何かようわからんのですが、私は石塚さんに教えて頂いたrefindをboot selectorに使っているので、EFI/Boot/REFIND.CONFに menuentry "FreeBSD13.5" { loader /EFI/freebsd/loadr135.efi options "rootdev=zfs:fbsd135pc06/ROOT/default: console=efi,comconsole" } のように書いておけば良いわけです(この件については以前野中さん、青木さん、 石塚さんに教えて頂きました)。ですからzfs partitionのパーティションラベル は不要なのです。swap partition 等はラベル付けておきますけど。あと /dev/ufs/HD06 /usr/home/maruyama/HD ufs rw,noatime,late 0 2 というのもあって、これでどの zfs で起動しても ~/HD は同じにしてあります。 もう一つここに書いておきますと、ブログに書いたUNIX未経験者向けインストー ルガイドでRoot on ZFS を採用した理由は、インストール作業中に da1 であっ たドライブにufsでシステムを作ると、インストール作業を終わってインストー ラーUSBを引き抜き、単独で起動しようとするとda0になってしまって、ブートで きない(/ がマウントできない)ということになるからです。ここで「エディター を使って single user modeで /etc/fstab を直せ」というのはUNIX未経験者に は無理な相談です。Root on ZFSにしておくとda1がda0に変わっても bootします。 /dev/da1p3 none swap sw 0 0 というのはエラーになりますが、ブートします。 >> なお私はアップグレードというのは同じOS version(例えば 13.5amdの範囲内)の >> 中でしかやりません。minor verionの変更であってもアップグレードする場合に >> はブログの「FreeBSD13.2への移行(纏め)」 >> https://amogha.livedoor.blog/archives/23328974.html >> に書いた「遷宮方式」を使います。家庭菜園的には ada0 に 500GBもあればこの >> 方法で充分にやって行けます。 > >この遷宮方式、計画にない停止が許されない、しかも移行後は >新環境が完全に動作することを保証しなければならないメイン >フレームでは常識のようです。 それは初耳。有難うございました。 >異なるのは、（私自身はオペレーションに関わる機会がないので >運用している方からの伝聞ですが）メインフレームだと当たり前の >ように複数のOSを同時に稼働できるので新環境の動作検証が完了した >ところで本番環境からのマイグレーションを行い、同期が取れて >切り換え可能になったところで新環境に切り替え、万一想定外の >不具合が出た場合、直ちに実績のある旧環境に切り戻すそうです。 > >＃ PPARとかLPARとか検索すると色々情報が出てくるようです。 >＃ PCでいうファームウェアのレベルでそういった機能を持って >＃ いるとのこと（話を聞いた方は「モニタ」と呼んでいました）。 >＃ UEFIも見倣ってくれるといいんですが。 >＃ 各OSにはUEFI Runtime Service経由でのみデバイスへのアクセスを >＃ 許し、UEFIで自在にリソース配分を制御できるようになっていれば >＃ forums等で苦悶の声が聞こえてくるpassthroughなぞ考える意味すら >＃ 無くなってくれるのですが。 -------- 丸山 直昌 まるやま なおまさ メールアドレス： [email protected]
