バラバラなUSBメモリの墓場
デスクの上を見てみてください。もし私と同じようなタイプなら、ラベルのないSanDiskのCruzerが数本転がっているのではないでしょうか。
一つは古いUbuntu 22.04、もう一つは壊れたProxmoxのISO、そして三つ目は先週役に立たなかったWindowsの回復ドライブでしょう。HomeLabを運用しているなら、このフラストレーションを経験しているはずです。新しい物理ノードやテスト環境を作るたびに、メモリを探し、ISOをダウンロードし、BalenaEtcherで書き込み、ハードウェアが認識してくれるのを祈る……。そんな退屈な儀式を繰り返していませんか。
単一のPCならこれでもいいですが、クラスタをデプロイするとなると大きなボトルネックになります dream。中古のDell OptiPlex 7050を4台追加した際、起動メディアの準備だけで45分も費やしていることに気づきました。サーバーの設定よりも、引き出しから「まともなUSBメモリ」を探す時間の方が長かったのです。
ローカルブートに潜む隠れたコスト
物理メディアは本質的に分散管理されており、すぐに時代遅れになります。新しいマイナーアップデートが出た瞬間、苦労して書き込んだUSBメモリは実質的にゴミ同然です。ポートの故障という物理的なリスクもありますし、USB 2.0の480Mbpsという低速さで4GBのイメージを読み込むのは永遠のように感じられます。
自宅に1Gbpsや10Gbpsの高速ネットワークがあるのに、未だに1998年のようにビットをポケットに入れて持ち運んでいます。本当の問題は、中央管理されたデプロイハブがないことです。ハードウェアは電源を入れた瞬間に、一つの更新されたOSライブラリにアクセスできるべきです。
選択肢の比較：USB vs. カスタムPXE vs. Netboot.xyz
歴史的に、ネットワークブート（PXE: Preboot Execution Environment）環境の構築はゼロからサーバーを作ることを意味していました。これはそれ自体が一つのプロジェクトでした。TFTPの設定に格闘し、Webサーバーでイメージをホストし、複雑なkickstartやpreseedファイルを手動で管理しなければなりませんでした。
- 手動USB: 導入のハードルは低いが、メンテナンスが大変でハードウェア故障に弱い。
- カスタムPXEサーバー: 柔軟性は最大だが、DHCPオプションの深い知識と絶え間ない手動更新が必要。
- Netboot.xyz: ちょうどいい落としどころ。コミュニティが管理するディレクトリから、数十種類のOSをクラウドまたはローカルキャッシュから直接ブートできます。
このワークフローをマスターすれば世界が変わります。一度ネットワークベースのデプロイに切り替えれば、二度とUSBメモリに手を伸ばすことはないでしょう。Netboot.xyzは軽量なブートローダーとして機能し、ハードウェアに「Netflixスタイル」のメニューを提供します。
DockerによるNetboot.xyzのデプロイ
Netboot.xyzを動かす最も効率的な方法はDockerです。ホストOSを汚さず、バージョン更新もコマンド一つで完了します。設定をドキュメント化し再現性を高めるため、Docker Composeを使用します。
まず、サービス専用のディレクトリを作成します：
mkdir ~/netbootxyz && cd ~/netbootxyz
nano docker-compose.ymlファイルに以下の設定を貼り付けてください：
services:
netbootxyz:
image: ghcr.io/netbootxyz/netbootxyz
container_name: netbootxyz
environment:
- MENU_VERSION=2.0.76
- NGINX_PORT=80
volumes:
- ./config:/config
- ./assets:/assets
ports:
- 3000:3000 # Webダッシュボード
- 69:69/udp # TFTPサービス
- 8080:80 # ローカルアセットサーバー
restart: unless-stoppedコンテナをデプロイします：
docker compose up -dこれでサーバーが立ち上がりました。 http://<your-ip>:3000 にアクセスしてダッシュボードを開きましょう。このUIでブートメニューを管理し、LAN内でのインストールを高速化するためにアセットを「ローカライズ」します。
肝心な設定：DHCPの設定
コンテナを動かすのは簡単です。本当のマジックは、起動時にこのサーバーを探すようコンピュータに指示したときに起こります。これには、DHCPサーバー（ルーターやPi-holeなど）で2つの特定の調整が必要です。
- Next Server (Option 66): DockerホストのIPアドレス（例: 192.168.1.50）。
- Bootfile Name (Option 67): レガシーBIOSの場合は
netboot.xyz.kpxe、最近のUEFIマシンの場合はnetboot.xyz.efiを使用します。
Pi-hole (dnsmasq) の設定
Pi-holeをDHCPとして使用している場合、カスタム設定ファイルを作成することでPXEサポートを追加できます：
sudo nano /etc/dnsmasq.d/07-pxe.confサーバーの実IPに置き換えて、以下の行を追加してください：
dhcp-boot=netboot.xyz.kpxe,,192.168.1.50
dhcp-match=set:efi64,option:client-arch,7
dhcp-match=set:efi64,option:client-arch,9
dhcp-boot=tag:efi64,netboot.xyz.efi,,192.168.1.50設定を反映するために再起動します：
pihole restartdns恩恵：爆速ネットワークデプロイ
いよいよお楽しみの時間です。マシンをネットワークに接続し、F12キー（またはブートメニューを開くキー）を連打して「Network Boot」を選択します。
マシンはIPを取得し、TFTP経由でブートローダーを読み込み、青いメニュー画面が表示されます。最近、私はこれを使って3台の古いラップトップを初期化し、k3sクラスタに作り変えました。メモリを差し替える代わりに、3台同時に起動して「Ubuntu 24.04」を選択し、ネットワーク越しにインストーラーを走らせました。ログインプロンプトが出るまで、12分もかかりませんでした。
ローカルアセットによるインターネット遅延の解消
光回線なら2GBのLive ISOをインターネットから直接ブートしても問題ありませんが、低速な回線では苦痛です。Netboot.xyzは「Local Assets」でこれを解決します。Web UIの Local Assets タブに移動してください。よく使うディストリビューションを、サーバーの /assets フォルダに事前ダウンロードしておくことができます。
これにより、15分の待ち時間がローカルネットワーク経由の30秒のバースト転送に変わります。頻繁に異なるディストリビューションを試したり、新しいパーツでMemTest86を実行したりする人にとっては、まさにゲームチェンジャーです。
HomeLabをデータセンターのように扱う
Netboot.xyzへの切り替えは、単なる利便性のためだけではありません。考え方をシフトさせるためのものです。ブート環境を中央集約化することで摩擦をなくし、常に最新かつ安全なOSバージョンを使用できるようになります。セットアップには20分ほどかかりますが、今後1年で節約できる時間は計り知れません. USBメモリの引き出しは、ついに現役引退です。
