元記事は、Linuxを「USBから起動する」のではなく、ネットワーク越しに起動する話です。しかもただのネットブートではなく、OSのルートディスク自体をネットワーク上に置くのがポイントです。
ざっくり言うと、
という流れです。
正直、最初に見ると「単語が多すぎる！」となります。ですが、役割ごとに分けて見るとかなり筋が通っています。
私はこういう構成、面倒さの代わりに“環境を壊しにくい”という強さがあるのが魅力だと思います。
著者の動機はかなりリアルです。
この「Windowsはゲーム用フロントエンドとしては使う。でも開発用OSとしてはあまり信用していない」という距離感、すごく分かります。賛否はあるにせよ、実感としてはかなり共感しやすい話です。
この手法のいいところは、ローカルの内蔵ディスク構成をいじらずに済むことです。
普通、Linuxをデュアルブートするときは、
という地味に面倒な作業がつきまといます。
でもこの記事の方式なら、ブートローダーもOSもネットワーク側に逃がせるので、ローカルのNVMeをゲームやWindows用途のまま温存できます。
ここはかなり重要です。
「Linuxを試したい。でも今のWindows環境は壊したくない」という人にとって、これはかなり筋のいい逃げ道だと思います。
著者も書いている通り、ネットワークドライブ上のDebianインストールはローカルディスクより遅いです。
とはいえ、この人の場合はOS起動後に使うモデル類をローカルNVMeや十分なRAMで扱うので、OSそのものの遅さはあまり気にしていません。
つまり、これは常用の高速OSというより、用途を絞った実験環境です。
ここは大事で、ブラウジングや日常利用をガッツリ快適にしたい人向けではないでしょう。
著者も「Firefoxでブラウズするためには使わない」と言っています。かなり正直で好感が持てます。
この記事の前提は、以下のようなものです。
つまり、サーバー1台でネットブートの中核をまとめ、ルーターは「この起動ファイルを取りに行ってね」と案内する役です。
役割分担がはっきりしていて、意外と整理されています。
まず netboot.xyz をインストールします。
netboot.xyz は、ネットワークブート時に表示するブートメニューの集合体みたいなものです。
いろいろなLinuxインストーラーやツールを、メニューから選べるようになります。
著者は単に使うだけでなく、ソースを取得してビルドしています。
理由は、実行時に都度アセットを落とす方式よりも、あらかじめ整えたほうが安定しそうだからです。
設定では、メニュー生成やチェックサム生成などを有効にし、site_name と boot_domain を自分のサーバーIPに合わせています。
さらに、いくつかのテンプレートも調整しています。
これによって、標準メニューだけでなく、カスタムiPXEメニューから自前の起動項目に飛べるようにしています。
ここ、地味ですが重要です。
「既製品をそのまま使う」のではなく、自分のネットワーク構成に合わせて少し手を入れることで、ぐっと実用的になります。
次に、Debianのインストーラー用ファイルをWebサーバーに置きます。
この記事では、
linuxinitrd.gzをDebianのnetboot配布先からダウンロードしています。
initrd は、ざっくり言うと起動初期に使う小さな仮のルート環境です。
本番OSが動く前に、まずこれで必要最低限の準備をします。
GUI付きの「GTKインストーラー」も選べるようにしていて、こちらは見た目が少し華やかです。
ただし、著者も書いている通り、特殊なGPUを使っていると相性問題があるかもしれないとのこと。ここは慎重ですね。
TFTP は、ネットワーク越しに小さな起動ファイルを配るための仕組みです。
PXEではよく使われます。
設定ファイルでは、TFTPのディレクトリやポートを指定し、ビルドした netboot.xyz のバイナリを /srv/tftp/ipxe に置いています。
ここで配っているのは主に:
netboot.xyz-undionly.kpxenetboot.xyz-snp.efinetboot.xyz.efi
です。
ざっくり言えば、古いBIOS環境でもUEFI環境でも起動できるように、複数のブートファイルを用意しているわけです。
このあたりは地味ですが、実際に使える構成にするには避けられない配慮だと思います。
次はルーター側の dnsmasq です。
dnsmasq は、DHCPの機能も持つ便利なサービスで、ネットワーク参加時に「起動ファイルはここだよ」と案内できます。
この記事では、BIOSクライアント、UEFI x86-64、iPXEクライアント をそれぞれ見分けて、適切な起動先を振り分けています。
ここがかなり面白いです。
というのも、著者は「VMはiPXEに対応していたけど、12700kの実機はそうではなかった」と書いています。
つまり、同じメニューでも機材によって事情が違うので、丁寧に分岐させているわけです。
この分岐の考え方は、ネットワーク起動をやる上でとても大事です。
一見同じ「PC」でも、BIOSなのかUEFIなのか、iPXEを理解するのかで全然違うからです。
ここで ZFS が出てきます。
ZFSは、かなり高機能なストレージシステムです。
この記事では深掘りしていませんが、著者は「ZFS is cool」とだけ軽く触れています。たしかに、ZFSはスナップショットや整合性管理が強くて、好きな人は本当に好きです。
そのZFS上に ZVOL を作っています。
ZVOL = ZFS上に作る仮想ブロックデバイス
ここで zfs create -V 32G のように、32GBの仮想ディスクを切っています。
このZVOLが、あとで iSCSI のバックストアになります。
私の感想としては、ここはかなり“技術好きの遊び心”が出ていて好きです。
普通なら素直にLVMや生ディスクを使いそうなところを、ZFSの上で仮想ディスクまで作る。ちょっと過剰だけど、それが楽しいんですよね。
ここがこの記事の山場です。
iSCSI は、ネットワーク越しに「ディスク」を見せる仕組みです。
クライアント側から見ると、まるでローカルディスクのように扱えます。
著者は targetcli を使って設定しています。やっていることはざっくり以下です。
demo_mode_write_protect=1 を設定
generate_node_acls=0 を設定
用語が多いですが、要するに
「このネットワーク上の仮想ディスクを、このPCだけが、このパスワードで使えるようにする」
という話です。
特に mutual authentication を設定しているのは、なかなかしっかりしています。
単にログインするだけでなく、クライアントとサーバーがお互いを認証するので、少し堅牢です。
こういうところを見ると、著者は単なる実験ではなく、ちゃんと壊れにくい構成を意識しているのが伝わってきます。
最後に、iSCSIで見えているディスクにDebianをインストールします。
つまり、インストーラーから見ると「普通のディスク」に見えていて、実はその正体がネットワーク上のZVOLだというわけです。
これが今回の仕掛けのキモです。
インストール後は、PCがそのiSCSIディスクから起動する形になります。
うまくいけば、ローカルのNVMeにLinuxを入れなくても、ネットワーク先のディスクからLinuxが立ち上がるわけです。
この手の構成は、単に「かっこいい」だけではありません。
以下のような価値があります。
特に最後の「再現性」は大きいです。
ローカルPCの状態に左右されにくいので、環境を整理しやすいんですよね。
もちろん、ネットワークが死んだら起動できないという弱点はあります。
でも、そこを飲み込めるなら、かなり面白い選択肢ではないでしょうか。
個人的には、これは**かなり好きなタイプの“無駄に見えて理にかなっている構成”**です。
普通の人にはおすすめしにくいです。
設定項目は多いし、PXE、TFTP、dnsmasq、iSCSI、ZFSと、登場人物が多すぎます。
でも、だからこそ「自分の環境を壊さずにLinuxを持ち歩かずに使いたい」という目的には、妙にハマっています。
とくに、WindowsアップデートでGRUBが壊れるのが嫌という発想は、経験者ほど刺さるはずです。
ネットワーク側にブートを寄せてしまうのは、かなり割り切った解決策だと思います。
