USBなし・現地作業なし。CodexとBMCでH100×2をUbuntu 26.04.1へ再構築

会社にあるGPUサーバーを、手元のMacからクリーンインストールする。インストールUSBを差しに行かず、別ディスクのデータを残したまま、OSだけを入れ替えられるのか。実際にH100を2枚搭載したサーバーで試してみました。

結果は成功です。Ubuntu 24.04の環境を退避し、Ubuntu 26.04.1 LTSを新規インストールしました。最後はログインできることだけで終わらせず、データのサンプル照合と、2枚それぞれでのCUDA計算まで確認しています。

ただし、一直線に進んだわけではありません。起動先が既存OSへ戻る、記号の入力が化ける、仮想DVDが遅い、ディスク名が変わる。この記事では、そのつまずきと対処を含めて記録します。操作と記録にはCodexを使いました。

何を消し、何を残すかを決める

対象は、使っていなかったH100×2のサーバーです。新しい計算環境を作るため、以前の環境を引き継ぐアップグレードではなく、OSを入れ直すことにしました。

OS用SSDには、現在の環境のほかに、使われていない旧ホーム領域や旧環境も残っていました。今回は「現行環境を退避すれば、旧ホーム・旧環境は消去してよい」という範囲を先に確定しています。Codexに作業を依頼する場合も、この判断まで曖昧にして任せないことが大切でした。

SSHだけでは、消している最中のOSを操作できない

OSが動いている間はSSHを使えます。しかし、再起動してインストーラーを動かし、既存OSを消している最中は、そのSSH接続を頼りにはできません。

そこで使ったのがBMCです。サーバー本体の管理コントローラーを通じて、OSとは別の経路から画面を見たり、キーを送ったり、電源を操作したりできます。今回は実際にリモートコンソールと仮想メディアを利用できることを確認してから進めました。BMCがあるという仕様だけで判断せず、接続・認証・機能の利用まで試しておくのがポイントです。

手元のMacから会社のA100サーバーへ入り、そこを経由してH100とBMCへ接続しました。A100は踏み台だけでなく、現行環境のバックアップ保存先と、インストール用ファイルの配信元も兼ねています。

同じ場所にA100があることは今回の進め方に役立ちました。ただし、踏み台にGPUが必要なわけではありません。必要なのは、対象へ届くネットワーク、退避用の容量、必要なファイルを渡せる環境です。

まず現行環境を退避する

既存環境はBtrfsだったため、稼働中のルートサブボリュームを読み取り専用スナップショットにし、sendストリームを圧縮してA100へ保存しました。加えて、旧ブート領域など3つのパーティションのイメージ、GPTの先頭・末尾、ディスク構成やfstabなどの情報も残しています。

保存したファイルはSHA-256と圧縮ファイルの検査を行い、Btrfsストリームもreceive --dumpで構造を確認しました。退避データの合計は約21.8 GBでした。

ここで、確認した範囲は区別しておきます。バックアップファイルの検査は済ませましたが、実機へ戻して起動する完全な復元試験は行っていません。また、別ディスクの約1.6 TiBのデータ全体を複製したわけでもありません。今回はそのディスクをインストール対象から外して保持する方針です。

最も気を使ったのは、ディスクの取り違え

実際に、起動する環境が変わるとデバイス名も変わりました。

もし「いつもsdaだから」と決めていたら、想定と違うディスクを選ぶ可能性があります。今回は容量と製造番号でOS用SSDを照合し、データ側はファイルシステムのUUIDも確認しました。保持するディスクは、インストーラーが動いている間、ブロックデバイスを読み取り専用にしています。

構成を確認するコマンドとしては、次のようなものを使えます。ここに示すのは確認用であり、ディスクを消去するコマンドではありません。

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,UUID,MOUNTPOINTS,RO
findmnt /data
sudo blkid

USBの代わりに、BMCからISOを接続する

インストールメディアは、Ubuntu公式のServer ISOです。SHA-256と署名を確認したうえで、BMCのリモートコンソールから仮想メディアとして接続しました。サーバーには仮想DVDとして見えるため、物理USBを挿さなくてもインストーラーを起動できます。

今回の操作の流れは、仮想メディアでISOを接続し、次回の起動先を指定して再起動し、リモートコンソールでUbuntuの起動画面を確認する、というものです。ただし、ISOの接続と、そのISOから実際に起動できることは別の確認でした。

つまずき1：CD起動を選んだのに、古いOSへ戻る

最初に一般的なCD起動の指定をしたときは、既存OSへ戻ってしまいました。今回は、仮想CD-ROMのUEFIデバイスパスを明示した起動指定に切り替えることで、Ubuntuの起動画面へ進めました。BMCやファームウェアによって項目や挙動は変わるので、機種をまたいで同じ指定が通るとは限りません。

つまずき2：URLのコロンがセミコロンに化ける

GRUBの起動設定へ自動インストール用のURLを入力したところ、リモートコンソール経由のキー入力で、コロンがセミコロンに変わりました。画面には「コマンドが見つからない」というエラーが出ています。

