Menu
Debian + Proxmox VE OS自動セットアップ。BMC VirtualMedia経由でpreseedインストール、PVEインストールまでを実行する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
別の tmux ペインで動いている Claude Code インスタンスを、このセッションから tmux send-keys / capture-pane で駆動するオーケストレーション。プランモード投入 → プラン再点検 (1 回目の検証) → ユーザ承認ゲート → auto mode 実装 → レポート未記載追記 → レポート矛盾再チェック (2 回目の検証) の定型フロー。長時間タスクをもう 1 体の claude に「ダブルチェック付きで」実行させ、要所だけ自分が監督したいときに使う。
PXE/netboot 経由で Debian + HW RAID10 を自動インストール (OpenWrt ローカル TFTP + embed ipxe.efi + IPv4 リテラル mirror)。BMC USB redirector が累積劣化した機種 (TX1320 M3 等) や、 cross-site 拠点の install に使う。phase 19 で training-tx1320 で完遂、 物理操作なしで自力 SSH まで到達。
Fujitsu iRMC S4 (TX1320 M3 等) の電源・BIOS・RAID 操作 + BIOS 設定リファレンス。Redfish (HTTPS + SECLEVEL=0) 経由の電源/ブート操作 + iRMC Web UI/KVM 経由の手動 BIOS/RAID 操作手順 + 全 BIOS 設定項目の網羅リファレンス (bios/)。training-tx1320 対応。
Supermicro X11DPU/X10DRT-P BIOS Setup 操作。KVM スクリーンショット + キーストロークで BIOS メニューを操作する。BIOS 設定変更、確認、保存を行う。4-6号機 + 10号機対応。
iDRAC7 基本操作。SSH 経由で racadm コマンドを実行し、サーバ管理を行う。
LINSTOR/DRBD ノードの離脱・復帰操作。障害シミュレーション、回復、正常離脱、再参加を行う。
| name | os-setup |
| description | Debian + Proxmox VE OS自動セットアップ。BMC VirtualMedia経由でpreseedインストール、PVEインストールまでを実行する。 |
| argument-hint | <config_file> |
Debian + Proxmox VE のインストールを BMC VirtualMedia 経由で自動実行する。
config/server4.yml, config/server5.yml）
config/os-setup.example.yml をコピーして config/server<N>.yml として編集reference.md を参照irmc-bios-raid skill の raid create-r10 経路 (scripts/tx1320-raid10-orchestrate.sh apply config/training_tx1320.yml) で RAID10 VD を作成しておく。 RAID 作成 + Debian install を 1 ISO で完結する設計なので、 os-setup スキルとは独立して実行可能 (現状 iRMC SMB attach が blocker、 詳細→ irmc-bios-raid SKILL.md)| スクリプト | 用途 |
|---|---|
./scripts/bmc-session.sh | BMC 認証・CSRF トークン (Supermicro) |
./scripts/bmc-virtualmedia.sh | VirtualMedia 操作 (Supermicro) |
./scripts/bmc-power.sh | Redfish 電源制御 + POST code 取得 (Supermicro) |
./scripts/bmc-kvm.sh | BMC KVM スクリーンショット (Supermicro) |
./scripts/idrac-virtualmedia.sh | VirtualMedia + Boot 操作 (iDRAC) |
./scripts/os-setup-phase.sh | フェーズ状態管理 |
./scripts/generate-preseed.sh | preseed 生成 |
./scripts/remaster-debian-iso.sh | ISO リマスター |
./scripts/pve-setup-remote.sh | PVE インストール（リモート実行） |
./scripts/pre-pve-setup.sh | DHCP + apt セットアップ（リモート実行、R320 等） |
./scripts/ssh-wait.sh | SSH 再接続ポーリング |
./scripts/sol-monitor.py | SOL 経由インストール監視 (自動再接続対応) |
./scripts/sol-login.py | SOL 経由ログイン・コマンド実行 |
./scripts/bmc-kvm-screenshot.py | BMC KVM スクリーンショット (Supermicro) |
config の bmc_type フィールドでプラットフォームを判別する。
| 操作 | Supermicro (bmc_type: supermicro) | iDRAC (bmc_type: idrac) | iRMC S4 (bmc_type: irmc、 training-tx1320) |
|---|---|---|---|
| VirtualMedia マウント | bmc-session.sh + bmc-virtualmedia.sh | idrac-virtualmedia.sh mount | irmc-virtualmedia.sh --share-type=NFS config + connect-cd + mount |
| VirtualMedia アンマウント | bmc-virtualmedia.sh umount | idrac-virtualmedia.sh umount | irmc-virtualmedia.sh disconnect-cd |
| Boot 設定 | bmc-power.sh boot-next (UefiBootNext) | idrac-virtualmedia.sh boot-once (racadm legacy) | bmc-power.sh boot-override Cd UEFI (BMC_BOOT_OVERRIDE_NO_DISABLED=1) |
| Boot リセット | bmc-power.sh boot-override-reset | idrac-virtualmedia.sh boot-reset | (Once 消費で自動 reset) |
| POST code 監視 | bmc-power.sh postcode | N/A (SOL / VNC で代替) | N/A (SOL + KVM locator screenshot) |
| KVM スクリーンショット | bmc-kvm.sh screenshot | idrac-kvm-screenshot.py (VNC primary + capconsole fallback) | scripts/irmc-kvm-interact.py screenshot --capture-mode=locator (legacy canvas mode は WebGL 黒画 artifact のため禁止) |
| SOL serial unit | ttyS1 (COM2, serial_unit: 1) | ttyS0 (COM1, serial_unit: 0) | ttyS0 (serial_unit: 0) |
| pre-pve-setup | 不要 (内部 mgmt + 外部 DHCP は legacy bridge で同居) | 必要 (pre-pve-setup.sh) | Phase 19 で完遂 (PXE pivot、 → .claude/skills/pxe-deploy/) |
🎯 iRMC S4 (TX1320) KVM screenshot の落とし穴: legacy
scripts/irmc-kvm-screenshot.py(canvas mode 固定) は WebGLpreserveDrawingBuffer:falseで黒画 artifact (全 PNG 11857 B 完全同 sha256) を出す。 2026-05-22 Phase 3 で「VGA 全黒」誤判定を起こした (Phase 4 で訂正)。 必ずscripts/irmc-kvm-interact.py screenshot --capture-mode=locator(default mode) を使うこと。 detail →.claude/skills/irmc-bios-raid/SKILL.mdの Playwright KVM 解決セクション参照。
VLAN trunk 環境 (10号機の例、別拠点): host LAN が 1本の VLAN trunk (内部 mgmt + 外部 DHCP がタグ付き) で来る場合、
config/serverN.ymlに 以下を追加すれば自動で対応される。フィールドが無い 4-9号機は従来動作。vlan_iface: eno1 # trunk 物理 NIC (Phase 0 で実測) internet_vlan_id: 1120 # DHCP/インターネット側 internal_vlan_id: 1083 # 10.0.0.0/8 内部 mgmt 側 static_iface: vmbr0 # 静的 IP は vmbr0 上に乗る dhcp_iface: vmbr1 # DHCP は vmbr1 上に乗る
generate-preseed.shが early_command で 8021q + VLAN サブを作り、 late_command で 8021q 永続化と VLAN サブインタフェース定義を target に書き込むpve-bridge-setup.shを Phase 8 で--vlan-iface系フラグ付きで呼ぶ:pve-bridge-setup.sh --vlan-iface eno1 --internet-vlan-id 1120 --internal-vlan-id 1083 --static-ip 10.10.10.210/8pre-pve-setup.sh --dhcp-iface eno1.1120で動作 (GW 動的検出済み)- 拠点固有 GW (4-9号機の
192.168.39.1とは違う値) も DHCP 経由で動的取得される
YQ="${PROJECT_DIR}/bin/yq"
CONFIG="config/server4.yml" # 引数で指定されたパス
BMC_TYPE=$("$YQ" '.bmc_type' "$CONFIG")
BMC_IP=$("$YQ" '.bmc_ip' "$CONFIG")
SERIAL_UNIT=$("$YQ" '.serial_unit' "$CONFIG")
ISO_FILENAME=$("$YQ" '.iso_filename' "$CONFIG")
SMB_HOST=$("$YQ" '.smb_host' "$CONFIG")
SMB_SHARE=$("$YQ" '.smb_share_path' "$CONFIG") # YAML "\\public" → \public
# 以下同様に各値を読み取る
複数サーバを同時にセットアップする場合の規約:
SERVER_SUFFIX = hostname の末尾数字 (例: ayase-web-service-4 → "4")
| リソース | 命名規則 |
|---|---|
| preseed | preseed/preseed-generated-s${SUFFIX}.cfg |
| ISO | config の iso_filename (サーバ別に分離済み) |
| cookie | tmp/<session-id>/bmc-cookie-s${SUFFIX} |
| SOL ログ | tmp/<session-id>/sol-install-s${SUFFIX}.log |
| pve-lock | 並列時は常に ./pve-lock.sh wait を使用 |
| 試行ログ | tmp/<session-id>/trial-N-s${SUFFIX}.log |
| 操作 | 最大リトライ | 間隔 | フォールバック |
|---|---|---|---|
| BMC session login | 3 | 10s | エラー停止 |
| VirtualMedia mount + verify | 3 | 15s | 再ログイン + 再mount |
| SOL connect (sol-monitor.py) | 3 | 5s | POST code ポーリング (Supermicro) / VNC (iDRAC) |
| SSH connect (ssh-wait.sh) | 30 | 10s | SOL 確認 |
| DHCP IPv4 (pre-pve-setup.sh) | 6 | 5s | dhclient |
| iDRAC install retry (full bmc-mount-boot 単位) | 3 | 5min | racadm racreset soft → 再 mount → 再 boot (R430 で実証) |
./scripts/os-setup-phase.sh init --config "$CONFIG"
./scripts/os-setup-phase.sh status --config "$CONFIG"
--config を指定すると、設定ファイル名からサーバ別の状態ディレクトリが自動導出される（例: config/server6.yml → state/os-setup/server6/）。これにより、異なるサーバの状態が互いに干渉しない。
既に初期化済みの場合は status で進行状況を確認し、完了済みフェーズはスキップする。
./scripts/os-setup-phase.sh next --config "$CONFIG" で次の未完了フェーズを取得する。
各フェーズ開始時に ./scripts/os-setup-phase.sh start <phase> --config "$CONFIG" を実行する。
mark 時に終了タイムスタンプが自動記録される。
pve-lock: 不要
debian_iso_url, debian_iso_sha256, iso_download_dir を読み取るcurl -L -o <path> <url> でダウンロードsha256sum <file> の出力と設定値を比較./scripts/os-setup-phase.sh mark iso-download --config "$CONFIG"エラー時: sha256 不一致 → ファイル削除して再ダウンロード
pve-lock: 不要
Supermicro の場合:
./scripts/generate-preseed.sh <config.yml> preseed/preseed-generated-s${SUFFIX}.cfgiDRAC の場合:
preseed/preseed-server7.cfg を手動管理。generate-preseed.sh は使用しない⚠️
netcfg/choose_interfaceは明示的に静的側 NIC を指定すること (Round 1 s15/s5 で観測):netcfg/choose_interface autoは link up している先頭 NIC を選ぶため、mgmt 配線がeno2のサーバでもeno1(DHCP 側) に静的 IP が割り当てられ、Phase 6 で SSH 不到達になる。generate-preseed.shはstatic_ifaceの値を自動設定するので、config のstatic_ifaceが正しければ問題ない。preseed.cfg.template は%%CHOOSE_INTERFACE%%プレースホルダーを使用。
⚠️
netcfg/no_default_routeとnetcfg/gateway_unreachableの両方を preseed に追加すること (Round 1 s5 で観測): 管理ネットワーク (10.0.0.0/8) はインターネット到達性がないため、以下の 2 つのダイアログが blocking する:
- "Continue without a default route?" —
d-i netcfg/no_default_route boolean trueで自動応答- "Gateway unreachable, continue?" —
d-i netcfg/gateway_unreachable boolean trueで自動応答preseed.cfg.templateには両方追加済み (2026-05-14)。iDRAC 用の手動管理 preseed にも追記すること。
完了: ./scripts/os-setup-phase.sh mark preseed-generate --config "$CONFIG"
pve-lock: 不要
sha256sum <preseed_file> で現在のハッシュを取得
前回のハッシュファイル (<iso_download_dir>/${ISO_FILENAME}.preseed-sha256) と比較
→ 一致 && 出力 ISO が存在 → リマスターをスキップ (Phase 3 即完了)
→ 不一致 or ISO なし → リマスター実行 (ステップ 3 へ)
Supermicro の場合:
./scripts/remaster-debian-iso.sh <元ISO> preseed/preseed-generated-s${SUFFIX}.cfg <iso_download_dir>/${ISO_FILENAME}
iDRAC の場合:
./scripts/remaster-debian-iso.sh <元ISO> preseed/preseed-server<N>.cfg <iso_download_dir>/${ISO_FILENAME} --serial-unit=<UNIT>
--serial-unit の決定: 事前に BIOS SerialPortAddress を確認して決める:
ssh -F ssh/config idrac<N> racadm get BIOS.SerialCommSettings.SerialPortAddress
| SerialPortAddress | iDRAC SOL → 物理 COM | kernel console= | --serial-unit= |
|---|---|---|---|
Serial1Com2Serial2Com1 | Serial2 → Com1 (0x3F8) | ttyS0 | 0 |
Serial1Com1Serial2Com2 | Serial2 → Com2 (0x2F8) | ttyS1 | 1 |
注意: この値は個体ごとに異なる (Serial1Com2Serial2Com1 が推奨設定だが、 F3 Load Defaults や過去の BIOS 操作で Serial1Com1Serial2Com2 に戻っている 個体もある)。SOL に BIOS POST は出るが installer 出力が出ない場合はこの mismatch を疑うこと (
report/2026-04-10_172807_server8_vmedia_recovery_test.md関連調査で発見)。
--legacy-only を付けない（UEFI + Legacy dual boot ISO を生成）remaster-debian-iso.sh のカーネルパラメータが vga=normal nomodeset であること確認preseed/file=/cdrom/preseed.cfg でISO ルート配置のみ使用preseed/file=/cdrom/preseed.cfg が読めない環境があるため、remaster-debian-iso.sh が preseed を initrd に注入する (ホスト側で 7z + cpio)。Supermicro の場合はこの動作がデフォルトsha256sum <preseed_file> の出力を <iso_download_dir>/${ISO_FILENAME}.preseed-sha256 に保存
./scripts/os-setup-phase.sh mark iso-remaster --config "$CONFIG"R320 は UEFI モードで運用する。preseed から partman-efi/non_efi_system を削除済みで、
UEFI モードでは partman が自動的に ESP を作成し grub-efi-amd64 が正常にインストールされる。
Legacy BIOS モードでは GPT パーティションテーブルからブートできない問題が発生する。
重要 (反復5で発見): BIOS F3 (Load Default Settings) を実行すると Boot Mode が UEFI → BIOS (Legacy) に変わる。 BIOSリセット後は必ず BootMode を確認し、BIOS (Legacy) になっていたら以下の手順で UEFI に戻すこと。
⚠️ 絶対禁止 (反復7-9で発見、8号機で永続的故障):
racadm set BIOS.BiosBootSettings.BootMode Uefiを使用してはならない。 R320 / iDRAC7 FW 2.65.65.65 では racadm 経由の BootMode 変更が UefiBootSeq からOptical.iDRACVirtual.1-1を削除し、VirtualMedia ブートが永続的に不能になる。 一度削除されると racadm では復元できない (BOOT018 read-only エラー)。BIOS Load Defaults + VNC BIOS UI での手動修正が必要になる (idrac7 スキルの「VirtualMedia ブート復旧手順」 を参照)。
R320 が Legacy BIOS モードの場合、VNC 経由で BIOS Setup から手動で UEFI に切り替える:
# まず現在のモードを確認
ssh -F ssh/config idrac7 "racadm get BIOS.BiosBootSettings.BootMode"
# BootMode=Bios が返ってきたら、VNC BIOS UI で手動変更:
# 1. 電源サイクル後 POST 開始まで 45 秒待機
# 2. F2 連打で BIOS Setup 入場
python3 ./scripts/idrac-kvm-interact.py --bmc-ip $BMC_IP sendkeys F2 x30 --wait 2000 \
--screenshot-each tmp/<sid>/bm-f2 --pre-screenshot
# 3. "System Setup" で Enter (System BIOS 選択)
# 4. "Boot Settings" に移動 → "Boot Mode" → UEFI 選択
# 5. Escape → Finish → 確認 Enter
# (具体的なキー操作はスクリーンショットを見ながら適宜)
重要: BootMode 変更には racadm を使わず、必ず VNC BIOS UI を使うこと。racadm の set BIOS.BiosBootSettings.BootMode は VirtualMedia デバイスの BIOS NVStore 登録を破壊する。
racadm set iDRAC.ServerBoot.BootOnce は iDRAC7 でサイレントに失敗する。
BootOnce の操作には legacy コマンドを使用すること:
racadm config -g cfgServerInfo -o cfgServerBootOnce 1 # 有効化
racadm config -g cfgServerInfo -o cfgServerBootOnce 0 # 無効化
FirstBootDevice は racadm set iDRAC.ServerBoot.FirstBootDevice が正常に動作する。
idrac-virtualmedia.sh は修正済み (legacy コマンドを使用)。
racadm raid clearforeignconfig は存在しない: foreign disk 解除には racadm raid resetconfig:RAID.Integrated.1-1 を使う (Blocked disk 解除にも有効)/dev/sdb として vFlash SD slot が exposed: R430 は 内蔵 vFlash SD slot (実 SD カード未装着でも) を /dev/sdb として OS から見える状態にすることがある。preseed の partman/early_command で for disk in $(list-devices disk) を使うと不正な空 disk (/dev/sdb size= block=) が partman に渡され partman-auto が失敗する。for disk in /dev/sda; do ... のように明示的に対象 disk のみ処理すること (server14.cfg で対応済)partman-auto/method regular + atomic recipe が失敗: root mountpoint が割り当てられず「No root file system」dialog ループになる。partman-auto/method lvm + atomic-lvm recipe で確実に動作する (vg0 + root LV + swap_1 LV 構成)。LVM 経由は 4Kn alignment 自動調整も良好remoteimage SMB マウントが不安定なら umount → 5 秒 → 再 mount を最大 3 回試行racadm get BIOS.BiosBootSettings.BootMode が Uefi のままなら触らないpve-lock: 必要（./pve-lock.sh wait で実行）
このフェーズは以下をまとめて実行する:
Phase 4 開始前にサーバを確実に Off にする:
PowerState=$(./scripts/bmc-power.sh status "$BMC_IP" "$BMC_USER" "$BMC_PASS")
# On なら ForceOff → 10 秒待機
これにより BootOptions 列挙が 1 回のパワーサイクルで成功する確率が上がる。
BMC ログイン:
COOKIE_FILE="tmp/<session-id>/bmc-cookie-s${SUFFIX}"
./scripts/bmc-session.sh login "$BMC_IP" "$BMC_USER" "$BMC_PASS" "$COOKIE_FILE"
CSRF=$(./scripts/bmc-session.sh csrf "$BMC_IP" "$COOKIE_FILE")
VirtualMedia 設定・マウント:
警告: SMB パスのバックスラッシュ SMB パスは必ず yq で config から読み取った値を使うこと。シェルリテラルで バックスラッシュをハードコードすると二重バックスラッシュ (
\\\\public) が CGI API に送信され、CGI は成功を返すが実際にはマウントされない silent failure が発生する。
SMB_PATH="${SMB_SHARE}\\${ISO_FILENAME}"
./scripts/bmc-virtualmedia.sh config "$BMC_IP" "$COOKIE_FILE" "$CSRF" "$SMB_HOST" "$SMB_PATH"
./scripts/bmc-virtualmedia.sh mount "$BMC_IP" "$COOKIE_FILE" "$CSRF"
./scripts/bmc-virtualmedia.sh status "$BMC_IP" "$COOKIE_FILE" "$CSRF"
Redfish でマウント検証:
./scripts/bmc-virtualmedia.sh verify "$BMC_IP" "$BMC_USER" "$BMC_PASS"
Inserted: true → 次のステップへInserted: false → BMC 再ログイン + CSRF 再取得 + 再マウント + 再検証 (最大3回)サーバをパワーサイクルして BootOptions を列挙させる:
重要:
ATEN Virtual CDROMは UEFI POST で VirtualMedia を検出した後にのみ BootOptions に出現する。
./pve-lock.sh wait ./scripts/bmc-power.sh cycle "$BMC_IP" "$BMC_USER" "$BMC_PASS" 20
POST 完了をアクティブポーリングで待機 (固定 sleep 180 の代わり):
bmc-power.sh postcode を 15 秒間隔でポーリング0x00 (POST complete) 到達 → 即座に次のステップへ0x00 or 0x01) のまま 45 秒変化なし → POST API 不信頼と判断し次のステップへ進む0x92 で 120 秒以上停滞 → POST スタック、ForceOff → 20s → On で再試行BootOptions から VirtualMedia CD の Boot ID を動的検索:
BOOT_ID=$(./scripts/bmc-power.sh find-boot-entry "$BMC_IP" "$BMC_USER" "$BMC_PASS" "ATEN Virtual CDROM")
find-boot-entry は最大3回リトライ（15秒間隔）6号機: Redfish BootOptions API が空の場合のフォールバック:
6号機など一部のサーバでは Redfish BootOptions API が空配列を返し、find-boot-entry / boot-next (UefiBootNext) が使えない。
この場合、bios-setup スキルの --no-click を使って BIOS Boot タブから Boot Option #1 を設定する:
--no-click で Boot タブに移動 (ArrowRight x5)bios-setup スキルで全 PXE Boot Option を Disabled に設定 (Enter → PageDown → Enter を Boot Option ごとに繰り返す。17 個分)Boot Override 設定 + 電源サイクル:
./pve-lock.sh wait ./scripts/bmc-power.sh boot-next "$BMC_IP" "$BMC_USER" "$BMC_PASS" "$BOOT_ID"
./pve-lock.sh wait ./scripts/bmc-power.sh cycle "$BMC_IP" "$BMC_USER" "$BMC_PASS" 20
POST 92 スタック (4号機固有):
4号機は ForceOff 後のパワーサイクルで POST 92 (PCI Bus Enumeration) にスタックする傾向がある。
efibootmgr -n + warm reboot でも回避不可 (検証済み)。
ForceOff → 20s → On のリカバリで対処し、POST 92 発生時は追加 5-10 分を見込むこと。
R430 では Phase 4 開始前に OS 用 VD が State=Online で存在すること を確認する。
VD が無い、Foreign / Blocked disk が残っている、または前回 fail ジョブが pending に残っている場合は、以下の整備手順を実行してから Phase 4 に入る (詳細: report/2026-05-12_040320_server14_os_install_retry.md):
ssh -F ssh/config idrac<N> racadm raid get vdisks
ssh -F ssh/config idrac<N> racadm raid get pdisks -o -p Size,State
ssh -F ssh/config idrac<N> racadm jobqueue view
./pve-lock.sh wait ./oplog.sh ssh -F ssh/config idrac<N> racadm jobqueue delete --all
./pve-lock.sh wait ./oplog.sh ssh -F ssh/config idrac<N> racadm raid resetconfig:RAID.Integrated.1-1
./pve-lock.sh wait ./oplog.sh ssh -F ssh/config idrac<N> racadm jobqueue create RAID.Integrated.1-1 -s TIME_NOW -r pwrcycle
iDRAC8 注意:
clearforeignconfigは 存在しない。clearconfigも「No foreign drives detected」エラーで失敗することがある。resetconfigを使うこと。foreign + local + pending + Blocked が一括解除される。
⚠️ resetconfig 後の SCP Export ジョブに注意 (Round 2 s15 で観測):
racadm raid resetconfig完了後、iDRAC が自動的にExport: Server Configuration Profilejob を生成する。これが完了する前にracadm raid createvdを実行するとLC062で失敗する。ssh -F ssh/config idrac<N> racadm jobqueue viewresetconfig job + Export job 両方が
Completed (100)を確認してから createvd へ進む。
./pve-lock.sh wait ./oplog.sh ssh -F ssh/config idrac<N> racadm raid createvd:RAID.Integrated.1-1 -rl r1 \
-pdkey:Disk.Bay.1:Enclosure.Internal.0-1:RAID.Integrated.1-1,Disk.Bay.6:Enclosure.Internal.0-1:RAID.Integrated.1-1 \
-name OS_RAID1
./pve-lock.sh wait ./oplog.sh ssh -F ssh/config idrac<N> racadm jobqueue create RAID.Integrated.1-1 -s TIME_NOW -r pwrcycle
racadm jobqueue view を 30 秒間隔でポーリングして Completed (100) を待つ (3-5 分目安)。⚠️ PERC RAID-1 disk スペック一致必須: link speed + sector size + model が一致したペアを選ぶこと。
- 不一致 (例: ST300MP0026 12Gb/s + ST9300653SS 6Gb/s) は BGI 26% 付近で停滞する (14号機で確認、issue #63)
- 同モデル・同サイズ・同 link speed なら BGI スキップで即時 Online になる
- State=Online, OperationalState=Not applicable で BGI 不要
事前検証: BIOS SerialCommSettings (R320 固有、install-monitor 成立の必須条件):
iDRAC SOL で Debian インストーラの進行を監視するためには、BIOS のシリアルコンソールリダイレクトが有効でなければならない。BIOS.SerialCommSettings.SerialComm が OnConRedirCom1 でない場合、BIOS POST 以降の出力 (カーネルログ、インストーラテキスト) が iDRAC SOL に流れず、sol-monitor.py は永久に進行を検知できない (install-monitor フェーズがハング)。
⚠️ 既知の原因:
BIOS.BiosBootSettings.BootMode破壊からの VirtualMedia 復旧手順 (idrac7 スキルの「VirtualMedia ブート復旧手順」) で BIOS Load Defaults (F3) を実行するとSerialCommSettingsもデフォルト (OnNoConRedir) にリセットされる。復旧手順でSerialCommSettingsの復元を行っていないと、次回 install-monitor が無言でハングする。
SERIAL_CURRENT=$(ssh -F ssh/config "$IDRAC_HOST" racadm get BIOS.SerialCommSettings.SerialComm | grep '^SerialComm=' | cut -d= -f2 | tr -d '\r\n')
REDIR_CURRENT=$(ssh -F ssh/config "$IDRAC_HOST" racadm get BIOS.SerialCommSettings.RedirAfterBoot | grep '^RedirAfterBoot=' | cut -d= -f2 | tr -d '\r\n')
if [ "$SERIAL_CURRENT" != "OnConRedirCom1" ] && [ "$SERIAL_CURRENT" != "OnConRedirAuto" ] || [ "$REDIR_CURRENT" != "Enabled" ]; then
echo "FIX: SerialComm=$SERIAL_CURRENT RedirAfterBoot=$REDIR_CURRENT → restoring"
./pve-lock.sh wait ./oplog.sh ssh -F ssh/config "$IDRAC_HOST" racadm set BIOS.SerialCommSettings.SerialComm OnConRedirCom1
./pve-lock.sh wait ./oplog.sh ssh -F ssh/config "$IDRAC_HOST" racadm set BIOS.SerialCommSettings.RedirAfterBoot Enabled
./pve-lock.sh wait ./oplog.sh ssh -F ssh/config "$IDRAC_HOST" racadm jobqueue create BIOS.Setup.1-1 -s TIME_NOW -r pwrcycle
# BIOS ジョブ完了を待つ (5-6 分)。jobqueue view でポーリング。
fi
BIOS.SerialCommSettings は BIOS.BiosBootSettings.BootMode と異なり、racadm 経由の変更で UefiBootSeq の VirtualMedia エントリを破壊しない。安全に racadm で変更可能。
注:
OnConRedirCom1だけでなくOnConRedirAutoも install-monitor 互換 (R430 + BIOS 2.9.1 / 2.15.0 で確認、Round 1)。両方とも許容値として扱う。
VirtualMedia マウント:
REMOTE_URI=$("$YQ" '.remoteimage_uri' "$CONFIG")
./scripts/idrac-virtualmedia.sh mount "$BMC_IP" "$REMOTE_URI"
./scripts/idrac-virtualmedia.sh status "$BMC_IP"
./scripts/idrac-virtualmedia.sh verify "$BMC_IP"
Boot Once 設定 + 電源サイクル:
./scripts/idrac-virtualmedia.sh boot-once "$BMC_IP" VCD-DVD
./pve-lock.sh wait ./scripts/bmc-power.sh cycle "$BMC_IP" "$BMC_USER" "$BMC_PASS" 20
完了: ./scripts/os-setup-phase.sh mark bmc-mount-boot --config "$CONFIG"
エラー時:
bmc-session.sh login + csrf を再実行pve-lock: 必要（Phase 4 から継続保持）
所要時間目安: Debian インストールは通常 10-12 分。全フェーズ (Phase 1-8) 合計は 35-50 分。
Debian インストーラの進行を監視する。SOL 監視を主要手段とし、フォールバックはプラットフォーム別。
preseed early_command は syslogd -R 10.1.6.1:5514 -L で installer syslog を UDP でフォワードする。
./scripts/syslog-receiver.sh を起動しておかないと、grub-install / efibootmgr の生エラー文字列が永久に失われる (SOL には TUI ダイアログのピクセルしか残らない)。
単独実行時:
mkdir -p tmp/<session-id>
if ss -uln 2>/dev/null | grep -q ':5514 '; then
echo "WARN: UDP 5514 already in use; skipping syslog receiver"
SYSLOG_RCV_PID=""
else
./scripts/syslog-receiver.sh 5514 tmp/<session-id>/installer-syslog-s${SUFFIX}.log &
SYSLOG_RCV_PID=$!
echo "Started syslog receiver (pid=$SYSLOG_RCV_PID)"
fi
並列実行時 (7/8/9 同時): 3 台が同じ UDP 5514 に書くため、親セッションで 1 本だけ リスナーを立てる。子エージェントは立てない。
./scripts/syslog-receiver.sh 5514 tmp/<parent-sid>/installer-syslog-all.log &
受信後は送信元 IP (10.10.10.207/208/209) で grep して台ごとに切り分ける。
前提: socat が必要。未インストールなら sudo apt install -y socat (許可リスト内)。
ログは検証 3.5 で attachment へ永続化する (tmp 掃除前に必ず退避)。
./scripts/sol-monitor.py でインストーラの進行をパッシブ監視する:
./scripts/sol-monitor.py \
--bmc-ip "$BMC_IP" --bmc-user "$BMC_USER" --bmc-pass "$BMC_PASS" \
--log-file tmp/<session-id>/sol-install-s${SUFFIX}.log \
--max-reconnects 3
注意: SOL は OS レベルの
/dev/ttyS*書き込みを捕捉しない (Dell R320 + iDRAC7 共通)。 SOL に流れる出力は BIOS の INT10h リダイレクションまたは installer 特有の UEFI ConsoleOut 経由のみ。 インストール後の OS 状態を SOL 経由で確認することは基本的にできないため、post-install-config は SSH +/etc/machine-id検証で行うこと (Phase 6 ステップ 5 参照)。
| exit code | 状態 | 対処 |
|---|---|---|
| 0 | 完了 (stage 観測 ≥ 1 & PowerState=Off) | 次の Phase へ |
| 1 | タイムアウト | PowerState 確認。Off かつ stage 観測あり→完了扱い。それ以外→forceoff |
| 2 | 接続エラー | フォールバックへ |
| 3 | 異常終了 | PowerState 確認。Off かつ stage 観測あり→完了扱い。それ以外→フォールバックへ |
| 4 | False positive (stage 0 件 + Off) | 強制 Off → bmc-mount-boot から再実行。install-monitor を done にしない。BIOS SerialComm/VirtualMedia の状態を再確認 |
重要:
PowerState=Off単独での成功判定は False positive の原因となる (report/2026-04-10_172807_server8_vmedia_recovery_test.md)。sol-monitor.pyは内部で 最低 1 ステージの観測 を必須化している。 さらに install-monitor 完了を判断する前に、Phase 6 の/etc/machine-idタイムスタンプ検証を必ず通すこと。 exit 4 を受け取った場合は、install-monitor を done にせず bmc-mount-boot からやり直す。
Supermicro: POST code ポーリング
./scripts/bmc-power.sh postcode "$BMC_IP" "$BMC_USER" "$BMC_PASS"
./scripts/bmc-power.sh status "$BMC_IP" "$BMC_USER" "$BMC_PASS"
Off → インストール完了0x92 で10分以上停滞 → POST スタック（reference.md 参照）iDRAC: VNC スクリーンショット (VNC 3回リトライ → capconsole フォールバック)
python3 ./scripts/idrac-kvm-screenshot.py --bmc-ip "$BMC_IP" --bmc-user "$BMC_USER" --bmc-pass "$BMC_PASS" --output tmp/<session-id>/screenshot.png
症状: install attempt 2-3 回失敗後、GRUB 無限ループ (POST → GRUB プロンプト → again) で installer に到達しない。VirtualMedia status は Inserted=true を返すが、boot 時に iDRAC が ISO を正しく hand-off しない内部状態 corruption。
解決: iDRAC を soft reset → clean state で再 mount → install 再実行 (14号機 attempt 6 で成功実証):
./pve-lock.sh wait ./oplog.sh ssh -F ssh/config idrac<N> racadm racreset soft
# 約 2-3 分で iDRAC 再起動完了 (SSH 切断 → 再接続可能まで)
./scripts/ssh-wait.sh 10.10.10.<3N> --timeout 240 --interval 10
# 再起動後に bmc-mount-boot から再実行
./scripts/os-setup-phase.sh reset bmc-mount-boot --config "$CONFIG"
./scripts/os-setup-phase.sh reset install-monitor --config "$CONFIG"
目安: 同一 ISO + 同一 preseed で install attempt 3 連続失敗 (GRUB 無限ループ or false-positive exit 4) が発生した場合は racreset soft を最初に試すこと。VirtualMedia をいくら再 mount しても状態は元に戻らない。
早期 trigger (Round 3 で観測): 以下のいずれかで 1 回目から racreset soft 即発動可:
- partman stuck: stage 5/9 で 15 分以上停滞 + installer-syslog で
No matching physical volumes found/partman: ...failed等の同種エラー後の沈黙が 10 分以上 (Round 3/5 で実証)。SOL に byobu status bar が表示されたまま動かないのもサイン- GRUB sector read error: SOL に
error: failure reading sector 0x... from cd0が連続出力- iDRAC SSH 復旧確認:
ssh-wait.shは root@host 限定。iDRAC はssh -F ssh/config idrac<N> racadm getsysinfoを 30 秒間隔でポーリング (~2-3 分で復旧)
preseed の partman/confirm boolean true は dialog を auto-confirm して partman 再試行を許す。partman-base/no_root_device 等の error dialog が SOL に表示されても、preseed が auto-confirm して install を最後まで進めている可能性がある (14号機 attempt 1, 3 で発生)。
判定手順:
grub-installer / finish-install の進行ログがあれば → install 進行中partman-auto で stop している → 真の失敗python3 ./scripts/idrac-kvm-screenshot.py --bmc-ip "$BMC_IP" --bmc-user "$BMC_USER" --bmc-pass "$BMC_PASS" --output tmp/<sid>/check.png
sol-monitor.py を継続走らせる (1 ステージでも観測されていれば EOF 再接続で正常完了する)ipmitool ... sol deactivate（sol-monitor.py が自動切断するが念のため）if [ -n "$SYSLOG_RCV_PID" ]; then
kill "$SYSLOG_RCV_PID" 2>/dev/null || true
wait "$SYSLOG_RCV_PID" 2>/dev/null || true
SYSLOG_LOG="tmp/<session-id>/installer-syslog-s${SUFFIX}.log"
if [ -s "$SYSLOG_LOG" ]; then
echo "Installer syslog: $(wc -l < "$SYSLOG_LOG") lines saved to $SYSLOG_LOG"
else
echo "WARN: Installer syslog empty — check network path to 10.1.6.1:5514"
fi
fi
./scripts/os-setup-phase.sh mark install-monitor --config "$CONFIG"pve-lock: 必要
Debian インストール後の初期設定。
Supermicro の場合:
./scripts/bmc-session.sh login "$BMC_IP" "$BMC_USER" "$BMC_PASS" "$COOKIE_FILE"
CSRF=$(./scripts/bmc-session.sh csrf "$BMC_IP" "$COOKIE_FILE")
./scripts/bmc-virtualmedia.sh umount "$BMC_IP" "$COOKIE_FILE" "$CSRF"
./pve-lock.sh wait ./scripts/bmc-power.sh boot-override-reset "$BMC_IP" "$BMC_USER" "$BMC_PASS"
iDRAC の場合:
./scripts/idrac-virtualmedia.sh umount "$BMC_IP"
./scripts/idrac-virtualmedia.sh boot-reset "$BMC_IP"
boot-reset は BootOnce=Disabled + FirstBootDevice=Normal に設定する。
./pve-lock.sh wait ./scripts/bmc-power.sh on "$BMC_IP" "$BMC_USER" "$BMC_PASS"
Supermicro の場合 — POST code 監視:
0x92 で停滞 → 自動リカバリ (ForceOff → 20秒 → On)0x01/0x00 が 3-5 分変化なし → stale の疑い → KVM スクリーンショットで確認./scripts/ssh-wait.sh <static_ip> --timeout 180 --interval 10 でアクティブポーリングiDRAC の場合 — SSH リトライ:
./scripts/ssh-wait.sh <static_ip> --timeout 210 --interval 10 で SSH 到達を待つ症状: Power On 後に POST → 「Reboot and Select proper Boot device」 → PXE フォールバック → DHCP 失敗で停止。SSH も到達しない。
典型例: 10号機 (NX-1065-G5) は OS install 先 disk が LSI SAS HBA 経由 で、出荷時 BIOS 設定の LSI HBA OPROM=[Disabled] のままだと Legacy boot 不能。Boot Override に PXE しか出ず、Boot タブの "Hard Disk Drive BBS Priorities" サブメニューが空 (= disk が boot device として列挙されない)。
判定: BIOS Setup に入って以下を確認 (bios-setup スキル + --prefer vkbd):
判定フロー:
LSI HBA OPROM=[Enabled] に変更 → F4 → Save & Reset (Plan A.3 — 10号機の本命)grub-install /dev/sda (Plan B)詳細は report/2026-05-02_*_server10_disk_first_boot_recovery.md を参照。
重要: preseed の late_command は Debian 13 で動作しないことが多い。 SSH 公開鍵、PermitRootLogin、sudoers は SOL 経由で設定する必要がある。 両プラットフォーム共通: このステップは Supermicro / iDRAC 両方で必須。 Supermicro の場合も SOL (
sol-login.py) で SSH 鍵を配置する。 SSH 鍵が未配置のままだと、後続の Phase 7 (pve-install) で SSH 接続できない。
a. SSH 公開鍵を Read ツールで ssh/id_ed25519.pub から取得（注意: ~/.ssh/id_ed25519.pub ではなく ssh/id_ed25519.pub を使うこと。ssh/config の pve7-9 エントリは ssh/id_ed25519 を IdentityFile として使用するため、これが正しいプロジェクト鍵）
⚠️ SOL コマンド送信のベストプラクティス (Round 1 s15 で観測):
- heredoc は使えない:
sol-login.pyは行単位送信のためcat <<EOF ... EOFが複数 echo に分解される。printf '...\n...\n' > fileを使うこと- stdout は捕捉されない: SOL 経由で
ip addr等を実行しても出力は SOL ログに混ざるだけで構造化キャプチャできない。状態確認は> /tmp/result.txtでファイル化してから後続 SSH で読み出すことprintf '...' > /fileで出る "Command may have failed" 警告は誤検知 (Round 2 s15): リダイレクト自体は成功している。SSH 鍵認証成功 / ファイル存在で間接的に検証する
b. コマンドファイルを tmp/<session-id>/sol-commands-s${SUFFIX}.txt に作成:
sed -i "s/^#PermitRootLogin.*/PermitRootLogin yes/" /etc/ssh/sshd_config
systemctl restart sshd
echo "debian ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/debian
chmod 0440 /etc/sudoers.d/debian
mkdir -p /root/.ssh
chmod 700 /root/.ssh
echo "<BASE64_ENCODED_PUBKEY>" | base64 -d > /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys
注意:
echo "ssh-ed25519 ..." > /root/.ssh/authorized_keysは SOL 経由で>リダイレクトと長い引数が正しく扱われないことがある。 公開鍵は必ず base64 エンコードして書き込むこと:python3 -c "import base64; k=open('ssh/id_ed25519.pub').read().strip(); print(base64.b64encode(k.encode()).decode())"これで得た BASE64 文字列を
<BASE64_ENCODED_PUBKEY>に置換する。
printf "\nauto <static_iface>\niface <static_iface> inet static\n address <static_ip>/8\n" >> /etc/network/interfaces
ifup <static_iface>
ip -brief addr
重要: 静的 IP 設定を SOL 経由で行うことで、DHCP IP への SSH 接続を不要にする。
c. ./scripts/sol-login.py で実行:
./scripts/sol-login.py --bmc-ip "$BMC_IP" --bmc-user "$BMC_USER" --bmc-pass "$BMC_PASS" \
--root-pass "$ROOT_PASS" --commands-file tmp/<session-id>/sol-commands-s${SUFFIX}.txt
⚠️ DETECTING timeout (Round 3 R430 で観測): 最初の sol-login.py が boot 完了前に DETECTING で 180s timeout する場合がある。120-180 秒待って再試行するか、ssh-wait.sh で SSH 到達してからにする (R430 + Debian 13 minimal で 5-6 分かかることがある)
⚠️ eno1 (DHCP iface) は preseed install 後 DOWN がデフォルト (Round 3 で観測): preseed の
netcfg/choose_interface select eno2で静的側 NIC を選んだ場合、DHCP 側のeno1は/etc/network/interfacesに未記述で boot 時 DOWN になる。Phase 7 でpre-pve-setup.shが dhcpcd を試す前にip link set eno1 upが必要なケースがある。 SOL コマンドリストに以下を追加して preventive に対処:ip link set <dhcp_iface> up printf 'auto <dhcp_iface>\niface <dhcp_iface> inet manual\n' >> /etc/network/interfaces
⚠️ SOL の
|(pipe) 文字解釈失敗 (R430 で観測):echo "..." | base64 -d > /root/.ssh/authorized_keysを SOL で実行すると、|の前後で escape が一部失敗しauthorized_keysecho等の 変名ファイル が作られることがある (鍵配置が silent failure になり、後続 SSH が認証エラー)。対策: pexpect 経由のパスワード SSH (DHCP IP 経由) で鍵を配置する。SOL では PermitRootLogin + PasswordAuthentication の最低限の設定だけ行い、authorized_keys は SSH で:
# SOL では PermitRootLogin / PasswordAuthentication のみ sed -i "s/^#PermitRootLogin.*/PermitRootLogin yes/" /etc/ssh/sshd_config sed -i "s/^#PasswordAuthentication.*/PasswordAuthentication yes/" /etc/ssh/sshd_config systemctl restart sshd# 別途 pexpect でパスワード SSH → 鍵配置 (DHCP IP は preseed install 後にログから取得) python3 -c " import pexpect p = pexpect.spawn('ssh -F ssh/config -o StrictHostKeyChecking=no root@<dhcp_ip>') p.expect('password:') p.sendline('<root_pass>') p.expect(r'#\s*$') p.sendline('mkdir -p /root/.ssh && chmod 700 /root/.ssh') p.expect(r'#\s*$') p.sendline('echo <pubkey> > /root/.ssh/authorized_keys') p.expect(r'#\s*$') p.sendline('chmod 600 /root/.ssh/authorized_keys') p.expect(r'#\s*$') "SOL 経由で
|が必要な処理 (base64 デコード等) は 一切回避する。短い鍵 (ed25519, 80 文字程度) なら base64 不要で直接 echo 可能。
sol-login.py がタイムアウトした場合 (Supermicro):
POST code 確認 → 0x92 なら ForceOff → 20秒 → On → ssh-wait.sh --timeout 180 --interval 10 → sol-login.py を再実行。
iDRAC のフォールバック: SOL が使えない場合は pexpect で debian ユーザにパスワード SSH → su root で設定する。
ssh-keygen -R <static_ip> -f ssh/known_hosts
./scripts/ssh-wait.sh <static_ip> --timeout 150 --interval 10
背景:
sol-monitor.pyの PowerState=Off 判定は stage 観測ガードで補強されているが、 それでも「古い OS がそのまま起動し SSH 応答を返した」ケースは検出できない。 install-monitor 開始時刻より 新しい/etc/machine-idが生成されていることを SSH 経由で 実測検証する。古ければリインストール未実行と判断し、install-monitor と bmc-mount-boot を reset してフェーズをやり直す (report/2026-04-10_172807_server8_vmedia_recovery_test.md参照)。
SERVER_NAME=$(basename "$CONFIG" .yml)
STATE_DIR="state/os-setup/${SERVER_NAME}"
INSTALL_START=$(cat "${STATE_DIR}/install-monitor.start")
REMOTE_MACHINE_ID_MTIME=$(ssh -F ssh/config "pve${NUM}" stat -c %Y /etc/machine-id)
REMOTE_HOSTNAME_MTIME=$(ssh -F ssh/config "pve${NUM}" stat -c %Y /etc/hostname)
echo "install-monitor.start = ${INSTALL_START} ($(date -d @${INSTALL_START}))"
echo "remote /etc/machine-id mtime = ${REMOTE_MACHINE_ID_MTIME} ($(date -d @${REMOTE_MACHINE_ID_MTIME}))"
echo "remote /etc/hostname mtime = ${REMOTE_HOSTNAME_MTIME} ($(date -d @${REMOTE_HOSTNAME_MTIME}))"
if [ "${REMOTE_MACHINE_ID_MTIME}" -lt "${INSTALL_START}" ]; then
echo "ERROR: /etc/machine-id predates install-monitor start — FALSE POSITIVE"
./scripts/os-setup-phase.sh fail post-install-config --config "$CONFIG"
./scripts/os-setup-phase.sh reset install-monitor --config "$CONFIG"
./scripts/os-setup-phase.sh reset bmc-mount-boot --config "$CONFIG"
exit 1
fi
両方のタイムスタンプが install-monitor 開始より新しいことを確認できたら正規のリインストールが行われたと判断する。
⚠️ initramfs dropout false-success (Round 9 s14 attempt 2 で新規観測): sol-monitor が exit 0 (installation completed) を返したが、OS が
(initramfs)プロンプトで停止していたケース。partman の "No root file system" dialog を preseed が auto-confirm し、kernel+initrd は書かれたが rootfs が実際は空のまま install monitor 完了。 検出: 上記/etc/machine-idmtime チェックの前に、SSH 不到達 → SOL 経由で Enter flood →(initramfs)プロンプトが返ってきたら initramfs dropout 確定。bmc-mount-boot + install-monitor を reset して再 install。
完了: ./scripts/os-setup-phase.sh mark post-install-config --config "$CONFIG"
pve-lock: 必要
PVE のインストールを SSH 経由で実行。
ネットワーク制約:
10.0.0.0/8はインターネット到達不可。preseed で設定されたdefault via 10.10.10.1を削除し、192.168.39.1経由に切り替えないと apt/wget が失敗する。preseed/late_commandとpre-pve-setup.shの両方で/etc/network/interfacesからgateway 10.10.10.1行を自動削除するため、新規セットアップでは原則手動操作不要。ip route show defaultがvia 192.168.39.1 ...を返すことだけ確認する。
preseed が CD-only (apt-setup/use_mirror boolean false) の場合:
scp -F ssh/config ./scripts/pre-pve-setup.sh root@<static_ip>:/tmp/
ssh -F ssh/config root@<static_ip> sh /tmp/pre-pve-setup.sh --dhcp-iface <dhcp_iface> --static-gw 10.10.10.1 --codename <codename>
pre-pve-setup.sh は DHCP 有効化、デフォルトルート修正、apt sources 設定、wget/ca-certificates インストールを自動で行う。
⚠️ DHCP 取得が timeout する場合 (Debian 13 minimal で観測): Debian 13 minimal install は
isc-dhcp-client不在で初回 DHCP が 30 秒 timeout する。pre-pve-setup.shは内部で fallback 順序 (ifup → dhclient → dhcpcd) を持つが、タイミング依存で失敗することがある。 その場合、手動でdhcpcd -1 -t 30 <dhcp_iface>を先に流してからpre-pve-setup.shを再実行する:ssh -F ssh/config root@<static_ip> dhcpcd -1 -t 30 <dhcp_iface> ssh -F ssh/config root@<static_ip> sh /tmp/pre-pve-setup.sh --dhcp-iface <dhcp_iface> --static-gw 10.10.10.1 --codename <codename>IPv4LL fallback 対処 (Round 8 s15 で観測):
dhcpcdで 169.254.x が割り当てられたら実 DHCP 不取得。ip addr flush dev <iface>→dhcpcd -t 60 <iface>再試行で復旧:ssh -F ssh/config root@<static_ip> ip addr flush dev <dhcp_iface> ssh -F ssh/config root@<static_ip> dhcpcd -t 60 <dhcp_iface>
scp -F ssh/config ./scripts/pve-setup-remote.sh root@<static_ip>:/tmp/
ssh -F ssh/config root@<static_ip> /tmp/pve-setup-remote.sh --phase pre-reboot --hostname <hostname> --ip <static_ip> --codename <codename> --serial-unit ${SERIAL_UNIT}
ssh -F ssh/config root@<static_ip> reboot || true
./scripts/ssh-wait.sh <static_ip> --timeout 300 --interval 10
ssh-wait.sh がタイムアウトした場合のリカバリ:
Supermicro の場合:
./scripts/bmc-power.sh postcode "$BMC_IP" "$BMC_USER" "$BMC_PASS"
0x92 → POST スタック0x00/0x01 が長時間 → stale の疑い → ./scripts/bmc-kvm.sh screenshot "$BMC_IP" tmp/<session-id>/post-check.png./scripts/ssh-wait.sh <static_ip> --timeout 180 --interval 10iDRAC の場合:
./scripts/ssh-wait.sh <static_ip> --timeout 180 --interval 10SSH 再接続後、post-reboot 前にデフォルトルートを修正する。pre-pve-setup.sh を再実行するのが最も確実:
scp -F ssh/config ./scripts/pre-pve-setup.sh root@<static_ip>:/tmp/
ssh -F ssh/config root@<static_ip> sh /tmp/pre-pve-setup.sh --dhcp-iface <dhcp_iface> --static-gw 10.10.10.1 --codename <codename>
または手動で:
ssh -F ssh/config root@<static_ip> ip route del default via 10.10.10.1 || true
ssh -F ssh/config root@<static_ip> ip route add default via 192.168.39.1 || true
ルート検証 (iDRAC に限らず全プラットフォーム共通で推奨): ルート修正後にインターネット到達性を確認:
ssh -F ssh/config root@<static_ip> ping -c1 -W3 deb.debian.org || echo "WARN: no internet"
→ 失敗時は ip route を確認し、DHCP ルート (192.168.39.1) を手動追加
scp -F ssh/config ./scripts/pve-setup-remote.sh root@<static_ip>:/tmp/
ssh -F ssh/config root@<static_ip> /tmp/pve-setup-remote.sh --phase post-reboot --hostname <hostname> --ip <static_ip> --codename <codename> --serial-unit ${SERIAL_UNIT} --linstor
--linstorフラグ: LINBIT リポジトリの GPG 鍵追加 + DRBD/LINSTOR パッケージインストールを行う。LINSTOR クラスタに参加するサーバでは必ず指定すること。省略すると LINSTOR 関連のセットアップはスキップされる。 enterprise リポジトリ (.list+.sources) の除去は--linstorの有無にかかわらず常に実行される。
⚠️ LINBIT GPG empty-file silent failure (Round 2 s14 で観測):
wgetは 404 でも exit 0 + 空ファイルを残すケースがあり、pve-setup-remote.shの内部 fallback (wget失敗時のみ ubuntu keyserver) が発動しない。--linstorを使う場合は事前にローカルから ubuntu キーサーバ経由で取得して配置することを推奨:
🚨 post-reboot 中の default route 消失 → apt 失敗 (5 trial 連続再現) (Round 4-6):
pve-setup-remote.sh --phase post-reboot実行中にproxmox-veパッケージインストールが ifupdown2 を再初期化し、default route via 192.168.39.1 が消える。続く apt がTemporary failure resolving 'packages.linbit.com'で fail する。5 trial 連続再現 = 必発。 必須対処手順:pve-setup-remote.sh --phase post-rebootが exit 100 で停止したら:
ssh root@<static_ip> sh /tmp/pre-pve-setup.sh --dhcp-iface <dhcp_iface> --static-gw 10.10.10.1 --codename trixieでルート修復ssh root@<static_ip> sh /tmp/pve-setup-remote.sh --phase post-reboot ...を再実行 (冪等性で resume される)根本対処は
pve-setup-remote.sh内部に route check + dhclient 埋込が必要 (別 issue 候補)。
⚠️ LINBIT linstor-common (56MB) ダウンロード時間に注意 (Round 3 s15 で観測):
packages.linbit.com経由のlinstor-common(56.6 MB) は ~150 KB/sec で 5-15 分かかることがある。aptが進捗なしに見えても/var/cache/apt/archives/partial/内のファイルサイズが増えていれば正常。-o Acquire::http::Timeout=60 -o Acquire::Retries=3検討余地あり。
⚠️ DRBD DKMS は build-essential / libc6-dev 必須 (Round 2 s14 で観測):
pve-setup-remote.sh --linstor完了後の DKMS ビルドがstdio.h: No such fileで失敗し drbd-dkms がiF(Failed) 状態になる。 事前に build-essential を入れておく:ssh -F ssh/config root@<static_ip> apt-get install -y build-essentialその後
pve-setup-remote.sh --phase post-reboot --linstorを再実行すると DKMS ビルドが通る。
🚨 LINBIT keyring 事前配置 (3/6 trial で必発) —
--linstorを使う場合は 必須ステップ: wget からの 404 (silent failure) と内部 fallback の組合せが半数の trial で fail する。--linstorを使う前に必ず事前配置:
LINBIT GPG キーが 404 になる場合の対処:
pve-setup-remote.shはhttps://packages.linbit.com/package-signing-pubkey.gpgから GPG キーを取得するが、URL が変更されて 404 になることがある。この場合はローカルマシンで Ubuntu キーサーバから取得してサーバに配置する:curl "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x4E5385546726D13CB649872CFC05A31DB826FE48" -o tmp/<sid>/linbit-key.asc gpg --batch --yes --dearmor -o tmp/<sid>/linbit-keyring.gpg tmp/<sid>/linbit-key.asc scp -F ssh/config tmp/<sid>/linbit-keyring.gpg root@<static_ip>:/usr/share/keyrings/linbit-keyring.gpg ssh -F ssh/config root@<static_ip> chmod a+r /usr/share/keyrings/linbit-keyring.gpgその後、
pve-setup-remote.sh --phase post-reboot --linstorを再実行する（GPG キーが存在する場合は再取得をスキップする）。
ssh -F ssh/config root@<static_ip> reboot || true
./scripts/ssh-wait.sh <static_ip> --timeout 300 --interval 10
ssh -F ssh/config root@<static_ip> ip route del default via 10.10.10.1 || true
ssh -F ssh/config root@<static_ip> ip route add default via 192.168.39.1 || true
ssh -F ssh/config root@<static_ip> ping -c1 -W3 deb.debian.org || echo "WARN: no internet"
ssh -F ssh/config root@<static_ip> pveversion で PVE バージョン確認curl -sk https://<static_ip>:8006 で Web UI アクセス確認完了マーク（必須）: ./scripts/os-setup-phase.sh mark pve-install --config "$CONFIG"
WARNING: このマークを忘れると Phase 8 が開始できない。
前提チェック: ./scripts/os-setup-phase.sh check pve-install --config "$CONFIG"
pve-lock: 必要
./scripts/bmc-session.sh login "$BMC_IP" "$BMC_USER" "$BMC_PASS" "$COOKIE_FILE"
CSRF=$(./scripts/bmc-session.sh csrf "$BMC_IP" "$COOKIE_FILE")
./scripts/bmc-virtualmedia.sh umount "$BMC_IP" "$COOKIE_FILE" "$CSRF"
./pve-lock.sh wait ./scripts/bmc-power.sh boot-override-reset "$BMC_IP" "$BMC_USER" "$BMC_PASS"
./scripts/idrac-virtualmedia.sh umount "$BMC_IP"
./scripts/idrac-virtualmedia.sh boot-status "$BMC_IP"
cookie ファイル削除: rm -f "$COOKIE_FILE"
最終検証サマリ:
ssh -F ssh/config root@<static_ip> cat /etc/os-releasessh -F ssh/config root@<static_ip> pveversionssh -F ssh/config root@<static_ip> uname -rssh -F ssh/config root@<static_ip> ip -brief addrcurl -sk https://<static_ip>:8006ブリッジ設定 (vmbr0/vmbr1) — 必須ステップ:
PVE で VM を利用するにはブリッジが必要。pve-setup-remote.sh は vmbr0/vmbr1 を作らない ので、必ず pve-bridge-setup.sh を別途実行すること (Round 5 で見落とし発生)。
冪等: ブリッジが既に設定済みならスキップされる。
実行前 check: ip route で default route 有無を確認 → 不在なら dhclient -1 -v <dhcp_iface> で復旧 (Round 5-7 で連続観測)。
pve-setup-remote.shが installing する/etc/network/if-up.d/z-fix-default-routehook は final reboot 後の route loss を防げないことがある (Round 7 で確認)。dhclient復旧手順を確実に流すこと。
STATIC_IFACE=$("$YQ" '.static_iface' "$CONFIG")
STATIC_IP=$("$YQ" '.static_ip' "$CONFIG")
STATIC_NETMASK=$("$YQ" '.static_netmask' "$CONFIG")
DHCP_IFACE=$("$YQ" '.dhcp_iface' "$CONFIG")
scp -F ssh/config scripts/pve-bridge-setup.sh root@<static_ip>:/tmp/
ssh -F ssh/config root@<static_ip> sh /tmp/pve-bridge-setup.sh \
--static-iface "$STATIC_IFACE" --static-ip "${STATIC_IP}/${STATIC_NETMASK}" --dhcp-iface "$DHCP_IFACE"
検証: ip -brief link show type bridge で vmbr0/vmbr1 が UP、ip -brief addr show vmbr0 で正しい IP。
IB セットアップ (IB 搭載サーバのみ):
OS セットアップ完了後、IPoIB を設定して永続化する。IB IP は config/linstor.yml の ib_ip を参照。
scp -F ssh/config scripts/ib-setup-remote.sh pve$N:/tmp/ib-setup-remote.sh
ssh -F ssh/config pve$N "sh /tmp/ib-setup-remote.sh --ip <IB_IP>/24 --mode connected --mtu 65520 --persist"
初回実行時は udev リネーム前に検出され失敗することがある。再実行すれば解決する。
--persist は /etc/network/interfaces.d/ib0 に加えて /etc/modules-load.d/ib_ipoib.conf も書き込む。これにより systemd-modules-load.service が networking.service より前に ib_ipoib モジュールをロードし、リブート後の自動起動が確実になる。
完了: ./scripts/os-setup-phase.sh mark cleanup --config "$CONFIG"
レポート作成: report/ ディレクトリに実行結果のレポートを作成
./scripts/os-setup-phase.sh times --config "$CONFIG" の出力をレポートに転記スキル呼び出し時に ./scripts/os-setup-phase.sh status --config "$CONFIG" で現在の状態を確認し、
完了済みフェーズをスキップして次のフェーズから再開する。
./scripts/os-setup-phase.sh next --config "$CONFIG" で次の未完了フェーズ名を取得できる。
失敗したフェーズは ./scripts/os-setup-phase.sh reset <phase> --config "$CONFIG" でリセットして再実行可能。
特定サーバの 全フェーズを pending に戻して Phase 1 からやり直す 場合、state ディレクトリの中身を一括削除する:
find state/os-setup/<host> -mindepth 1 -delete
./scripts/os-setup-phase.sh init --config config/<host>.yml
⚠️
rm -rf state/os-setup/<host>/*は CLAUDE.md の shell 安全チェックでブロックされる ことが多い (top-level wildcard 検出)。find ... -mindepth 1 -deleteを使うこと (Round 1 s14 で確認)。
Phase 4〜8 では状態変更操作に ./pve-lock.sh を使用する:
./pve-lock.sh run <command...> # 即座に実行（ロック中ならエラー）
./pve-lock.sh wait <command...> # ロック待ち→実行（並列時はこちらを使用）
ロック中の場合は別の課題に着手し、ロック解放後に再開する。
report/2026-05-14_091100_os_setup_18trial_x10dpu_r320.md の 18 trial と
report/2026-05-15_*_18trial_regression_fix.md の後続検証で確定した実運用注意。
racreset soft 後の VirtualMedia 復旧iDRAC7/iDRAC8 で racadm racreset soft を実行すると、BMC リブート後に
VirtualMedia の "Remote File Share" 設定が消失することがある (trial-1-s9 で発生)。
症状: racadm remoteimage -s が Status=Disabled を返し、ISO がマウントされていない。
復旧手順:
./scripts/idrac-virtualmedia.sh mount <bmc_ip> を再実行 (SMB パスは config YAML の vm_smb_path を使う)racadm config -g cfgServerInfo -o cfgServerBootOnce 1 で boot-once を再設定racadm config -g cfgServerInfo -o cfgServerFirstBootDevice VCD-DVD で次ブートを VCD にracadm serveraction powercycle で電源 cycle (warmreboot ではブートデバイスが反映されないことあり)重要:
racreset softは最終手段。VirtualMedia の状態が消えるため、その後の 全ての mount/boot-once 設定をやり直す必要がある。
通しテストを subagent で実行する場合の必須条件:
subagent_type には Opus を選び、明示的な model パラメータで
claude-opus-4-7 を指定する。Monitor で pause すると親への中間応答が
止まり、親が状態を把握できなくなる。長時間待機は Bash(run_in_background=false)
で foreground block するか、sol-monitor.py を foreground 実行する。find state/os-setup/<host> -mindepth 1 -delete を
明記し、/etc/machine-id の mtime が今回の install 開始時刻より新しいことを
確認する手順を入れる。ssh -F ssh/config root@<static_ip> stat -c %Y /etc/machine-id
# → 当該 trial の preseed start epoch (date +%s で記録) より新しいことを確認
subagent プロンプトのテンプレ:
- os-setup スキルを呼び出し、config/<host>.yml で Phase 1-8 を実行する
- 着手前に `find state/os-setup/<host> -mindepth 1 -delete` で完全リセット
- 開始時刻を `date +%s > tmp/<sid>/trial-start-epoch` に記録
- sol-monitor.py には `--installer-syslog tmp/.../installer-syslog.log`,
`--static-ip <static_ip>`, `--preseed-start-epoch $(cat ...)` を渡す
- 完了判定: ssh で /etc/machine-id mtime > trial-start-epoch を確認
- 中間レポートを `report/attachment/<MAIN>/trial-N-s<X>.md` に保存
- Monitor ツールは使わない、長時間待機は Bash foreground 実行
find-boot-entry "ATEN Virtual CDROM" 失敗時のフォールバックX11DPU BIOS 4.0 (4-6 号機) では、find-boot-entry "ATEN Virtual CDROM" が
Boot#### の動的列挙に失敗することがある (trial-1-s4 で発生)。
ATEN Virtual CDROM は UEFI POST 中に VirtualMedia を検出してから初めて
BootOptions に出現するため、検出タイミングのズレで空リターンになる。
フォールバック:
# 1. boot-override で UEFI モードの CDROM を直接指定 (BootOrder 操作なし)
./scripts/bmc-power.sh boot-override <bmc_ip> <user> <pass> Cd UEFI
# 2. ふつうの順序での power on
./scripts/bmc-power.sh on <bmc_ip> <user> <pass>
bmc-power.sh boot-override の引数順序は <bmc_ip> <user> <pass> <target> <mode>
で、<target> は Cd (CDROM), Hdd (HDD), Pxe (PXE)、<mode> は UEFI or Legacy。
順序を間違えると Redfish の Boot.BootSourceOverrideTarget 未受理 (HTTP 400) になる。
boot-override-reset 後の最初の起動で iPXE / 無効 BootEntry に落ちる場合は、
boot-override Hdd UEFI で 1 回ディスク強制ブートを挟むと回復する (trial-1-s5/s6 で確認)。
report/attachment/2026-05-15_073531_18trial_regression_fix/trial-{1,2,3}-s14.md
で確定した R430 固有の preflight。OS install 直前に確認すること。
PERC が HBA mode に切り替わっていた、あるいは過去の trial で Bay 0 や Bay 2-5 が Non-Raid passthrough になっていると、partman の disk discovery で前回 install の LVM/VG が表に出てきて duplicate VG dialog で stuck する。
# 全 PD の状態を確認
ssh -F ssh/config -i ssh/idrac_rsa root@10.10.10.34 \
racadm storage get pdisks -o
# Non-Raid passthrough になっている PD を Ready に戻す
ssh -F ssh/config -i ssh/idrac_rsa root@10.10.10.34 \
racadm storage converttoraid:Disk.Bay.0:Enclosure.Internal.0-1:RAID.Integrated.1-1
ssh -F ssh/config -i ssh/idrac_rsa root@10.10.10.34 \
racadm jobqueue create RAID.Integrated.1-1 --realtime
OS install 対象は Bay 1+6 RAID-1 のみ。それ以外のベイ (0, 2-5, 7) は Non-Raid passthrough にしないこと。Ready 状態 (Raid mode、VD 不所属) が正解。
R430 は mgmt-only NIC (eno2 → 10.0.0.0/8、internet 不可) で OS install する。 debconf の preseed では、
apt-setup/use_mirror=false だけでは不十分mirror/country, mirror/http/hostname, mirror/http/directory, mirror/http/proxy
が残っていると choose-mirror が依然 wget で deb.debian.org に到達を試み、
"Bad archive mirror" dialog で 30 分以上 stuck する (trial-3-s14 で確証)完全 CD-only にする条件 (server7-9.cfg と同等):
### Mirror dialog skipped entirely (no mirror/* lines)
d-i apt-setup/use_mirror boolean false
d-i apt-setup/no_mirror boolean true
d-i apt-setup/cdrom/set-first boolean true
d-i apt-setup/cdrom/set-next boolean false
d-i apt-setup/cdrom/set-double boolean false
d-i apt-setup/cdrom/set-failed boolean false
d-i apt-setup/non-free-firmware boolean true
重要:
mirror/country string manualが残っていると choose-mirror が インタラクティブモードに落ちて入力待ちになる。mirror/* 行は完全削除。cdrom/set-next=falseも必須 (true だと次 CD を待ち bouncer dialog)。
netinst CD (mirror なし) で install するため、tasksel が install しようとするパッケージで 失敗ループを起こすことがある (trial-4-s14 で確認)。
d-i pkgsel/include から curl を削除: netinst CD に curl の依存物が無い場合があり、
tasksel "Select and install software" が失敗ループに陥る。openssh-server sudo wget gnupg 程度に絞る。d-i pkgsel/upgrade select none にすること: mirror なし環境で full-upgrade を選ぶと
upgrade 対象を mirror から fetch できず失敗。none で skip。tasksel tasksel/first multiselect standard は残してよい (CD 内パッケージのみで完結する)。複数 trial を回す場合、前回 install で書かれた LVM PV/VG ヘッダ + GPT partition table が
/dev/sda に残り、partman の atomic recipe が "No root file system is defined" dialog で
stuck する (trial-5-s14 で発生)。preseed に partman/early_command を入れて毎回 disk を
wipe する:
d-i partman/early_command string \
wipefs -a /dev/sda 2>/dev/null || true; \
dd if=/dev/zero of=/dev/sda bs=1M count=10 2>/dev/null || true; \
dd if=/dev/zero of=/dev/sda bs=1M seek=$(($(blockdev --getsz /dev/sda) / 2048 - 10)) count=10 2>/dev/null || true; \
partprobe /dev/sda 2>/dev/null || true; \
:
wipefs -a: superblock 署名 (LVM/MD/GPT) を削除dd (先頭 + 末尾): GPT primary table + GPT backup table の領域をゼロ埋めpartprobe: カーネルに変更を通知server7-9.cfg は sgdisk --zap-all を使う別パターン。R430 では wipefs + dd 方式で
確認済み。
R430 で config/serverN.yml の serial_unit が 0 のとき、preseed の
debian-installer/add-kernel-opts は console=ttyS0 でなければならない (trial 4 直前で
ttyS1 のままだと SOL に installer 出力が流れず black-out)。
config と preseed をペアで管理する場合は generate-preseed.sh の console_order を参照、
手動管理 (preseed-serverN.cfg) の場合は config の serial_unit と整合確認すること。