메뉴
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 まで到達。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
別の tmux ペインで動いている Claude Code インスタンスを、このセッションから tmux send-keys / capture-pane で駆動するオーケストレーション。プランモード投入 → プラン再点検 (1 回目の検証) → ユーザ承認ゲート → auto mode 実装 → レポート未記載追記 → レポート矛盾再チェック (2 回目の検証) の定型フロー。長時間タスクをもう 1 体の claude に「ダブルチェック付きで」実行させ、要所だけ自分が監督したいときに使う。
Fujitsu iRMC S4 (TX1320 M3 等) の電源・BIOS・RAID 操作 + BIOS 設定リファレンス。Redfish (HTTPS + SECLEVEL=0) 経由の電源/ブート操作 + iRMC Web UI/KVM 経由の手動 BIOS/RAID 操作手順 + 全 BIOS 設定項目の網羅リファレンス (bios/)。training-tx1320 対応。
Debian + Proxmox VE OS自動セットアップ。BMC VirtualMedia経由でpreseedインストール、PVEインストールまでを実行する。
Supermicro X11DPU/X10DRT-P BIOS Setup 操作。KVM スクリーンショット + キーストロークで BIOS メニューを操作する。BIOS 設定変更、確認、保存を行う。4-6号機 + 10号機対応。
iDRAC7 基本操作。SSH 経由で racadm コマンドを実行し、サーバ管理を行う。
LINSTOR/DRBD ノードの離脱・復帰操作。障害シミュレーション、回復、正常離脱、再参加を行う。
| name | pxe-deploy |
| description | 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 まで到達。 |
| argument-hint | <config_file> |
BMC VirtualMedia (CD/USB redirector) を使わずに PXE/netboot で OS install する経路。 BMC USB redirector の累積劣化 (os-setup 経路が失敗する機種) や、 host が cross-site 拠点にあって install ISO の大容量 cross-site 転送が間欠 loss で失敗するケースに使う。 Phase 19 で training-tx1320 にて完遂、 claude が物理操作なしで自力 SSH 到達まで達成 (commit dbb936a、 phase19 総括)。
この節だけを上から順に実行すれば training-tx1320 の通常 OS install + PVE が完遂する。 sonnet サブエージェントはまずこの節を実行し、詳細・背景が必要なときだけ下の該当節を参照する。 対象は ステップ2〜6 (deploy → install監視 → disk boot → IP特定 → PVE通し)。 ステップ1 (BIOS HII KVM RAID Clear) は呼出元 (opus) が実施済みの前提。install 中の preseed
partman/early_commandで storcli が RAID10 を delete+create するため、RAID 再構築は install が行う。確立: 2026-06-03 (本 runbook 化) / 基盤の 3 試行実証は e2e report。
| 項目 | 値 |
|---|---|
| config | config/training_tx1320.yml |
| BMC (iRMC) | 10.254.254.9 / claude / Claude123 |
| deploy ISO basename | ipxe-tx1320.iso (playground NFS export /var/samba/public に配置済み) |
| playground | 10.1.6.6 (nginx access.log = /var/log/nginx/access.log、firmware/preseed 配信) |
| eno2 MAC (dark-net、SSH 用) | 4c:52:62:14:de:f0 |
| storcli64 取得元 | http://10.1.6.6/firmware/storcli64.bin |
| 管理 IP (固定) | 10.1.4.16 (vmbr1=eno2 dark-net static) |
🆕 2026-06-19: bridge 構成 + 固定 IP 化。
config/training_tx1320.ymlにbridge_setup: true+secondary_bridge_address: "10.1.4.16/8"を追加し、install 後の/etc/network/interfacesが vmbr0 (eno1=site LAN, DHCP) + vmbr1 (eno2=dark-net, static10.1.4.16/8) の PVE ブリッジ構成に なった (generate-preseed.shの dhcp+bridge_setup ブランチが生成、pkgsel にbridge-utils追加で 初回ブートから ifupdown で起動)。管理/SSH は固定10.1.4.16を使う → 下記 Step 5 の eno2 DHCP IP 特定 (ping-sweep +ip neigh | grep MAC) は 不要 になり、tx1320-pve-setup.sh config/... 10.1.4.16を直接渡せる (reboot を跨いでも IP 不変、#12 解消)。ssh/config にHost training-tx1320 10.1.4.16追加済。 旧 DHCP 経路 (eno2 が 10.254.254.x lease) を使いたい場合は config のbridge_setupを外す。
mkdir -p tmp/<sid> # <sid> = Claude Code セッション UUID 先頭8桁
ping -c3 -W2 10.254.254.9 # iRMC 疎通 (latency 高めだが loss 0 を確認)
ping -c3 -W2 10.1.6.6 # playground 疎通
ssh -F ssh/config ubuntu@10.1.6.6 ls -l /var/www/html/preseed /var/www/html/firmware /var/samba/public
# 期待: preseed/training-tx1320.cfg, firmware/{storcli64.bin,setup-raid10-storcli.sh,phonehome-setup.sh},
# /var/samba/public/ipxe-tx1320.iso が存在すること
export BMC_SCHEME=https BMC_CURL_OPTS="--ciphers DEFAULT@SECLEVEL=0"
export BMC_PATCH_REQUIRES_ETAG=1 BMC_BOOT_OVERRIDE_NO_DISABLED=1 POWER_ON_RESET_TYPE=On
未 export だと
bmc-power.shが rc=52 (empty reply、cipher なしで TLS 失敗、落とし穴 #10)。irmc-ipxe-cd-deploy.shは内部で自前 export するが、自分で叩く bmc-power.sh のために export しておく。
./oplog.sh ./scripts/irmc-ipxe-cd-deploy.sh config/training_tx1320.yml ipxe-tx1320.iso
DisconnectCD → CDImage(NFS)設定 → VirtualMediaServiceRestart (USB redirector 劣化リセット) → On → ConnectCD(検証+リトライ) → ForceOff → boot-override Cd UEFI (Off で設定) → On。deploy 中の
disconnect-cdHTTP400 / PowerOnActionParameterValueNotInListは|| trueガード済みで無害。 🐛 ConnectCD は ForceOff 直後の即再 deploy で HTTP 500 を返すことがある (iRMC CD worker 不整合、 試行9)。放置すると CD 未接続のまま boot-override Cd が設定され旧 HDD GRUB から起動するサイレント 失敗になる → スクリプトは ConnectCD が 204 を返すまで VirtualMediaServiceRestart + リトライ (最大4回)、 ダメなら deploy を abort する (試行9 で対策)。deploy がConnectCD did not return 204で abort したら そのまま Step 2 をもう一度実行する。
.venv/bin/python scripts/sol-monitor.py --bmc-ip 10.254.254.9 --bmc-user claude \
--bmc-pass Claude123 --log-file tmp/<sid>/install.log --timeout 2400 --powerstate-interval 30
interface=eno1 固定で恒久対策済みだが、タイミング依存で再発しうる
(実測発生率 ~30-50%、試行1/2/6 で発生)。deploy(電源 On)から合計 ~10min 経っても
CONFIGURING_APT に進まず DETECTING_NETWORK 等で停滞なら d-i netcfg stuck と判断
(= DETECTING_NETWORK 突入後 ~6-7min 動かない状態)。./scripts/bmc-power.sh forceoff 10.254.254.9 claude Claude123
→ Step 2 から再 deploy。2 回目 attempt は +3〜4min で CONFIGURING_APT 到達 = 即解消する
(試行1で実証)。10min は安全な閾値 (15min まで待つ必要はない)。
sol-monitor.py は rc=4 (false positive) で返る — POWER_DOWN
でなく途中打ち切りのため (試行9 で観測)。これは異常ではなく ForceOff した結果なので無視してよい。
完遂判定は再 deploy 後の sol-monitor が rc=0 になることで行う。./oplog.sh ./scripts/bmc-power.sh boot-override 10.254.254.9 claude Claude123 Hdd UEFI
./oplog.sh ./scripts/bmc-power.sh on 10.254.254.9 claude Claude123
sh tmp/<sid>/find-ip.sh # 下記内容のスクリプトを Write してから実行 (パイプ/$()は分割禁止のため)
tmp/<sid>/find-ip.sh の内容 (1〜254 を ping して ARP 充填 → eno2 MAC で IP 抽出):
#!/bin/sh
j=1; while [ "$j" -lt 255 ]; do ping -c1 -W1 "10.254.254.${j}" >/dev/null 2>&1 & j=$((j+1)); done; wait
ip neigh | grep -i '4c:52:62:14:de:f0' | awk '{print $1}' | grep -E '^10\.254\.254\.' | head -1
disk boot 後 eno2 DHCP は通常 +2〜4min で取得 (
auto eno2化で #14 解消済み)。出なければ 1〜2 分 待って再実行。tx1320-pve-setup.shも内部で同じ MAC 再 discovery を行うので、ここで未取得でも 概ね進められるが、初期 IP は渡す必要がある。
./oplog.sh ./scripts/tx1320-pve-setup.sh config/training_tx1320.yml <ip>
⚠️ このコマンドの出力 (background task の .output) は巨大になりうる — 初回 PVE install の
Processing triggersでW: Tried to start delayed item ceph-common ...警告が百万行単位出ること がある (試行8 で 119MB、無害)。ログ全体を Read しない —grep -v "W: Tried"や末尾tail相当を スクリプト経由で抽出してDONE. Final reachable IP行と検証ブロックだけ確認する。 known_hosts の stale key 掃除は不要 — スクリプトが-o UserKnownHostsFile=/dev/nullを使うため IP 使い回し時の鍵不一致 ("REMOTE HOST IDENTIFICATION HAS CHANGED") は起きない (試行2 で対策済み。StrictHostKeyChecking=noだけでは鍵 MISMATCH は拒否される点に注意)。 SSH待ち → live hostname (tx1320) を /etc/hosts に採用 (config のtraining-tx1320を盲信しない、 でないと pve-cluster 不起動) → pre-reboot(PVE repo+kernel) → reboot → post-reboot(proxmox-ve) → reboot → 検証。eno2 lease が reboot で変わってもdiscover_by_mac(MAC 再 discovery) で追従する。
ssh -F ssh/config -o StrictHostKeyChecking=no root@<ip> pveversion # PVE 9.x
ssh -F ssh/config -o StrictHostKeyChecking=no root@<ip> systemctl is-active pveproxy pvedaemon pve-cluster # 全 active
curl -sk --max-time 15 https://<ip>:8006 -o /dev/null -w '%{http_code}\n' # 200
RAID10 Optimal の直読: tx1320-pve-setup.sh の検証ステップが storcli64 を playground から自動取得
して /c0/vall show を出力する (試行2 で組込み)。その出力に RAID10 ... Optl ... 1.6xx TB が出れば OK。
出ない/フォールバックしたい場合のみ下記を手動実行:
sh tmp/<sid>/verify-raid.sh # 下記を Write してから実行
tmp/<sid>/verify-raid.sh:
#!/bin/sh
ssh -F ssh/config -o StrictHostKeyChecking=no "root@<ip>" "test -x /usr/local/bin/storcli64 || (wget -q -O /usr/local/bin/storcli64 http://10.1.6.6/firmware/storcli64.bin && chmod +x /usr/local/bin/storcli64); /usr/local/bin/storcli64 /c0/vall show"
期待:
RAID10 ... Optl ... 1.6xx TB。lsblkで sda 1.6T 単一ディスク + LVM (tx1320-vg) も傍証。
- 試行番号: N
- 結果: 成功 / 失敗 (どのステップで)
- 所要時間: deploy→SSH 到達 ~XX min
- 最終 IP (eno2): 10.254.254.X
- install retry: 0/1 回 (#15 発生有無)
- 踏んだ落とし穴 / 想定外: ...
- 検証結果: pveversion=... / services=... / web UI=HTTP ... / RAID10=Optl ... TB
- runbook の曖昧点・改善提案: ... (opus が次試行に反映する。無ければ「なし」)
sol-monitor.py は必ず Bash の foreground (ブロッキング) で実行する。run_in_background:true
を使わない。背景実行して「通知を待つ」とターンを終えてしまうと、サブエージェントは
install 完了通知を受け取れず作業が途中で止まる (試行3 で実際に発生)。foreground なら
Bash 呼び出しが install 完遂まで (最大 timeout) ブロックして返る — それを待つのが正しい。tmp/<sid>/ のみ (/tmp/ 禁止)。$()/; 複合・< リダイレクトを含むコマンドはスクリプトファイルに書いて sh tmp/<sid>/x.sh。./oplog.sh 経由。スクリプトは必ず ./ 付き相対パスで実行。各試行前に opus が BIOS HII KVM Clear (RAID 空に) → sonnet が上記 runbook で通常セットアップを自律実行。
| 試行 | 結果 | install retry (#15) | 最終 eno2 IP | PVE | web UI | RAID10 | sonnet が踏んだ点 / runbook 改善 |
|---|---|---|---|---|---|---|---|
| 1 | ✅ 自律成功 | 1 (DETECTING_NETWORK ~10min 停滞→ForceOff+retry で +3min 解消) | .16 | 9.2.3 | 200 | Optl 1.635TB | nginx access.log が空 = 進捗判定は sol-monitor stage に一本化 (runbook 反映済)。storcli は target に無く verify-raid.sh の wget 取得で直読 (runbook 記載どおり動作)。最終 reboot で IP 変動 (#12、MAC rediscovery で追従) |
| 2 | ✅ 自律成功 | 1 (#15 再発→runbook 通り ForceOff+retry で解消) | .16 | 9.2.3 | 200 | Optl 1.635TB | 🐛 known_hosts stale key 衝突で SSH 拒否 (IP 使い回しで旧鍵が残り StrictHostKeyChecking=no でも MISMATCH 拒否)。sonnet は手動 ssh-keygen -R で回避 → tx1320-pve-setup.sh に -o UserKnownHostsFile=/dev/null を追加して恒久対策。併せて検証ステップに storcli64 自動取得+直読を組込み |
| 3 | ⚠️ opus 補完 (sonnet yield) | 0 (#15 なし) | .16 | 9.2.3 | 200 | Optl 1.635TB | 🚨 sonnet が sol-monitor.py を run_in_background:true で起動し「通知を待つ」とターンを終えて install 監視中に停止 (制御を opus に返した)。install 自体は健全で opus が disk boot 以降を引き継ぎ完遂 → runbook/プロンプトに「sol-monitor は foreground 必須・最終報告まで絶対 yield しない」を明記。storcli 直読・UserKnownHostsFile 修正の効果は本試行で確認 (スクリプトが RAID10 Optl を直接出力、鍵警告は /dev/null 行きで無害) |
| 4 | ✅ 自律成功 | 0 (#15 なし) | .16 | 9.2.3 | 200 | Optl 1.635TB | anti-yield 対策の効果を確認 — sonnet は sol-monitor を background 起動したが出力を定期 Read して完了 (exit 0) を待ち、yield しなかった (試行3 の失敗モードを克服)。install 21.5min と長め = cross-site link 速度依存 (kernel DL ~5min)。install 時間は 10〜25min の幅がある (mirror/link 速度依存) |
| 5 | ✅ 自律成功 | 0 (#15 なし) | .16 | 9.2.3 | 200 | Optl 1.635TB | harness が sol-monitor を自動 background 化したが Read ポーリングで完遂 (yield せず)。最終 reboot で IP .23→.16 変動時、wait_ssh が死んだ旧 IP に 420s 無駄待ち → wait_ssh を「既知 IP と MAC 再 discovery を毎サイクル交互」にインターリーブ化して無駄待ちを解消 |
| 6 | ✅ 自律成功 | 1 (#15、合計 9.8min で ForceOff→即解消) | .16 | 9.2.3 | 200 | Optl 1.635TB | 新規ブロッカーなし。#15 を runbook 閾値手順どおり処理。anti-yield / wait_ssh interleave / storcli 直読すべて機能。#15 閾値を「deploy から合計 ~10min」と明確化 |
| 7 | ✅ 自律成功 | 0 (#15 なし) | .16 | 9.2.3 | 200 | Optl 1.635TB | クリーン完走・改善提案なし (収束)。runbook 無修正で完遂。opus 側 BIOS Clear で ArrowRight ドロップ (Main 居残り) → shot 検証 + 再送で吸収 (手順の堅牢性を実証) |
| 8 | ✅ 自律成功 | 1 (#15、10.3min で ForceOff→5.2min 解消) | .16 | 9.2.3 | 200 | Optl 1.635TB | 初回 PVE install で apt deferred trigger 警告 W: Tried to start delayed item が ~220万行 (119MB) 出力 (無害)。sonnet は grep/tail で対処 → runbook に「PVE setup ログは巨大化しうる・全 Read 禁止」注記。BIOS Clear は再び ArrowRight ドロップ→再送で吸収 |
| 9 | ✅ 自律成功 (再実行) | 1+ (#15×2 + ConnectCD500) | .16 | 9.2.3 | 200 | Optl 1.635TB | 初回エージェントが API ConnectionRefused (インフラ) で中断 → 再 spawn。🐛 ConnectCD HTTP500 バグ発見 — ForceOff 直後の即再 deploy で iRMC CD worker 不整合 → \|\| true で握り潰され CD 未接続のまま boot-override Cd 設定 → 旧 HDD GRUB 起動のサイレント失敗 (RAID clear 済で initramfs ループ)。sonnet は再 deploy で自己回復 → irmc-ipxe-cd-deploy.sh の ConnectCD を「204 まで VirtualMediaServiceRestart+リトライ、ダメなら abort」に強化 |
| 10 | ✅ 自律成功 | 0 (#15 なし) | .16 | 9.2.3 | 200 | Optl 1.635TB | クリーン完走・改善提案なし (収束)。anti-yield / wait_ssh interleave / storcli 直読 / ConnectCD リトライすべて機能 |
10 試行サマリ (2026-06-03〜04, session 4dbf313d): 全 10/10 が PVE 9.2.3 + web UI 200 + RAID10 Optl 1.635TB を達成。
9/10 が完全 sonnet 自律 (試行3 のみ sonnet の途中 yield で opus 補完 → 対策後は再発せず、試行4-10 で 7 連続自律成功)。
試行9 初回の中断は API ConnectionRefused = インフラ起因 (再 spawn で成功)。判明・恒久対策した点 (すべて
runbook/スクリプトに反映済み): 進捗判定 = sol-monitor stage (nginx 不可) / #15 は deploy から合計 ~10min 停滞で
ForceOff→retry / sol-monitor は foreground・最終報告まで yield 禁止 / UserKnownHostsFile=/dev/null で鍵不一致回避 /
wait_ssh interleave で IP 変動追従 / storcli 自動取得で RAID10 直読 / ConnectCD 500 リトライで HDD fall-through 防止 /
PVE setup ログ巨大化は grep/tail。通常セットアップ (deploy→PVE) は sonnet が runbook 参照のみで自律完遂可能と確定。
sonnet 自律実行の成立を試行1-2で確認、試行4 で再確認 (3/4 が完全自律、試行3 のみ opus 補完)。 試行3 で最大の落とし穴 = sonnet の途中 yield が判明し対策 → 試行4 で克服を確認。判明した 恒久対策: (a) 進捗判定は nginx でなく sol-monitor stage、(b) #15 は sol-monitor 停滞 ~10min を閾値に ForceOff→retry、(c) known_hosts 鍵不一致 →
UserKnownHostsFile=/dev/null(試行2)、(d) sol-monitor は foreground 実行・最終報告まで yield 禁止 (試行3-4、runbook「sonnet 実行上の制約」+ プロンプトに明記)。 install 所要は 10〜25min (cross-site link 速度依存)、PVE setup は ~30-55min。
| 状況 | 推奨経路 |
|---|---|
| Supermicro / iDRAC で BMC VirtualMedia 健全、 同一拠点 | os-setup スキル (BMC ISO mount + preseed、 短時間で完遂) |
| iRMC S4 で USB redirector 累積劣化 (POST 99 stuck、 FW update でも回復せず) | 本 skill (PXE pivot で完全 bypass) |
| cross-site 設置で大容量 ISO 転送が間欠 loss で破綻 (138KB 帯で時間 RST) | 本 skill (kernel/initrd は host のインターネット経由で公開 mirror から取得) |
| 闇ネット (10.0.0.0/8) 経由で SSH 検証したい (NAT 背後 LAN 不達) | 本 skill (両 NIC DHCP + ip neigh で dark-net IP 特定) |
OpenWrt (拠点 LAN gateway) ──ローカル TFTP──→ 完全 embed ipxe.efi (chainload なし)
│ 再 DHCP で gateway 付き lease 取得
▼
ftp.jp.debian.org 153.127.75.11 (IPv4 リテラル) ──→ kernel + initrd (host インターネット経由、 cross-site 回避)
▼
d-i ──→ preseed http://<playground>/preseed/... (cross-site 小容量 12KB のみ、 link 劣化でも完走)
──→ storcli64.bin http://<playground>/firmware/ (d-i busybox wget で 8MB 完走、 iPXE と違い堅牢)
──→ base system deb.debian.org (host インターネット、 公開 mirror)
──→ phone-home (任意、 nginx access.log で IP 受信、 cross-site 不通時は ip neigh で代替)
──→ poweroff
install 後: boot-override=Hdd で disk boot ──→ eno2 闇ネット IP で claude 自力 SSH
firmware PXE-ROM boot は OpenWrt 側に dnsmasq ローカル TFTP + dhcp_boot=ipxe.efi の設定を要する。
この OpenWrt 特別設定への依存を排除したい場合 (または PXE NIC が boot order に無い場合)、同じ embed ipxe.efi を
最小 UEFI ISO に焼いて BMC Virtual Media で起動する。iPXE が起動した後は通常の PXE 経路と全く同じ
(DHCP→IPv4 リテラル mirror から kernel/initrd→playground HTTP から preseed/storcli→iPXE loader で kernel 起動)。
OpenWrt は 通常 DHCP リースを配るだけ でよい。2026-05-31 (vmnfs531) に training-tx1320 で完遂
(report)。
BMC Virtual Media (NFS/SMB) ──→ ipxe-<host>.iso (bootx64.efi = embed ipxe.efi)
│ boot-override Cd → iPXE 起動 (firmware StartImage を使わない)
▼ 以降は上の「アーキテクチャ」と同一 (DHCP→mirror→preseed→install)
なぜ full Debian ISO の Virtual Media boot ではダメか: 古い UEFI firmware (例 Fujitsu D3373 BIOS R1.22.0 2018 /
iRMC S4 FW 9.69F) では GRUB 2.12 が Debian 13 の 6.12 kernel を起動できない。GRUB は kernel を firmware の
StartImage (LoadImage) 経由で起動しようとし、firmware が start_image() returned 0x8000000000000001
(EFI_LOAD_ERROR) で拒否 → kernel printk ゼロのまま GRUB に戻る triple-fault reset loop。standalone grub も
純正 shim 経由の grub も同じ (shim は無言で GRUB に戻る)。iPXE は独自 loader で kernel を起動するため回避できる
(= PXE が成功する理由)。よって full-ISO Virtual Media は当該 firmware では dead end、iPXE-on-CD が正解。
# 1. embed ipxe.efi を最小 UEFI ISO に焼く (playground の ipxe.efi を取得して)
scp playground:/var/www/html/ipxe.efi tmp/<sid>/ipxe.efi
./scripts/build-ipxe-iso.sh tmp/<sid>/ipxe.efi tmp/<sid>/ipxe-<host>.iso
# BMC が読む場所 (iRMC の NFS export = playground:/var/samba/public) に置く
scp tmp/<sid>/ipxe-<host>.iso playground:/tmp/ && ssh playground "sudo mv /tmp/ipxe-<host>.iso /var/samba/public/"
# 2. Virtual Media で attach + boot (config 駆動)
./scripts/irmc-ipxe-cd-deploy.sh config/<host>.yml ipxe-<host>.iso
# → DisconnectCD → config(NFS) → VirtualMediaServiceRestart → On → ConnectCD → ForceOff → boot-override Cd → On
# 3. 監視 (PXE 経路と同じ。SOL kernel printk + nginx fetch が真の進捗)
.venv/bin/python scripts/sol-monitor.py --bmc-ip <ip> --bmc-user claude --bmc-pass <pass> --log-file install.log --timeout 1800
# 4. install 完遂後 disk boot
export BMC_SCHEME=https BMC_CURL_OPTS="--ciphers DEFAULT@SECLEVEL=0" BMC_PATCH_REQUIRES_ETAG=1 BMC_BOOT_OVERRIDE_NO_DISABLED=1 POWER_ON_RESET_TYPE=On
./scripts/bmc-power.sh boot-override <ip> claude <pass> Hdd UEFI ; ./scripts/bmc-power.sh on <ip> claude <pass>
ConnectCD 204 + IsAnyVirtualMediaActive:true
を返すのに host 側 /dev/sr0 は "No medium found"。対策 = POST /redfish/v1/Managers/iRMC/Actions/Oem/FTSManager.VirtualMediaServiceRestart
body {"VirtualMediaType":"CD"} で Virtual Media worker を再起動 (irmc-ipxe-cd-deploy.sh が自動実行)。PowerState=On 必須 (Off だと HTTP 400 ActionParameterValueNotInList)。接続済みなら allowable が DisconnectCD。接続は ForceOff をまたいで持続。PowerState=Off で設定 → PowerOn の順 (On 中設定 + cycle は内蔵ディスク起動に化ける)。/redfish/v1/Systems/0/BootOptions 未提供 (boot-next で CD 直接指定不可、boot-override の class 指定のみ)。training-tx1320 に対し「BIOS HII Clear Configuration → iPXE-CD deploy → preseed+storcli RAID10 → 検証」を 10 回連続ре反復し 10/10 成功 (RAID10 Optl 1.635TB を全 run で SSH 裏取り、 report 2026-06-02_122133_tx1320_ipxe_cd_hii_clear_10run)。観察:
irmc-ipxe-cd-deploy.sh の VirtualMediaServiceRestart で USB redirector 劣化を毎回回避。10 連続 deploy で CD 提示失敗ゼロ (Phase 15-18 の劣化問題は本経路では再現せず)。interface=auto のままでも #15 (d-i netcfg stuck) は 0/10 — 本検証で使った embed ipxe.efi は旧 interface=auto 版だったが netcfg stuck は一度も起きなかった。これは #15 が タイミング依存の非決定的事象 (eno2 link-up が netcfg と重なるか) であることを裏付ける。PXE-TFTP 経路の 10-run では同じ interface=auto で 30% 発生したのと対照的。ただし interface=eno1 固定 (決定論的解消) は引き続き推奨 — 0/10 は「起きなかった」であって「起きない」ではない。console=ttyS0 のため VGA はブランク (d-i は SOL に出る)。OEM screenshot で d-i は撮れない → 進捗は SOL log + playground nginx access.log (preseed/storcli/phonehome GET) が一次情報。installed system は VGA tty1 に getty が出る (login プロンプト撮影可)。/tmp/tftp/ に置く (tmpfs、 OpenWrt 再起動で消えるので再配置必要)。 dnsmasq 設定: enable_tftp=1、 tftp_root=/tmp/tftp、 dhcp_boot=ipxe.efi (server 省略=dnsmasq 自身)/preseed/<host>.cfg + /firmware/{storcli64.bin,setup-raid10-storcli.sh,phonehome-setup.sh} + /ipxe.efi 配信。 iPXE build 環境 (/tmp/ipxe-build/ipxe/src/ の git clone) も置くNetworkStack=Enabled + IPv4PxeSupport=Enabled 必須 (irmc-bios-raid skill の bios apply-config で BSPBR 経由設定)。 これが Disabled だと UEFI PXE boot option が生成されず boot-override Pxe が BIOS Setup に落ちるnetwork_mode: dhcp + static_iface: <PXE NIC> + dhcp_secondary_iface: <別 NIC> を config/<host>.yml に設定 (両 NIC DHCP で闇ネット側 NIC が IP 取得)scripts/generate-preseed.sh --pxe (cdrom 依存削除 + HTTP storcli fetch + phone-home setup)、 scripts/bmc-power.sh (boot-override)、 scripts/sol-monitor.py (完遂判定)、 scripts/irmc-oem-screenshot.sh (実画面確認)scripts/irmc-virtualmedia.sh disconnect-cd、 PXE 経路では使わず redirector 状態を clean に)"Pxe" が含まれることを確認config/<host>.yml に記載、 または iRMC EthernetInterfaces で MACAddress 確認)config の bios_settings.supported に追加:
NetworkStack: "Enabled"
IPv4PxeSupport: "Enabled"
irmc-bios-raid skill の bios apply-config で BSPBR backup → edit → restore → cycle (boot phase で適用)。
apt install nginx ipxe + nginx で /var/www/html/ 配信 (autoindex on)uci set dhcp.@dnsmasq[0].enable_tftp='1'
uci set dhcp.@dnsmasq[0].tftp_root='/tmp/tftp'
uci set dhcp.@dnsmasq[0].dhcp_boot='ipxe.efi' # server 省略=dnsmasq 自身
uci commit dhcp
/etc/init.d/dnsmasq restart
wget http://<playground>/ipxe.efi -O /tmp/tftp/ipxe.efi # OpenWrt 再起動で再配置必要
./scripts/generate-preseed.sh --pxe config/<host>.yml > /tmp/<host>.cfg
scp /tmp/<host>.cfg ubuntu@<playground>:/tmp/ && ssh ... sudo mv /tmp/<host>.cfg /var/www/html/preseed/<host>.cfg
# storcli64.bin + setup-raid10-storcli.sh + phonehome-setup.sh も /var/www/html/firmware/ に配置
# iRMC は bmc-power.sh 呼び出し前に config の bmc env を export する (#10)。
# これを忘れると cipher なしで TLS 失敗 → rc=52 (empty reply)。
export BMC_SCHEME=https BMC_CURL_OPTS="--ciphers DEFAULT@SECLEVEL=0"
export BMC_PATCH_REQUIRES_ETAG=1 BMC_BOOT_OVERRIDE_NO_DISABLED=1 POWER_ON_RESET_TYPE=On
./oplog.sh ./scripts/bmc-power.sh boot-override <BMC_IP> claude Claude123 Pxe UEFI
./oplog.sh ./scripts/bmc-power.sh forceoff <BMC_IP> ... # sleep 30
./oplog.sh ./scripts/bmc-power.sh on <BMC_IP> ...
.venv/bin/python scripts/sol-monitor.py --bmc-ip ... --log-file install.log --timeout 2700
# nginx access.log を tail で並行観察 (preseed/firmware/phonehome fetch が真の進捗)
要所で OEM screenshot を撮影 (DHCP→gateway→kernel fetch→d-i→login prompt)。 sol-monitor の stage 検出は SOL ring buffer replay で誤検出するので、 真の進捗は nginx fetch で判定。
./oplog.sh ./scripts/bmc-power.sh boot-override <BMC_IP> ... Hdd UEFI # PXE loop 回避
./oplog.sh ./scripts/bmc-power.sh on <BMC_IP> ...
phone-home が cross-site 不通で届かなくても OK:
ssh playground "ip neigh | grep <eno2-MAC>" # 闇ネット IP を特定
# または: 自 host で `ip neigh | grep <eno2-MAC>`
ssh -F ssh/config -i ssh/id_ed25519 root@<dark-net-IP> "lsblk; /usr/local/bin/storcli64 /c0/vall show || (wget -O /usr/local/bin/storcli64 http://<playground>/firmware/storcli64.bin && chmod +x /usr/local/bin/storcli64 && /usr/local/bin/storcli64 /c0/vall show)"
scripts/tx1320-pve-setup.shinstall が入れるのは Debian + RAID10 まで。PVE は post-install の SSH ステップ
(pve-setup-remote.sh の pre-reboot/post-reboot) で入れる。これを 1 コマンド化したラッパー:
./oplog.sh ./scripts/tx1320-pve-setup.sh config/training_tx1320.yml <dark-net-IP>
# pre-reboot(PVE repo+kernel) → reboot → post-reboot(proxmox-ve) → reboot → verify
# 検証: pveversion / pveproxy・pvedaemon・pve-cluster active / https://<ip>:8006 = HTTP 200
通し検証で確定した PVE ステップの落とし穴 (2026-06-02 session 6d0368bf、3試行):
tx1320 (config の training-tx1320 ではない)。PVE は自 hostname を
/etc/hosts で非ループバック IP に解決できないと pve-cluster が起動しない。ラッパーは
ssh root@ip hostname で live hostname を取得して pve-setup-remote.sh --hostname に渡す
(config 値を盲信しない)。これで pve-cluster active を確認。wait_ssh は
timeout 後に /24 ping-sweep で neigh を populate → eno2 MAC で再 discovery して IP を差し替える
(config の eno2_mac を使用)。ip neigh | grep だけでは ping-sweep なしだと neigh が stale/空で
発見できない — 必ず先に ping-sweep する。default via 192.168.33.1 dev eno1 (拠点 LAN) が生きていれば OK。
pve-setup-remote.sh の z-fix-default-route フックは本拠点 GW (10.10.10.1/192.168.39.1) を
ハードコードするが、既に default route がある限り if no default ガードで発火せず無害。ssh/known_hosts に stale entry が残る → host key 警告。
ssh-keygen -f ssh/known_hosts -R <ip> で掃除 (SSH 自体は StrictHostKeyChecking=no で接続可)。RAID→PVE 通しの全体像: ① BIOS HII KVM Clear (irmc-bios-raid skill、繰り返しテスト時の確実な RAID 初期化) → ②
irmc-ipxe-cd-deploy.sh ... ipxe-tx1320.iso(deploy) → ③ sol-monitor (install) → ④bmc-power.sh boot-override Hdd UEFI+ on (disk boot) → ⑤ eno2 MAC で IP discovery → ⑥tx1320-pve-setup.sh(PVE) → ⑦ pveversion/8006 検証。deploy ISO basename はipxe-tx1320.isoを明示指定(既定ipxe-<hostname>.isoではない)。
| # | 壁 | 真因 | 対策 |
|---|---|---|---|
| 1 | boot-override Pxe が BIOS Setup に落ちる | BIOS NetworkStack: Disabled | BSPBR で NetworkStack=Enabled + IPv4PxeSupport=Enabled |
| 2 | TFTP RRQ 反復、 ipxe.efi 転送失敗 | TFTP-through-NAT (data の新 port が SNAT で ICMP reject) | OpenWrt dnsmasq ローカル TFTP で配信 (NAT 越え不要、 同一 segment) |
| 3 | d-i netcfg segfault | cmdline interface=eth0 が renamed eno1 と不一致 | interface=auto |
| 4 | "Continue without default route?" で停止 | 闇ネット DHCP が gateway 通知せず、 preseed 適用前に dialog | cmdline netcfg/no_default_route=true |
| 5 | iPXE chainboot 失敗 (iPXE>) | boot script を cross-site から chainload → 間欠 100% loss で 443B 取得失敗 | 全 boot ロジックを ipxe.efi に embed (chainload 排除) |
| 6 | iPXE kernel fetch が ~138KB で Connection reset | cross-site リンク劣化 (時間ベース RST、 iPXE HTTP 固有。 d-i wget は同リンクで 8MB 完走) | kernel/initrd を ftp.jp.debian.org (host インターネット経由) から取得 |
| 7 | deb.debian.org で Network unreachable | iPXE が dual-stack の AAAA(IPv6) / DNS で詰まる (OpenWrt 自体は到達可) | IPv4 リテラル 153.127.75.11 を直書き (CDN は Host ヘッダ依存で IP 不可、 実 mirror の IP) |
| 8 | DHCP レース (gateway 有/無) | host NIC segment に 2 DHCP (拠点 LAN gateway 有 / 闇ネット gateway 無) | iPXE isset ${net0/gateway} || goto re-dhcp で gateway 付き lease 取得まで再 DHCP |
| 9 | installed host の IP 特定 (自力 SSH) | phone-home は cross-site 不達、 だが片方の NIC が闇ネット IP 取得 | ip neigh | grep <eno2-MAC> で playground/local ARP から特定 |
# iPXE source を /tmp/ipxe-build/ に clone (初回のみ)
apt install -y build-essential liblzma-dev mtools git
git clone --depth 1 https://github.com/ipxe/ipxe.git /tmp/ipxe-build/ipxe
embed する boot script tx1320-embed.ipxe (キモ: 再 DHCP→gateway→IPv4 リテラルから kernel/initrd):
#!ipxe
echo === pvese embedded iPXE ===
:dl
echo Acquiring DHCP (need gateway for internet)...
dhcp net0 || goto slow
echo IP=${net0/ip} GW=${net0/gateway}
isset ${net0/gateway} || goto nogw
kernel http://153.127.75.11/debian/dists/trixie/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux auto=true priority=critical preseed/url=http://<playground>/preseed/<host>.cfg interface=eno1 netcfg/no_default_route=true hostname=<host> domain=local console=ttyS0,115200n8 earlyprintk=ttyS0,115200n8 loglevel=8 ignore_loglevel || goto retry
initrd http://153.127.75.11/debian/dists/trixie/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz || goto retry
boot || shell
:nogw
sleep 3
goto dl
:slow
sleep 5
goto dl
:retry
sleep 5
goto dl
ビルド + 公開:
cd /tmp/ipxe-build/ipxe/src
cp tx1320-embed.ipxe ./
make -j$(nproc) bin-x86_64-efi/ipxe.efi EMBED=tx1320-embed.ipxe
sudo cp bin-x86_64-efi/ipxe.efi /var/www/html/ipxe.efi # OpenWrt が wget で取得する HTTP 公開
|| がないと script 全体 abort — kernel ... && initrd ... && goto ok は kernel 失敗で script 終了する。 kernel ... || goto retry で || で受けるのが正。set <custom>/inc は "Operation not supported" で使えない build がある。 built-in (${net0/ip} / ${net0/gateway} / isset / goto / :label / sleep / dhcp net0) は可。interface=<PXE NIC> で install NIC を固定する (TX1320 は interface=eno1)。 interface=auto だと、 install NIC でない方の NIC (例: eno2=dark-net) の link-up が d-i netcfg 中に発生したとき、 d-i が 2 NIC 両方に IPv6 autoconfiguration を実行して timeout が累積し、 preseed GET が来ず netcfg がスタックする (10-run 検証の落とし穴 #15、 発生率 30%)。 PXE NIC は embed iPXE の isset ${net0/gateway} || goto nogw で gateway-bearing な site LAN ポート (= eno1) に確定するので、 そこへ固定すれば netcfg は反対側 NIC を完全に無視する。 preseed 内の netcfg/choose_interface では間に合わない (preseed はネットワーク越し取得 = netcfg が走り終わった後にしか読まれない) — cmdline が唯一のレバー。ip neigh | grep <eno2-MAC> で特定 (DHCP のため reboot 変動)。NetworkStack を有効化、 SOL は ttyS0、 OEM screenshot で実画面確認。os-setup skill のほうが速い。 ただし cross-site / 間欠 loss 環境では本 skill の PXE pivot を検討。os-setup skill — BMC VirtualMedia 経由の従来 install (Supermicro/iDRAC で第一選択、 iRMC S4 で USB redirector 健全なら可)irmc-bios-raid skill — BIOS BSPBR (NetworkStack 有効化) + storcli + iRMC FW updatereport/2026-05-30_053607_tx1320_raid10_overview_phase1-19_summary.md (Phase 1-19 横断索引)report/2026-05-30_050830_tx1320_raid10_phase19_pxe_autonomous_ssh.md、 memory training_tx1320_phase19_pxe_autonomous_ssh.md| 回 | 結果 | BIOS POST | preseed GET | storcli GET | phonehome GET | PowerOff | 総時間 | NW retry | 失敗モード/新落とし穴 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | ✅ | t+60s | 23:25:20 | 23:26:02 | 23:32:43 | ~23:32 | ~12min | 0 | bmc-power.sh boot-override rc=52 (curl -L + PATCH 競合)。直接 curl PATCH で回避 |
| 2 | ✅ | t+240s | 00:00:15 (+3m12s) | 00:00:56 (+3m53s) | 00:07:41 (+10m38s) | ~00:07:43 | ~10m40s | 0 | eno2 DHCP IP が前回 (10.254.254.6) から変動 → 10.254.254.7 (#12 再確認)。Run 1 より ~2min 速い (9.8min で GRUB stage) |
| 3 | ✅ | t+180s | 00:22:22 (+3m10s) | 00:23:05 (+3m53s) | 00:29:38 (+10m26s) | 00:30:11 (+10m59s) | ~26min | 0 | eno2 DHCP 取得が disk boot 後 ~14min 遅延 (allow-hotplug eno2 + ケーブル既接続でリンクアップイベント不発生の可能性)。IP=10.254.254.8 (Run 1/2 と異なる)。arp-scan 10.254.254.0/24 or 1-30 brute-ping で特定 |
| 4 | ✅ | t+60s | 00:56:33 (+3m5s) | 00:57:14 (+3m46s) | 01:03:58 (+10m30s) | 01:03:34 (+10m6s) | ~15min | 0 | eno2 DHCP 即時取得 (~3min) で最速 SSH。IP=10.254.254.10 (毎回変動確認)。BIOS POST 99 t+60s は Run 1 と同じ高速パターン |
| 5 | ✅ | t+92s | 01:15:43 (+2m57s) | 01:16:25 (+3m39s) | 01:23:19 (+10m33s) | ~01:23:45 (+10m59s) | ~15m24s | 0 | BIOS POST t+92s (Run 1/4 の 60s より若干遅め)。eno2 DHCP disk boot後 ~3m53s (即時)。IP=10.254.254.11 (毎回変動確認) |
| 6 | ✅ (retry 1) | t+117s | 02:04:27 (+3m30s) [retry] | 02:05:17 (+4m20s) [retry] | 02:12:41 (+11m44s) [retry] | 02:13:08 (+12m11s) [retry] | ~18min (retry込み) | 0 | 落とし穴 #15: 1 回目 attempt で d-i が 25min 超 network detection stuck (preseed GET なし)。eno2 link-up 遅延が d-i netcfg 途中に発生し IPv6 autoconfiguration が 2 NIC 分重複実行。ForceOff → retry で即時解消。retry は +3m30s で preseed GET (通常通り) |
| 7 | ✅ | t+~180s | 02:28:14 (+3m11s) | 02:28:56 (+3m53s) | 02:35:37 (+10m34s) | 02:36:36 (+11m33s) | ~15min | 0 | install retry なし。安定した中間パターン。BIOS POST t+180s (Run 3 と同等)。eno2 DHCP disk boot後 ~2m49s (即時)。IP=10.254.254.13 |
| 8 | ✅ (retry 1) | t+~120-180s | 02:59:05 (+3m17s) [retry] | 02:59:48 (+4m00s) [retry] | 03:06:54 (+11m06s) [retry] | 03:07:20 (+11m32s) [retry] | ~19min (retry込み) | 0 | 落とし穴 #15 再発: 1回目 attempt で d-i が ~7min netcfg stuck (DNS dialog waiting: DHCP 成功後に [!!] Configure the network で Name server addresses入力待ち、preseed GET 来ず)。SOL log で "Configuring the network with DHCP" + "Network autoconfiguration has succeeded" + DNS dialog の VT100 escape sequence 確認。ForceOff → retry で即時解消。retry は +3m17s で preseed GET (Run 6 と同パターン)。eno2 DHCP disk boot後 ~3m19s (即時)。IP=10.254.254.14 |
| 9 | ✅ (retry 1) | t+~120s | 03:31:08 (+3m48s) [retry] | 03:31:49 (+4m29s) [retry] | 03:38:39 (+11m19s) [retry] | ~03:39:00 (+11m40s) [retry] | ~25min (retry込み) | 0 | 落とし穴 #15 再発 (3回目): 1回目 attempt で d-i が DETECTING_NETWORK stuck (SOL 2.4min で stage 2/9、5min間動かず)。ForceOff → retry で即時解消。retry は +3m48s で preseed GET (Run 6/8 と同パターン)。eno2 DHCP disk boot後 ~4m20s (即時寄り)。IP=10.254.254.15 |
| 10 | ✅ | t+120s | 03:52:43 (+3m03s) | 03:53:25 (+3m45s) | 04:00:35 (+10m55s) | 04:01:35 (+11m55s) | ~14-15min | 0 | install retry なし (#15 なし)。BIOS POST t+120s。iPXE t+180s で kernel 61%/t+240s で initrd 94%/kernel OK。DETECTING_NETWORK(+2.8m)→CONFIGURING_APT(+3.8m)→INSTALLING_SOFTWARE(+8.2m)→INSTALLING_GRUB(+10.4m)→POWER_DOWN(+11.4m)。eno2 DHCP disk boot後 ~2-3min。IP=10.254.254.16 |
storcli64 /c0/vall show → RAID10 Optl 1.635 TB ✓、storcli64 /c0/dall show → 4 drives all Onln (252:0-3) ✓、lsblk sda 1.6T ✓| # | 現象 | 真因 | 対策 |
|---|---|---|---|
| 10 | bmc-power.sh boot-override が rc=52 (empty reply) で失敗 | 真因は -L ではなく iRMC 用 env (特に BMC_CURL_OPTS="--ciphers DEFAULT@SECLEVEL=0") の未 export。 iRMC S4 は古い DH 鍵のため cipher option なしだと TLS handshake が失敗し empty reply (rc=52) になる。10-run 当時の -L 原因説は誤診 (検証: 同 env で PATCH に -L あり/なし両方 http=200・rc=0、iRMC /redfish/v1/Systems/0 は 301 しない。逆に -L は NX-3060-G5 11/12号機の末尾 / 301 follow に必要なので削除してはならない) | scripts/bmc-power.sh を呼ぶ前に config の bmc env を export する (下記 Step 5 のコマンド例参照、irmc-bios-raid-setup.sh の load_config() と同じ 5 変数: BMC_SCHEME / BMC_CURL_OPTS / POWER_ON_RESET_TYPE / BMC_PATCH_REQUIRES_ETAG / BMC_BOOT_OVERRIDE_NO_DISABLED)。export すれば ./scripts/bmc-power.sh boot-override が単体で rc=0、tmp 直 curl 回避は不要 |
| 11 | ./scripts/irmc-virtualmedia.sh disconnect-cd が 400 エラー | iRMC FW 9.69F で OEM action 名が変更 (DisconnectCD → 不明)。ただし PXE 経路では Virtual Media が既に inactive なので無視可 | PXE 経路では IsAnyVirtualMediaActive: false を確認して disconnect をスキップ可 |
| 12 | eno2 DHCP IP が再起動で変動 (10.254.254.4 → 10.254.254.6) | dark-net DHCP はリース固定なし | IP特定は必ず `ip neigh |
| 13 | ssh -F ssh/config root@<eno2-IP> が Permission denied | ssh/config の training-tx1320 Host は HostName 10.254.254.4 固定で、動的 IP (10.254.254.6 等) にはマッチしない → IdentityFile が適用されない | ssh -i ssh/id_ed25519 を明示するか ssh/config Host に 10.254.254.* ワイルドカードを追加 |
| 14 | disk boot 後 eno2 DHCP 取得が 15 分以上遅延 (Run 3) | allow-hotplug eno2 はリンクアップイベントを検出してから DHCP を開始する。ケーブルが起動前から接続されていると初回リンクアップイベントが発生しない場合がある → dhcpcd が長時間 DHCP を試みた後に取得 | 恒久対策済み: scripts/generate-preseed.sh の late_network で dhcp_secondary_iface を allow-hotplug → auto に変更 (起動時に link-up イベント非依存で DHCP)。常時配線された dark-net ポートのみ対象。 旧 ISO の場合は ARP 未出現時 1-30 brute-ping / arp-scan 10.254.254.0/24 で特定 |
| 15 | d-i install で preseed GET が 25 分以上来ない (Run 6 初回 attempt) | eno2 の link-up が d-i netcfg 開始後に発生した場合、d-i が 2 NIC 両方に対して IPv6 autoconfiguration (Waiting for link-local → Attempting IPv6) を実行する。各 NIC のタイムアウトが累積し netcfg が長時間スタックする。イベント発生は非決定的 (前回 install のためケーブルが接続済み＋起動タイミングによる) | 恒久対策済み: embed iPXE の kernel cmdline を interface=auto → interface=eno1 に変更し install NIC を固定 (上記「iPXE script の落とし穴」#6)。 ipxe.efi 再ビルド + 再配置が必要。固定後は netcfg が eno2 を無視するため #15 は発生しない。暫定回避は従来通り ForceOff → retry (2 回目 attempt は +3m30s で preseed GET) |
| フェーズ | Run 1 (23:20 UTC) | Run 2 (23:57 UTC) | Run 3 (00:19 UTC) | Run 4 (00:53 UTC) | Run 5 (01:12 UTC) | Run 6 retry (02:00 UTC) | Run 7 (02:25 UTC) | Run 8 retry (02:55 UTC) | Run 9 retry (03:27 UTC) | Run 10 (03:49 UTC) |
|---|---|---|---|---|---|---|---|---|---|---|
| BIOS POST 99 (iPXE loading) | t+60s | t+240s | t+180s | t+60s | t+92s | t+103s | t+~180s | t+~120-180s | t+~120s | t+120s |
| iPXE DHCP+kernel fetch 開始 | t+120s 前後 | t+360s | t+240s (initrd 42% 観測) | t+120s 前後 | t+~150s | t+163s (kernel 44%) | t+~240s | t+~360s (kernel+initrd OK) | t+~141s (kernel/initrd OK) | t+180s (kernel 61%)、t+240s (initrd 94%) |
| preseed GET | +5m20s | +3m12s | +3m10s | +3m5s | +2m57s | +3m30s | +3m11s | +3m17s | +3m48s | +3m03s |
| storcli64.bin GET | +6m02s | +3m53s | +3m53s | +3m46s | +3m39s | +4m20s | +3m53s | +4m00s | +4m29s | +3m45s |
| RAID10 作成完了 | +6m36s | +4m | ~+5m | ~+4m | ~+4m | ~+4.5m | ~+4m | ~+4m30s | ~+5m | ~+4m |
| phonehome GET + PowerOff | +12m43s | +10m38s | +10m26s (+10m59s Off) | +10m30s (+10m6s Off) | +10m33s (+10m59s Off) | +11m44s (+12m11s Off) | +10m34s (+11m33s Off) | +11m06s (+11m32s Off) | +11m19s (+11m40s Off) | +10m55s (+11m55s Off) |
| disk boot → login prompt | +20m (PowerOff後 ~7m) | +25m (PowerOff後 ~14m) | +14m (PowerOff後 ~3m) | +13m (PowerOff後 ~3m) | +15m (PowerOff後 ~4m) | PowerOff後 ~3m (login at 02:16:47) | PowerOff後 ~2m29s | PowerOff後 ~2m15s | PowerOff後 ~3m33s | PowerOff後 ~2m (login at 04:03) |
| eno2 DHCP 取得 (ARP 観測) | disk boot後 ~3-4m | disk boot後 ~5-6m | disk boot後 ~15m (IP=.8) | disk boot後 即時 (IP=.10) | disk boot後 ~3m53s (IP=.11) | disk boot後 ~3m (IP=.12) | disk boot後 ~2m49s (IP=.13) | disk boot後 ~3m19s (IP=.14) | disk boot後 ~4m20s (IP=.15) | disk boot後 ~2-3m (IP=.16) |
| 備考 | BIOS POST t+60s (高速) | t+240s (可変) | eno2 DHCP 遅延大 (allow-hotplug 問題) | 最速 ~15min 総時間、DHCP 即時取得 | 安定した中間パターン。DHCP 即時-標準 | 1回目 attempt で d-i 25min stuck (#15)。retry で正常完走 | 安定した中間パターン。install retry なし、BIOS POST t+180s | #15 再発 (DNS dialog stuck)。retry で正常完走。eno2=.14 (新アドレス) | #15 再発 (DETECTING_NETWORK ~5min stuck)。retry で正常完走。eno2=.15 (新アドレス) | install retry なし (#15 なし)。~14-15min で最速クラス完遂。eno2=.16 |
| 項目 | 値 |
|---|---|
| 成功率 | 10/10 (100%) |
| install retry あり | 3回 (Run 6/8/9、すべて落とし穴 #15 = d-i netcfg stuck) |
| install retry なし | 7回 (Run 1/2/3/4/5/7/10) |
| 落とし穴 #15 発生率 | 30% (3/10) |
| 総時間 (install PowerOn → SSH 到達) | 最短 ~13min (Run 4)、最長 ~26min (Run 3 = eno2 DHCP 15min 遅延)、retry なし median ~15min、retry あり ~18-25min |
| eno2 DHCP 遅延 (15min超) | 1回 (Run 3) ← allow-hotplug + ケーブル既接続でリンクアップイベント不発生 |
| NW retry (bmc/playground 操作) | 0回 (全10回) — インフラが極めて安定 |
| 結論 | PXE 経路は 10回全成功、100% 再現性。最大ブロッカーは落とし穴 #15 (d-i netcfg stuck, 30%)。ForceOff+retry で即座に回避できるため実用上問題なし。標準総時間 13-15min。 |
10-run 検証のフォローアップとして #15 / #14 / #10 を恒久対策し、実機 PXE install で検証した (report 2026-05-31_*_tx1320_pxe_followup_*.md)。
interface=eno1): 3 回連続で preseed GET が初回 attempt のみで +3-4 分以内に到達 (Run F1 +3m19s / F2 +4m9s / F3 +4m9s)。10-run で 30% 発生していた d-i netcfg stuck は 0/3 (= 0%)。interface=eno1 で netcfg が eno2 を完全に無視するため dual-NIC IPv6 autoconfig が物理的に起きない (決定論的解消)。auto eno2): disk boot 後 eno2 DHCP が +2.5-3 分で取得 (Run F1 10.254.254.16 / F3 .18)。10-run Run3 の 15 分遅延は再現せず。installed-system の /etc/network/interfaces が auto eno2 であることを SSH で確認。BMC_SCHEME / BMC_CURL_OPTS / BMC_PATCH_REQUIRES_ETAG / BMC_BOOT_OVERRIDE_NO_DISABLED / POWER_ON_RESET_TYPE を export すれば ./scripts/bmc-power.sh boot-override が rc=0。真因は -L ではなく cipher env 未設定 (上記 #10 表参照)。&&→;): late_command の phonehome 行が正しく生成され、SSH publickey (= authorized_keys) も保持されることを確認。; 修正で in-target の phonehome-setup.sh が実行され、first-boot systemd oneshot (pvese-phonehome.service) が disk boot 後に GET /phonehome?host=...&ips=... で報告する。nginx access.log で確認可。network-online.target+10s 後の最初の成功 curl で exit する。eno1 (site LAN) が先に online を満たすため、eno2 の DHCP 完了前に発火すると eno2 を APIPA で報告する。SSH 到達用の dark-net IP は phonehome を当てにせず ip neigh | grep <eno2-MAC> で再確認する (eno2 lease 自体は auto 化で disk boot +3 分以内に来る)。ResetType=On を拒否する (Fujitsu.1.0.ActionParameterValueNotInList)。ForceOff → 固定 sleep → on は sleep が不足すると失敗する。Off になるまでポーリング (例: 5s × 最大 120s) してから power on すること (tx1320-raid10-orchestrate.sh / 本検証の run-cycle.sh はこの方式)。generate-preseed.sh の awk esc() は & 未対応の潜在バグ — phonehome は &&→; で回避済みだが、esc() 自体は & を正しくエスケープしない。late_network や preseed 値に & を入れると gsub 置換で %%...%% に化ける。late_network に & を使わないこと (根本修正は別 issue)。tx1320 (config の training-tx1320 ではない)。stale ARP に旧 lease が同 MAC で残るため、IP 特定後は ssh ... hostname で live 系を確認する。