そこで、起動前の画面に長い文字列を打ち続ける方法をやめ、ライブ環境が起動してから正しい設定ファイルを渡す方法へ切り替えました。リモートKVMでは、送信したつもりの文字と実際に画面へ入った文字を照合する必要がある、と実感した場面です。

つまずき3：仮想DVDの読み出しが遅い

BMC経由の読み出しは、今回の経路では約0.6 MB/sと遅くなっていました。ライブ環境にSSHで入れるようになってから、A100から同じLANを通して、検証済みのISOをH100のRAMへ転送しました。

約2.93 GBの転送とハッシュ照合は、実測で25.295秒。RAM上のISOを読み取り専用でマウントし、インストール用ファイルの読み出しに使うことで、進行を改善できました。これはOSの全インストール時間ではなく、ISOの転送と照合にかかった時間です。

一方で、実行中のライブOSは元の仮想DVDも参照していました。そのため、RAMへコピーした段階ですぐにDVDを取り外さず、インストーラーの終了まで接続を維持しています。

自動インストールも、消去の前に止めて確認する

インストールには、Ubuntu Serverのautoinstallを利用しました。今回はストレージを初期化する前の段階で待機させ、次の3点を確認してから解除しています。

1. 現行環境の退避が終わり、保存ファイルの検査が済んでいる。
2. 初期化する対象が、容量・製造番号で照合した480 GBのOS用SSDである。
3. 保持するデータディスクが対象から外れ、読み取り専用になっている。

待機を解除すると、OS用SSDのパーティションを作り直し、Ubuntuを展開します。新しいルート領域はext4とし、EFIの起動領域も作成しました。続いてカーネル、起動設定、SSH、セキュリティ更新の適用を進めています。

この段階の映像はBMCで録画しました。YouTube版では、待ち時間を短縮しつつ、実際のインストールログが進む様子を使っています。

「インストール完了」の後にも点検する

起動前の点検では、インストール時にだけ使うautoinstallやNoCloud関連の引数が、新しいGRUBへ引き継がれていることが分かりました。不要な指定を取り除き、起動設定を再生成しています。

インストーラーが正常終了して電源が落ちたことを確認し、仮想DVDを解除。その後に電源を入れ直して、SSDからUbuntu 26.04.1 LTSを起動しました。カーネルは7.0.0-38-genericです。

初回起動ではSSHホスト鍵が生成し直され、以前の鍵と違うという警告も出ました。鍵のチェックを無効にするのではなく、BMCコンソールに出たフィンガープリントと照合してから新しい鍵で接続しています。SSHログインとsudoの動作も確認しました。

データ保持とH100の計算まで確認

データ用ディスクは、元と同じUUIDのXFSとして/dataへマウントできました。事前に採取した24ファイルのSHA-256を照合すると、すべて一致しています。これはサンプルの一致を確かめた結果であり、約1.6 TiBの全ファイルを検査した結果ではありません。

GPUドライバーには、Ubuntuのサーバー向けNVIDIAパッケージを使いました。今回選ばれたのは595-server-open、バージョンは595.91.07です。確認用のユーティリティを入れ、再起動後にnvidia-smiでH100が2枚とも認識されることを確認しました。

計算試験では、CUDA Driver APIから各GPUでベクトル加算を実行し、CPU側で求めた値と比べました。2枚とも最大絶対誤差は0です。短い基本動作の試験なので、長時間の安定性やアプリケーションの性能を示すものではありません。

CUDA Toolkit、学習フレームワーク、Slurmなどの環境を一式戻したわけではありません。まずクリーンなOSとドライバー、GPUの基本動作までを確認した段階です。

録画ファイルが172本になった理由

作業中、MacのダウンロードにAVIが延々と増えていきました。今回のBMC録画は、約40 MBごとのファイルへ自動分割する動作だったためです。録画を止めたあと、本数が増えないことも確認しました。

最初の録画が51本、次が121本。合計172本、約6.97 GBになりました。2回の録画は連番がそれぞれ始まり直すため、単純にpart番号だけで混ぜず、録画セッションごとにまとめています。元のAVIには音声がなく、YouTube版では後からナレーションと字幕を加えました。

GPUの計算試験は録画停止後に実施したので、その部分は実ログと静止画を使って説明しています。公開版では接続先や鍵情報などを除き、画面の抜粋や情報整理を行った箇所も分かるようにしました。

次は、このクリーンな環境からクラスターへ

今回できたのは、インストールUSBも現地作業も使わずに、H100サーバーを新しいOSへ入れ替えることです。支えになったのは、OSが止まっても使えるBMCの経路、現行環境の退避、ディスクの識別、そして作業後の検証でした。

Codexには操作や調査、記録を任せながら、消去してよい範囲を明確にし、画面とログで一つずつ結果を確かめて進めました。つまずきから戻れる管理経路があることの価値を、実機で確認できた作業でもあります。

次は、この環境を使ってクラスター構築や計算環境の整備へ進む予定です。今回のように、設定したというだけで終わらせず、何が動いたかまで記録していきたいと思います。