| name | irmc-bios-raid |
| description | Fujitsu iRMC S4 (TX1320 M3 等) の電源・BIOS・RAID 操作 + BIOS 設定リファレンス。Redfish (HTTPS + SECLEVEL=0) 経由の電源/ブート操作 + iRMC Web UI/KVM 経由の手動 BIOS/RAID 操作手順 + 全 BIOS 設定項目の網羅リファレンス (bios/)。training-tx1320 対応。 |
| argument-hint | <subcommand: power|bios|raid|info> [args...] |
iRMC S4 BIOS / RAID 操作スキル
Fujitsu PRIMERGY サーバの iRMC S4 BMC を Redfish (HTTPS + 古い DH 鍵対策) 経由で操作する。
本セッション (2026-05-16) 時点で対応している唯一のマシンは training-tx1320 (10.254.254.9, 一時設置・クラスタ非参加)。
| サブコマンド | 用途 | 自動化レベル |
|---|
info <config> | 接続情報・PowerState・BIOS バージョン・ライセンス確認 | 完全自動 |
power status <config> | 電源状態取得 | 完全自動 |
power on <config> | 電源 On (ResetType=On) | 完全自動 |
power forceoff <config> | 強制 Off | 完全自動 |
power cycle <config> [wait=15] | ForceOff → wait → On | 完全自動 |
bios enter <config> | 再起動して BIOS Setup へ (BootSourceOverrideTarget=BiosSetup) | 完全自動 (POST 中の F2 不要) |
bios screenshot <config> <out.jpg> | OEM FTSComputerSystem.Screenshot (Make→Preview) | 半自動 (BIOS Setup 中など static screen で AllowableValues に Preview が出ない場合あり) |
bios backup <config> <out.xml> | WinSCU XML をダウンロード (boot phase で実行) | 完全自動 (scripts/irmc-bios.py backup) |
bios restore <config> <in.xml> | WinSCU XML をインポート (boot phase で適用) | 完全自動 (scripts/irmc-bios.py restore、 multipart/form-data data=@xml) |
bios show <xml> [regex] | XML 内の <supportedSetting> を一覧 | 完全自動 |
bios set <xml> <id> <value> | XML 内の特定 id の <value> を書換 | 完全自動 |
bios diff <a.xml> <b.xml> | 2 つの XML 間の値差分表示 | 完全自動 |
bios apply-config <config> | config['bios_settings.supported'] の値を XML に書き込み → restore | 完全自動 |
bios verify <config> | 現在の BIOS 設定が config と一致するか確認 | 完全自動 |
raid status <config> | RAID コントローラ・VD・PD 表示 | 手動 (iRMC Web UI で確認、手順ガイドのみ) |
raid create-r10 <config> | 4 本選んで RAID10 VD 作成 | ⚠️ 部分動作 (2026-05-18 #7 s-peaceful-hinton)。 #6 (p-effervescent-kahn) で SMB silent failure 真因確定 + 修正 → CD boot + kernel boot まで成功。 installer の cdrom-detect で iRMC Virtual CD が見つからない問題に対し、 #7 で kernel cmdline (GRUB legacy / ISOLINUX / EFI 全 3 経路) + preseed.cfg.template に cdrom-detect/try-usb=true cdrom-detect/scan=true hw-detect/load_media=false を仕込んで再試行 → 効かず。 iRMC OEM CDImage は GRUB レベル (BIOS USB CD-ROM emulation) では読めるが、 Linux 起動後の installer cdrom-detect の udev/sysfs ルールにマッチしない。 preseed.cfg 自体も /cdrom/preseed.cfg から load される設計上 cdrom-detect 失敗の時点で適用されない (chicken-and-egg)。 次セッション候補 (優先順): (1) initrd preseed 注入 + preseed/early_command で自前 mount /dev/sr0 /cdrom、 (2) iRMC HDImage (USB Mass Storage) 経由配信、 (3) PXE / hd-media 経路。 詳細は本 SKILL.md 末尾の「RAID10 storcli + preseed 経路」セクション + report 2026-05-18_025914_tx1320_raid10_cdrom_detect_cmdline_failed.md を参照 |
raid delete <config> <vd> | VD 削除 | 手動 (同上) |
詳細プロトコル・落とし穴・スクリーンショットは reference.md を参照。
BIOS 設定リファレンス (bios/)
TX1320 M3 (D3373-B1x) の 全 BIOS 設定項目 (91 設定 + 各タブ/サブメニュー) を、選択肢・デフォルト・
現在値・ヘルプ・リスクまで網羅したリファレンスを bios/index.md に置く (タブ単位で分割)。
値は実機 WinSCU XML 由来、タブ所属と存在は KVM 確認で確定する。各タブ: main /
advanced / security / power /
server-mgmt / boot / save-exit /
RAID HII。再生成・KVM 確認手順は bios/_capture-runbook.md。
前提条件
- 対象: training-tx1320 (10.254.254.9, iRMC S4 FW 9.08F, claude index 4)
- config:
config/training_tx1320.yml
- 認証: claude / Claude123 (BMC ユーザ)
- ライセンス: KVM + MEDIA (Permanent)、eLCM なし → Redfish 経由 RAID 操作不可
- ipmitool は SOL 用 (本 skill では電源・BIOS は Redfish のみ使用)
Redfish 接続規約
iRMC S4 は古い DH 鍵で TLS handshake するため、curl のオプションが必要:
curl -k --ciphers 'DEFAULT@SECLEVEL=0' -u claude:Claude123 https://10.254.254.9/redfish/v1/...
scripts/bmc-power.sh は環境変数で対応済み:
BMC_SCHEME=https \
BMC_CURL_OPTS='--ciphers DEFAULT@SECLEVEL=0' \
POWER_ON_RESET_TYPE=On \
./scripts/bmc-power.sh <command> 10.254.254.9 claude Claude123
iRMC ResetType メモ: AllowableValues は PowerState で変わる。Off→On 遷移は "On" を使う (default で OK)。PushPowerButton は電源 On 状態で物理ボタンを pulse する用途のみ。
config から自動で読み込んで export するヘルパーパターン (skill 内で利用):
BMC_IP=$(./bin/yq '.bmc_ip' config/training_tx1320.yml)
BMC_USER=$(./bin/yq '.bmc_user' config/training_tx1320.yml)
BMC_PASS=$(./bin/yq '.bmc_pass' config/training_tx1320.yml)
export BMC_SCHEME=$(./bin/yq '.bmc_scheme' config/training_tx1320.yml)
export BMC_CURL_OPTS=$(./bin/yq '.bmc_curl_opts' config/training_tx1320.yml)
export POWER_ON_RESET_TYPE=$(./bin/yq '.power_on_reset_type' config/training_tx1320.yml)
./scripts/bmc-power.sh status "$BMC_IP" "$BMC_USER" "$BMC_PASS"
サブコマンド: info
接続性と基本情報を一括取得。
BMC_IP=10.254.254.9
USR=claude; PSW=Claude123
CURL='curl -sS -k --ciphers DEFAULT@SECLEVEL=0 --max-time 30 -u'
$CURL "$USR:$PSW" "https://$BMC_IP/redfish/v1/Systems/0" | grep -E '"Manufacturer"|"Model"|"BiosVersion"|"PowerState"|"SerialNumber"|"TotalSystemMemoryGiB"'
$CURL "$USR:$PSW" "https://$BMC_IP/redfish/v1/Managers/iRMC" | grep -E '"Model"|"FirmwareVersion"'
$CURL "$USR:$PSW" "https://$BMC_IP/redfish/v1/Managers/iRMC/Oem/ts_fujitsu/iRMCConfiguration/Licenses"
期待出力 (training-tx1320):
- Manufacturer: FUJITSU / Model: PRIMERGY TX1320 M3 / BIOS V5.0.0.11 R1.22.0 / Memory 24 GiB
- iRMC S4 FW 9.08F
- Licenses: KVM, MEDIA (Permanent)
サブコマンド: power
scripts/bmc-power.sh を呼ぶ。電源 On は ResetType=On (デフォルト) で OK。
BMC_SCHEME=https BMC_CURL_OPTS='--ciphers DEFAULT@SECLEVEL=0' \
./scripts/bmc-power.sh status 10.254.254.9 claude Claude123
BMC_SCHEME=https BMC_CURL_OPTS='--ciphers DEFAULT@SECLEVEL=0' \
./oplog.sh ./scripts/bmc-power.sh on 10.254.254.9 claude Claude123
BMC_SCHEME=https BMC_CURL_OPTS='--ciphers DEFAULT@SECLEVEL=0' \
./oplog.sh ./scripts/bmc-power.sh forceoff 10.254.254.9 claude Claude123
BMC_SCHEME=https BMC_CURL_OPTS='--ciphers DEFAULT@SECLEVEL=0' \
./oplog.sh ./scripts/bmc-power.sh cycle 10.254.254.9 claude Claude123 20
サブコマンド: bios enter
Redfish PATCH で BootSourceOverrideTarget を BiosSetup に設定 → 再起動 → BIOS Setup に入る。
F2 キー送信不要 (POST 自動で BIOS Setup に分岐する)。
BMC_SCHEME=https BMC_CURL_OPTS='--ciphers DEFAULT@SECLEVEL=0' \
./scripts/bmc-power.sh boot-override 10.254.254.9 claude Claude123 BiosSetup UEFI
BMC_SCHEME=https BMC_CURL_OPTS='--ciphers DEFAULT@SECLEVEL=0' \
./oplog.sh ./scripts/bmc-power.sh cycle 10.254.254.9 claude Claude123 20
注意: BootSourceOverrideEnabled は iRMC の AllowableValues が Once / Continuous のみ (Disabled は別フィールド)。Once で 1 回限定。
サブコマンド: bios screenshot
OEM FTSComputerSystem.Screenshot で現在の画面を取得 (POST 中・BIOS Setup 中・OS 起動後の画面が見える)。
BMC_IP=10.254.254.9
USR=claude; PSW=Claude123
curl -sS -k --ciphers 'DEFAULT@SECLEVEL=0' -u "$USR:$PSW" \
-X POST "https://$BMC_IP/redfish/v1/Systems/0/Actions/Oem/FTSComputerSystem.Screenshot" \
-H 'Content-Type: application/json' \
-d '{"FTSScreenshotType":"Make"}'
サブコマンド: bios backup / bios restore / bios apply-config
OEM FTSBios.BSPBRBackup / FTSBios.BSPBRRestore で WinSCU XML を読み書き。Bios.Attributes={} なため、設定変更はこの XML 経由で行う。scripts/irmc-bios.py でラップ済み。
Backup フロー (新規 backup を取得して download する場合)
- POST
FTSBios.BSPBRBackup → 任意 Task /N (TaskState=Pending)
- Task は BIOS Boot Phase で実行される —
MessagesOEM に "BSPBR boot phase pending, you may need to reboot host" → サーバを cycle/forceoff/on で再起動
- Boot Phase が始まると Task は Running
BSPBRBootInProgress → 完了で Completed BSPBRSuccess
/Systems/0/Bios の IsBspbrFileAvailable: true を確認- POST
FTSBios.BSPBRSaveBackupToFile (Content-Type: application/json, body {}) → HTTP 200 で application/octet-stream の WinSCU XML が返る
- 末尾に NUL bytes が付いてくる → Python は
text.rstrip(b"\x00\r\n\t ") で除去してから parse する
Restore フロー
- WinSCU XML を編集 (
<supportedSetting> の <value> を書換)
- POST
FTSBios.BSPBRRestore → Content-Type: multipart/form-data、 field 名 data 必須 (-F "data=@bios.xml")
- 他の Content-Type は
406 Not Acceptable (Fujitsu.1.0.ContentTypeNotSupported)
- field 名が違うと
400 (Fujitsu.1.0.DeclaredDataNotPresent)
- HTTP 202 + Task /N (Pending)
- cycle で boot phase → 適用 → Completed
BSPBRSuccess
- 2 度目以降の SaveBackupToFile は 404 — restore で backup file が「消費」される。再度新規 backup task を投入する。
apply-config フロー (推奨)
./scripts/irmc-bios-raid-setup.sh setup-bios config/training_tx1320.yml --cycle
./scripts/irmc-bios-raid-setup.sh verify-bios config/training_tx1320.yml
実機検証済み: training-tx1320 で BootOptionFilter 等の Legacy→UEFI 切替が確実に動作する (2026-05-16)。
XML スキーマ
WinSCU XML には 2 つのセクションが含まれる:
<settingDefinitions> — 各 setting の 定義 (id, name, possibleValues, default, current)。 comment="setting definition part only, does not restore anything" の通り、 restore 対象外。<configuration> 内の <supportedSetting> — restore で適用される現在値 (id, name, setupItemID, value)。 <value> を書き換えて restore する。
詳細は reference.md の "WinSCU XML schema" を参照。
サブコマンド: raid (BIOS UEFI HII 手動操作のガイド)
iRMC S4 の Redfish Storage Members は空、OEM Raid は OOBRaidEventsEnabled しか持たず、eLCM ライセンスもない (training-tx1320)。BIOS Setup → Advanced → AVAGO MegaRAID Configuration Utility (UEFI HII) を HTML5 KVM で操作するのが唯一の経路。
⚠️ VGA frame buffer 問題 (2026-05-16 #69 続報)
確定: BMC Manager Reset では改善しない。 2026-05-16 #69 で Manager.Reset GracefulRestart (HTTP 204) → BMC 復帰 187s → BIOS Setup 再進入を試したが、 canvas は引き続き黒で frame buffer が更新されない。
ただし OEM Screenshot (FTSComputerSystem.Screenshot) は 3 回に 1 回程度成功することが判明。 これを retry で穴埋めすれば実用的な画面取得が可能 (scripts/irmc-oem-screenshot.sh 2026-05-16 改修済、 wall-clock 化 + 4 attempts retry, --max-time 15)。
✅ Playwright KVM 自動化 解決 (2026-05-17 golden-candle セッションで実証)
scripts/irmc-kvm-interact.py 改修済み。 default で動作する新パス + 旧パス温存:
| 旧パス (温存) | 新パス (default) |
|---|
canvas.toDataURL() — WebGL preserveDrawingBuffer:false で黒 | locator.screenshot() — composed frame を取得 |
click(force=True) | locator.click(force=False) — hit-test 経由 |
| (なし) | キー送信に dispatch-event フォールバック (document.dispatchEvent(KeyboardEvent)) も実装済み |
新 CLI flag: --capture-mode={locator,canvas} / --focus-mode={hittest,force} / --key-mode={playwright,dispatch-event}。 旧経路は --capture-mode=canvas 等で利用可能。
🎯 KVM screenshot は必ず --capture-mode=locator (default) を使うこと。 legacy scripts/irmc-kvm-screenshot.py は canvas mode 固定で WebGL 黒画 artifact を出す (Phase 3 s-rustling-melody 2026-05-22 で 11857 B × 3 同一 PNG を「VGA 全黒」と誤判定、 Phase 4 s-vast-hare 2026-05-22 で訂正)。 canvas mode artifact のサイン: 撮った PNG が全部完全同 size (sha256 一致) で 11857 B 前後。 これが出たら即 locator mode に切り替える。 ただし host が実際に kernel hang していて VGA が更新されない場合も同 size 連続になるため (Phase 4 で BIOS POST 12833 B × 4、 凍結 4489 B × 2)、 単に同 size 連続 = artifact とは限らない。 識別ポイント: canvas mode artifact は 全 5 枚で完全同 sha256、 実 host hang は POST 段階と hang 段階で sha256 が分かれる。
✅ 2026-05-17 #2: cursor_y adaptive navigation (golden-dongarra セッション)
scripts/irmc-kvm-interact.py の Playwright 路線を更に強化し、 PIL でカーソル位置を pixel-level 検出する nav_cursor_to_y(target_y, max_press, tol) を tmp/iter/_util.py に実装。 size fingerprint だけでは隣接 menu items を区別できない (16 items in BIOS Advanced tab で size 差 7-30 bytes 程度) ことが判明、 pixel-level cursor detection が解決策。
確定知見 (詳細→ [report/2026-05-17_…_robustness.md]):
| 検証項目 | 結果 |
|---|
| Partial-access dialog dismiss | _dismiss_partial_access_dialog(vp) — HTML overlay の Ok ボタンを JS click。 旧 KVM session が master の場合に発生 |
| Exit-Without-Saving dialog | キー n は Aptio で無効。 ArrowRight (No) + Enter で dismiss |
| BIOS top-level tab detection | 17 fingerprints (各 tab の各カーソル位置) を size + cursor_y で識別 |
safe_navigate_to_advanced_tab() | Esc + dialog dismiss → ArrowLeft/Right で adaptive にタブ移動 |
| AVAGO row 到達 | nav_cursor_to_y(target=393) で 100% 成功 (iter 3b PASS) |
| AVAGO Main → Cfg Mgmt navigation | cursor_y mapping (Main Menu y=70 base, +19 per item) で stable |
| 個別 drive toggle 信頼性問題 | 解消: nav_cursor_to_y で silent drops を自動補正 (ArrowDown が dropped → 再 press) |
| Clear Configuration scaffolding | clear_configuration(vp, sdir) 実装。 ただし Confirm field の dialog cursor 検出に課題あり (要更なる pixel detection 改善) |
| RAID 10 VD0 commit | 未完遂。 form 内の 複数 ► マーカー問題 (form には「navigable 標識」として ► が複数表示され、 active cursor 検出が混乱) |
カーソル検出関数 (tmp/iter/_util.py:detect_cursor_row):
def detect_cursor_row(png_path, x_min=4, x_max=30, y_min=60, y_max=720,
cursor_pixel_value=255, min_cursor_run=4):
"""カーソル ► の bright (255) pixel 連続を検出。
Menu items: cursor at x=8-14; Dialog form fields: cursor at x=24-26
"""
nav_cursor_to_y(vp, sdir, target_y, max_press=25, tol=10, ...) は target_y に着地するまで ArrowDown を adaptive に押し、 overshoot 時は ArrowUp に切替え。 silent drops に自動対応。
まだ未解決 (次セッション継続必要):
- Create VD form の active cursor 検出 — form には複数の ► マーカーが表示され、 detect_cursor_row が active cursor を正しく識別できない。 → 解決案: ► glyph 検出ではなく「行の白背景ハイライト」(background color) を検出。
bright_pixels count を per-row で計算、 highlighted row を特定する関数に置換
- Clear Config dialog の field navigation — Confirm field の cursor detection が不安定
- 2-span 構成自動化 — RAID 10 選択後の form layout (Span 0 / Add More Spans / Span 1) の cursor_y マッピング未取得
✅ 2026-05-17 #3: active-cursor highlight detection + NumpadAdd + ArrowDown skip 発見 (partitioned-beaver セッション)
tmp/iter/_util.py に以下を追加実装:
detect_active_cursor_row(png_path, x_min=30, x_max=400, bg_threshold=200, min_bright_cols=30, y_min=60, y_max=720, merge_gap=4) — 行の白背景ハイライト (highlight band) を検出。 各 y で bright pixel cluster 数を計測し、 最も bright count が大きい cluster の center y を返すnav_cursor_to_y(..., detector='caret'|'highlight', settle_ms=0) — caret/highlight を選択 + reach 後 settle 待機 + drift 補正
実機検証 (training-tx1320) で判明した重大事実:
| 観測 | 結論 |
|---|
detect_active_cursor_row が form 内で常に y=128 (Select RAID Level の [RAID0] 値表示) を picking | cursor が他行にいても [RAID0] の cluster (y=121..132, max bright cols=110) が brightest として誤検出される。 form 内では highlight detection 単独で cursor 位置確定は不可能 |
form_open 直後 ArrowDown 1500ms wait → size=18474 → 実機 cursor は y=147 (Select Drives From) | Aptio が Select RAID Level (y=128) をスキップ。 form_open (cursor on Save Config TOP y=88) → ArrowDown 1 で 2 行飛びで Select Drives From に着く |
ArrowUp 1 from y=88 → cursor at y=411 (Emulation Type) | wrap-around to form の bottom |
vp.keyboard.press("+") / chord Shift+Equal / type("+") | どれも Aptio に届かず size 不変 |
vp.keyboard.press("NumpadAdd") | 届く。 Select Drives From で押すと [Unconfigured Capacity] ↔ [Free Capacity] トグル (size 18474↔18436 振動) |
| ArrowDown でカーソル位置が画面表示と Aptio 内部状態でずれる | iRMC KVM frame buffer の lazy refresh + Aptio key event queue の race condition。 settle_ms=1500-3000 でも完全解消せず |
| cursor 位置の確実な検出手段 | NumpadAdd を 1 回押して何の値が変わったかを screenshot size + 画像比較で同定するのが最も信頼性高い (highlight detection は誤検出多発) |
確定した CURSOR_Y_CREATE_VD_FORM (RAID0 default, scout iter08_scout_run/p2_raid0_*.png から):
| 行 | y | 項目 | navigable? |
|---|
| step 0 | 88 | Save Configuration (TOP) | yes |
| step 1 | 128 | Select RAID Level [RAID0] | No (Aptio skip) |
| step 2 | 147 | Select Drives From [Unconfigured Capacity] | yes |
| step 3 | 166 | Select Drives | yes (submenu) |
| step 4 | 204 | Virtual Drive Name | yes |
| step 5 | 223 | Virtual Drive Size | yes |
| step 6 | 259 | Strip Size [256 KB] | yes |
| step 7 | 280 | Read Policy [Read Ahead] | yes |
| step 8 | 299 | Write Policy [Write Back] | yes |
| step 9 | 316 | I/O Policy [Direct] | yes |
| step 10 | 337 | Access Policy [Read/Write] | yes |
| step 11 | 373 | Disable Background Initialization [No] | yes |
| step 12 | 411 | Emulation Type [Default] | yes |
| step 13 | (wrap) | → 88 | wrap |
ArrowDown を 14 回押すと wrap-around。 silent drop (同じ y 連続) は step 9-10, 11-12 で観測。
Select RAID Level (y=128) は ArrowDown skip 対象のため、 値変更には:
- ArrowDown でいずれかの navigable 行に着く
Tab または Shift+Tab で項目間 cycle (未検証)- もしくは popup 経由 (
Enter で Select RAID Level に入る—これが本来の Aptio の意図と思われる)
次セッション継続課題 (Task C/D):
- cursor on Select RAID Level の到達方法を確定 — Tab/Shift+Tab? それとも form 初期 cursor が default で Select RAID Level (y=128) にあり、 そこで NumpadAdd?
- size fingerprint ベースの cursor identifier — NumpadAdd 1 回で size diff から cursor 行を確定する関数 (
identify_form_cursor_by_probe)
- drives popup の cursor 検出 — popup overlay 範囲 (x=410-600, y=350-420 など) に限定した detect 関数
- RAID10 commit シーケンス C1-C13 — 上記 1-3 完了が前提
- dispatcher 統合 — RAID10 commit 動作確認後
詳細→ report/2026-05-17_092256_tx1320_raid10_active_cursor.md
🎉🎯🎯🎯 2026-06-02 (d0a59391, issue #69): RAID10 dead end は 覆った — BIOS HII KVM から RAID10 作成成功
2026-05-17 #4 の「RAID10 は AVAGO HII KVM 経路では不可能」結論は誤り (偽陰性) だった。FW 9.69F + ハードニング済みツール (scripts/irmc-kvm/server.py) + per-key サブエージェント画像分析で、BIOS Setup HII から RAID10 VD を作成し Virtual Drive 0: RAID10, 1.636TB, Optimal を KVM + OEM 真VGA の両方で裏取りした (4×900GB SAS → 2 span ミラー+ストライプ = 全容量 3.272TB の半分 1.636TB)。report 2026-06-02_*_tx1320_raid10_bios_hii_success.md。
dead end が偽陰性だった理由:
- FW 9.69F の Create VD フォームは 開いた瞬間カーソルが
Select RAID Level 行に乗っている (2026-05-17 の「Save Config top から ArrowDown で y=128 を skip」は旧 FW/旧ツール/[RAID0] cluster 誤検出の複合アーティファクト)。
Select RAID Level の Enter で開くドロップダウンに RAID0 / RAID1 / RAID5 / RAID6 / RAID00 / RAID10 が並ぶ (RAID50/60 は "if supported" で 4 ドライブ時は非表示)。RAID10 は 0 ドライブ選択時点でも出る。右ヘルプも "0, 1, 5, 6 (if supported), 00, 10, 50, and 60 (if supported)" と明記。- RAID10 選択でフォームが
SELECT SPAN(S): / Span 0: / Select Drives / Add More Spans に変化 (spanned 構成 UI)。
RAID10 作成 全手順 (FW 9.69F、実証済み):
- 既存 VD があれば Clear Configuration (下記 commit レシピ)。クリア後 Config Mgmt 再進入で
Create Virtual Drive が出る (Config Mgmt メニューは stale なので一段 Escape→再進入でリフレッシュ)。
- Config Mgmt →
Create Virtual Drive → Enter。フォームはカーソルが Select RAID Level [RAID0] に乗って開く。Enter → ドロップダウン → ArrowDown×5 で RAID10 → Enter。
Span 0: 配下の Select Drives へ移動 (Select RAID Level から ArrowDown: Protect スキップ→Select Drives From→SELECT SPAN(S)/Span0 ヘッダスキップ→Select Drives) → Enter → drive popup。- drive popup で 2 台だけ Enabled にする (各ドライブ: Enter で Disabled/Enabled ドロップダウン→
mouse 230 384 でポップアップにフォーカス→ArrowDown→Enter)。上部 Apply Changes (ArrowUp で到達) → Enter → ►OK を Enter。
- フォームに戻り
Add More Spans → Enter (Span 1 生成)。Span 1: 配下の Select Drives → Enter → drive popup には残り 2 台のみ表示されるので Check All → Enter → Apply Changes → Enter → ►OK。
- フォームに
Span 0: + Span 1: + Virtual Drive Size 1.636 TB が出る。Save Configuration (フォーム最上部) → Enter → 作成確認ダイアログ → commit レシピ → 1st ►OK を Enter → 2nd msg ("Virtual Drive creation was successful...") は Escape。
- 裏取り: Main Menu → Virtual Drive Management →
Virtual Drive 0: RAID10, 1.636TB, Optimal。VD0 Enter で Raid Level [RAID10] / Status [Optimal] / Size 1.636 TB も確認可。
🆕🆕🆕 今回確立した重大ハードニング知見 (上記レシピ成立の鍵):
- 🚨
keyrepeat は高 latency 拠点 (training-tx1320, ping 60-340ms) で多重登録する (800ms 間隔で 4 press → 約 6 行移動 = 1.5x)。間隔 ≥1600ms にすると 1:1 になる。精密ナビは keyrepeat <key> <n> 1600 か単発 press を使う。単発 press (コマンドファイル 1 つ 1 キー) は確実に 1:1。
- 🚨 commit/ドロップダウン確認ダイアログの操作は 1 つのコマンドファイルに全部入れる。ダイアログを開く Enter とその後の
mouse→ArrowDown→Enter を別コマンドファイルに分けると、その間にフォーカスが失われ矢印が drop され ►No に当たって dialog がキャンセルされる (058/059 で実証)。press Enter (open) → sleep 3 → mouse <items> → sleep → ArrowDown → Enter を 1 ファイルで送る (060 で成功)。
- 🚨 フォーカス確立クリックは「項目の上」を狙う。画面中央 (512 384) は不可。確認ダイアログ (Confirm/Yes/No) は開いた直後に
mouse 80 240 (左の項目帯)。中央 (512 384) はダイアログ項目が左上にあるため空白部に当たり、矢印が drop される。
- Confirm の Disabled/Enabled ドロップダウンには別途クリック不要。ダイアログ冒頭の
mouse 80 240 で得たフォーカスがそのまま引き継がれ、ArrowDown→Enter で直接操作できる (commit レシピを 1 コマンドファイルにまとめる前提)。
- ドライブの Disabled/Enabled ドロップダウンは
mouse 230 384 (ポップアップ箱の上) が必須。ドライブ行へナビ後に別コマンドで開くためフォーカスが切れており、再クリックしないと ArrowDown が drop する。
- ArrowDown は No から Confirm に wrap する (No→ArrowDown→Confirm)。
ArrowUp×2 より ArrowDown×1 wrap が 1 キーで確実。
- ドライブの Disabled/Enabled ドロップダウンは
mouse 230 384 フォーカス必須。これ無しの ArrowDown は drop、NumpadAdd 直接トグルも drop (036 で実証)。
- 重い画面遷移 (メニュー→フォーム) は 2.5s sleep でも stale スクショになることがある → 同じ前画面が写ったら追加 sleep + 再 shot (024→025 で実証)。
- 作成 2nd msg は Escape、削除/作成 1st ►OK は Enter (挙動差、SKILL 既出を再確認)。
🛑 [SUPERSEDED — 2026-06-02 に覆った、上記参照] 2026-05-17 #4: RAID10 自動化 dead end 確定 (a-goofy-graham セッション)
tmp/iter/_util.py に identify_form_cursor_by_probe(vp, sdir, label, expected_y) + detect_popup_cursor_row(...) + PROBE_FORBIDDEN_Y / PROBE_SAFE_Y / CURSOR_Y_CREATE_VD_FORM を追加。 静的検証 (既存 PNG) で _rowwise_diff_y が cursor 行を確実に特定可能なことを実証 (size delta -38 でも _rowwise_diff_y は y=148 を pin pointer 検出、 期待 y=147 と一致)。
実機検証 (training-tx1320, iter_09 + iter_09b + iter_09c) で判明した dead end:
| 試行 | 結果 |
|---|
| iter_09 Phase 3 A2: ArrowUp x1 from y=147 → cursor y=88 (Save Config TOP に戻る、 expect y=128) | ❌ A2 失敗 |
| ArrowUp x2 from y=147 → y=411 (Emulation Type, wrap to BOTTOM) | ❌ A2 fallback 失敗 |
| ArrowUp x3 from y=147 → y=392 (不明位置) | ❌ |
| iter_09b T1 form_open + Enter on Save Config TOP → Save Configuration dialog (size +1215) | ❌ y=128 到達せず (cursor は内部的にも y=88 確定) |
| iter_09b T2/T3 Tab / Shift+Tab → size +0 (完全無反応) | ❌ Aptio HII は Tab を解さない |
| iter_09b T_home Home key → size +0 (無反応) | ❌ |
| iter_09b T_end / T_pagedown → cursor y=411 (form BOTTOM) | ❌ y=128 訪問なし |
| iter_09b T_pageup → cursor y=88 (form TOP) | ❌ y=128 スキップ |
| iter_09b T_click x50/x200/x300, y=128 Mouse click via Playwright canvas → size +0 | ❌ Aptio HII は canvas click を解さない |
| iter_09c Profile-Based VD: 4 profile cycle (RAID 0/1/5/6) — RAID 10 profile なし | 🛑 Profile 経路も dead end |
結論: AVAGO HII for TX1320 M3 (LSI SAS3008, FW iRMC 9.08F) では:
- Create VD form の Select RAID Level (y=128) には ArrowDown/Up/Tab/Shift+Tab/Home/End/PageUp/PageDown/Mouse Click のいずれでも到達不可能
- Profile-Based VD は RAID 0/1/5/6 のみ提供、 RAID 10 profile なし
- → RAID 10 自動化は AVAGO HII KVM 経路では不可能
残された候補 (次セッション以降):
- LSI Software RAID Utility (Advanced tab y=406) を試す — AVAGO とは別 controller の HII の可能性
- キーボードイベント raw injection (Playwright bypass、 iRMC KVM Java/HTML5 protocol level) — Tab/Click が届かない原因の分析
- 2 段階 RAID 1 + RAID 0 ストライプ — Profile-based で RAID 1 を 2 つ作り、 後で manual RAID 0 化 (AVAGO がこの構成をサポートするか未確認)
- iRMC OEM Redfish 探索 — TX1320 は eLCM なしだが、 OEM Redfish で RAID 設定変更ができる panel が隠れている可能性
- MEGACLI CLI を OS 側から実行 — OS install 後に MEGACLI で RAID 10 を作成 (ただし OS install には先に RAID 必要なので circular)
Drives popup の frame buffer 描画問題 (iter_09 Phase 4 で判明):
- popup を Enter で開いた直後 4 frame canvas 全て真っ黒 (cnt=0)
- 5 frame 目以降 highlight が部分的に見える (cnt=39-79)
detect_popup_cursor_row(x=410-580, y=340-560) でも検出失敗- 仮説: iRMC KVM frame buffer の lazy refresh + popup overlay の partial draw
- → 次セッションで Ctrl 単独 key で frame refresh を強制 + 待機時間長期化を試行 (ただし dead end のため優先度低)
確定した CURSOR_Y_CREATE_VD_FORM (本セッションで追加):
CURSOR_Y_CREATE_VD_FORM = {
"save_configuration_top": 88,
"select_raid_level": 128,
"select_drives_from": 147,
"select_drives": 166,
"virtual_drive_name": 204,
"strip_size": 259,
"read_policy": 280,
"write_policy": 299,
"io_policy": 316,
"access_policy": 337,
"disk_cache_policy": 373,
"emulation_type": 411,
}
追加実装関数 (tmp/iter/_util.py):
identify_form_cursor_by_probe(vp, sdir, label, expected_y) — hybrid (model + image diff probe). PROBE_FORBIDDEN_Y={88,411} で action 行 skip、 PROBE_SAFE_Y={147,259,280,299,316,337,373} で NumpadAdd→NumpadSubtract で値を確実に戻す + image diff で cursor 行特定detect_popup_cursor_row(...) — popup overlay 範囲限定 detect (popup frame buffer 描画問題で本セッションでは動作未確認)_rowwise_diff_y(before, after, ...) — 2 PNG 間の row-wise pixel diff sum を計算 → 最大 y を返す (probe の内部実装)
詳細: 次セッション引き継ぎレポート report/2026-05-17_HHMMSS_tx1320_raid10_dead_end.md 参照
🎯 2026-05-31 (cosmic-aho): FW 9.69F KVM ログイン修正 + HII モーダルダイアログ入力不能の確定
FW 9.69F で KVM 自動化を再開しようとして判明した 2 点 (実機 training-tx1320)。
(1) FW 9.69F の KVM ログインは cookie ベース — 旧 open_viewer は必ず失敗する
- 旧
scripts/irmc-kvm-interact.py / tmp/iter/_util.py の open_viewer は login 成功を re.search(r'sid=', page.url) で判定していたが、FW 9.69F は SID を URL に入れず cookie (sid) に格納する。P99 (Login submit) クリック後の URL は /systeminfo?ms=1&lang=0#login のまま (ログインは成功している) → 旧コードは Failed to login after 3 attempts で必ず死ぬ。
- 修正 3 点 (検証済み):
- login 成功判定を
ctx.cookies() に sid cookie 出現で行う
- viewer は
viewer.html?ms=0&lang=0 を sid パラメータなしで開く (cookie セッションで認証)。Web UI の "Video Redirection (HTML5)" link href も viewer.html?ms=1&lang=0 で sid なし
canvas#kvm の click は #cursor_canvas overlay が pointer を intercept するため click(force=True) 必須 (旧コードの hit-test click は timeout)
- KVM canvas locator screenshot (1024x768) は鮮明に判読可能。BIOS Setup メニュー画面の cursor_y マップ (
CURSOR_Y_ADVANCED_TAB 等) は 9.69F でも有効。
- 参考実装:
tmp/503d9361/kvmlib.py の open_viewer (本セッションの作業コピー)。次回これを scripts/irmc-kvm-interact.py に移植すべき。
(2) 🛑 Aptio HII モーダルダイアログ/ポップアップは KVM 入力 (キー・マウス) を一切受け付けない
VD 削除を BIOS メニュー (Configuration Management → Clear Configuration) で試行したところ、Clear Configuration 確認ダイアログがキーボード・マウスの両方を完全に無視する。OEM Screenshot (真の VGA) で裏取り済み:
- Clear Config 確認ダイアログ (
Confirm [Disabled] / Yes / ► No、初期カーソル No):
- ArrowUp/ArrowDown を 20 回連打しても ► は No から 1px も動かない (OEM screenshot で確定、frame buffer 凍結ではない)
- Enter (No 上) も効かない (ダイアログが閉じない)
- Escape も効かない (General Help popup を F1 で開いた後 Escape で閉じられない)
- canvas マウスクリック (Confirm/Yes/No 行の座標) も無効 (Aptio HII はマウスを解さない、 2026-05-17 #4 既出を再確認)
- 一方 F1 (General Help) は効く — F1 は下層フォームが処理するグローバルホットキーのため。だが開いた Help popup 自体は Esc/Ok で閉じられない
- メニュー (Setup ページ) の矢印ナビゲーションは効く — Main tab → Advanced tab → AVAGO row (ArrowDown 14)、Main Menu → Configuration Management → Clear Configuration への移動は成功。Enter でのサブメニュー/ダイアログ展開も成功。
- 境界: 「Setup ページ (左寄せメニュー項目リスト)」の ↑↓ は効くが、「モーダル確認ダイアログ/ポップアップ」の ↑↓/Enter/Esc/マウスは効かない。これは 2026-05-17 #3/#4 の「Create VD form の Select RAID Level 到達不可」「drives popup frame buffer 描画問題」と同根 (HII popup/form の入力レイヤが KVM では機能しない)。
⚠️ 上記 (2) の「入力不能 / dead-end」結論は 2026-06-01 に覆った (下記参照)。当初は「Confirm/Yes/No モーダルに synthesized input が一切届かない」と判断したが、真相は 「フォーカスカーソル ► が常に No に固定表示され実フォーカスを反映しないため、キーが効いていないように見えていた」 だけ。実際にはキーは届いており、正しいキーシーケンス + 1キーごとの screenshot 確認で 完全自動操作が可能。
🎉🎯 2026-06-01 (cosmic-aho 続き): 確認ダイアログ自動操作レシピ確立 — RAID 削除→再作成を完全自動化
上記 (2) の訂正。Confirm/Yes/No モーダル (Clear Configuration 削除確認 / Save Configuration 作成確認 / drives popup ではない方) は operable。鍵は「► は静的でフォーカスを示さない」ことを理解し、1キーごとに screenshot で状態遷移を確認しながら進めること (盲目の連続送信は不可)。
確認ダイアログ commit レシピ (実証済み、削除・作成共通):
- ダイアログ展開直後 (初期フォーカス=No、► は No 上に固定表示):
ArrowUp ×2 → Enter → Confirm のドロップダウン (Disabled/Enabled) が開く (screenshot size ~11866 で確認。►×1 では不足)。
- ドロップダウンで
ArrowDown → Enter → Enabled 選択。Confirm [Enabled] になり Yes が選択可能化。
ArrowDown → Enter → Yes を選択して commit。Confirm=Enabled 後は ► が実際に Yes (caret y~221) へ可視移動するので screenshot で確認できる。- "The operation has been performed successfully / ►OK" ポップアップを
Enter で閉じる (この左寄せ ►OK 型は Enter で閉じる)。
Create VD (RAID0) 全自動シーケンス (FW 9.69F、実証済み):
- Main →
ArrowRight (Advanced tab) → AVAGO row (cursor_y=393) → Enter → AVAGO dashboard。
Enter (Main Menu) → Enter (Configuration Management) → Enter (Create Virtual Drive)。VD が無い時のみ Config Mgmt 先頭が Create Virtual Drive。RAID Level は [RAID0] がデフォルトで変更不要。- フォームで
Select Drives 行 (highlight y~147) へ → Enter → drives popup。
- drives popup で
Check All 行 (y~412) → Enter → 全 drive [Enabled]。
Apply Changes (上部 y70 を ArrowUp で狙うのが確実。下部 y450 への navy は all-Enabled 行の bright cluster で highlight 誤爆) → Enter → ►OK を Enter で閉 → フォームに戻る (VD Size に容量反映、例: 4×837GB RAID0 = 3.272 TB)。Save Configuration (フォーム最上部、cursor 初期位置) → Enter → 作成確認ダイアログ → 上記 commit レシピ。
Clear Configuration (削除) 全自動シーケンス: AVAGO dashboard → Enter (Main Menu) → Enter (Config Mgmt) → Clear Configuration 行 → Enter → 削除確認ダイアログ → 上記 commit レシピ。
🚨 検証は必ず Virtual Drive Management で: AVAGO dashboard の Virtual Drives:/Drive Groups: カウントと Configuration Management のメニュー項目は stale でキャッシュされ、作成/削除直後に古い状態を表示する (作成後も VD:0、削除後も「View Drive Group Properties/Clear Configuration」を表示し続ける)。実態は Main Menu → Virtual Drive Management が反映 (例: "Virtual Drive 0: RAID0, 3.272TB, Optimal")。
これにより iRMC S4 KVM (FW 9.69F) で BIOS メニュー経由の RAID 削除→再作成が (単一健全セッションで) 自動化可能と確定 (2026-06-01、RAID0 で実証)。RAID10 の Create VD form 内 Select RAID Level への到達も 2026-06-02 (d0a59391, issue #69) に実証され、Select RAID Level ドロップダウンに RAID10 が並ぶことを確認 → RAID10 を含む全レベルが HII KVM で作成可能と確定（旧「Select RAID Level dead-end」判定は覆った。上記「🎉🎯🎯🎯 2026-06-02 ... RAID10 dead end は覆った」節を参照）。参考実装: tmp/<sid>/kvm_server.py (永続セッション + コマンドファイル駆動 + ► 不可視前提の per-key 検証)。
🎯🎯🎯 2026-06-02 (r10hiicd): Clear Configuration は 単一コマンドファイルで完全自動化可能 — 10/10 決定論再現
OS install 10 回反復 (各 install 前に BIOS HII で RAID 構成を Clear) で、Clear Configuration の全工程を 1 つのコマンドファイルにまとめて投入し 10/10 で成功。per-key の対話的フィードバックは不要 (recipe が決定論的)。scripts/irmc-kvm/server.py の永続セッションへ以下 1 ファイルを投入するだけ:
press ArrowRight 1800 # Main -> Advanced
keyrepeat ArrowDown 14 1600 # -> AVAGO MegaRAID 行 (1600ms で 1:1、高 latency でも過剰登録なし)
shot c1_avago.png
press Enter 2500 # -> AVAGO dashboard (cursor=Main Menu)
press Enter 2500 # -> Main Menu (cursor=Configuration Management)
press Enter 2500 # -> Config Mgmt (cursor=View Drive Group Properties)
press ArrowDown 1600 # -> Clear Configuration 行
shot c2_clear_row.png
press Enter 3000 # Clear 確認ダイアログを開く
shot c3_dialog.png
mouse 80 240 # ダイアログ項目帯にフォーカス確立 (中央 512,384 は不可)
sleep 1
press ArrowDown 1800 # No -> wrap -> Confirm
press Enter 1800 # Confirm [Disabled/Enabled] ドロップダウンを開く
press ArrowDown 1800 # Disabled -> Enabled
press Enter 1800 # Enabled 選択 (フォーカス継続のため別クリック不要)
press ArrowDown 1800 # Confirm -> Yes
press Enter 2000 # commit
shot c4_committed.png # "The operation has been performed successfully" + ►OK
press Enter 2500 # ►OK を閉じる
press Escape 2500 # -> Main Menu
keyrepeat ArrowDown 2 1600 # -> Virtual Drive Management
press Enter 2500
shot c5_vdm_verify.png # "no Virtual Drives currently available" = Clear 成功
quit
🔑 検証は KVM canvas PNG の byte size を指紋として使える (10 run 全て同一値、locator capture mode):
| チェックポイント | PNG size | caret_y | 意味 |
|---|
| c1_avago | 18051 | 393 | AVAGO MegaRAID 行 highlight |
| c2_clear_row | 10135 | 83/90 | Clear Configuration 行 highlight (help="Deletes all existing configurations") |
| c3_dialog | 11383 | 259 | Clear 確認ダイアログ (Confirm[Disabled]/Yes/►No) |
| c4_committed | 9462 | 102 | "operation performed successfully / ►OK" |
| c5_vdm_verify | 9758 | None | "no Virtual Drives currently available" |
size が一致すれば画面遷移は成功。ずれたら投入をやり直す (本 10 run では一度もずれなかった)。BIOS POST 後 server.py の server_ready.png は BIOS Main で size≈14600 / caret_y=178。コマンドファイル例: tmp/r10hiicd/clear-all.cmd。RAID10 作成 (storcli) は OS install の preseed partman/early_command が担当 (Clear 後の delete force は no-op、create が効く)。
⚠️ server.py の --idle-timeout 内に必ずコマンドを投入すること。投入が遅れて idle-timeout (既定 3600s) に達するとセッションが終了し、再起動 (relaunch) が必要になる (r10hiicd run09 で発生、host は BIOS Setup に留まるため害はないが時間ロス)。
🚨🆕 (2026-06-02 session 6d0368bf): 単一ファイル recipe は先頭 ArrowRight ドロップに脆弱 — 検証付き Clear が堅牢
RAID→PVE 通し 3試行検証で、上記の単一ファイル clear-all.cmd 投入が 試行1は成功・試行2は失敗した。
失敗時は 先頭 press ArrowRight (Main→Advanced タブ切替) が高 latency でドロップし、Main タブのまま
keyrepeat ArrowDown 14 して System Time 行に着地 → 以降の Enter/dialog が全て誤画面で実行され、
指紋が総崩れ (c1=14584 caret_y=292、c3==c4 で commit 不発、RAID 未クリア)。c1 を読むと BIOS Main タブ
だった。r10hiicd の 10/10 はタブ切替が運良く毎回通っただけで、決定論ではない (ping 36-340ms の拠点)。
→ 堅牢な「検証付き Clear」手順 (試行2で実証、推奨):
press ArrowRight 2000 + shot tab.png → 画像で Advanced タブ着地を確認。Main のままなら ArrowRight 再送 (リトライ)。navy 393 caret 25 1500 + shot avago_row.png → AVAGO 行へ adaptive 着地 (nav_cursor_to_y が
ArrowDown silent drop を自己補正。blind な keyrepeat ArrowDown 14 より確実)。size=18051/caret_y=393 で確認。press Enter 2500×3 + press ArrowDown 1600 + shot clearrow.png → 右ヘルプ "Deletes all existing
configurations" + "Clear Configuration" ハイライトを確認 (VD 有り時は Config Mgmt が 2 項目: View Drive
Group Properties / Clear Configuration、Clear は ArrowDown 1)。- modal commit を 1 ファイルで投入 (
press Enter 3000 でダイアログ → mouse 80 240 → ArrowDown→Enter
×3 で No→Confirm→Enabled→Yes → commit → Enter (►OK) → Escape → keyrepeat ArrowDown 2 → Enter
→ shot vdm.png)。vdm.png size=9758 = "no Virtual Drives currently available" = クリア成功。
要点: タブ切替は必ず shot で検証 (ドロップ時リトライ)、AVAGO 着地は navy で adaptive に。指紋は最終 vdm.png
(9758) のみが信頼でき、中間 (committed.png 等) は投入経路で size がぶれる。コマンドファイル例:
tmp/6d0368bf/{c-tab,c-avago,c-descend,c-commit}.cmd。
🚨🆕 (2026-06-03 4dbf313d) server.py READY は実際には常に Main タブに着地する。だが server_ready.png
の size 指紋は当てにならない — 実測で READY が size=17919 (Advanced の指紋) を出しても cursor は Main
にいた (試行4: 17919/caret_y=102 表示なのに直後の navy initial cursor_y=178 で Main の短いリストを wrap し
393 未到達 FAILED)。対策: READY 後は size を見て分岐せず、常に単一 press ArrowRight を送って Main→Advanced
に入り、shot tab.png で確認 (Advanced = size 17919 / caret_y=102) してから navy 393 で AVAGO へ。
server_ready が Advanced っぽい size でも ArrowRight をスキップしない (試行4 はスキップして Main に
居座り失敗)。⚠️ タブ列は wrap する (Main で ArrowLeft を押すと最右 Save & Exit に回り込む) ので、
"ArrowLeft で Main 強制" は逆効果 (試行5 で Save & Exit に着地)。navy が 393 に到達せず 178/197/235/273/292
を巡回したら「Advanced でなく別タブにいる」サイン → そのタブを subagent で読み、Advanced は左から 2 番目
(index1) なので現在 index c から ArrowRight × ((1 - c) mod 7) で到達できる。
🚨 無人 N サイクル自動ループの落とし穴 (2026-06-01、9 回ループ試行中に判明)
単発の削除/作成は自動化できたが、無人で N サイクル回すのは以下の脆さで非常に困難。harden するには下記を厳守:
- 制御テストに F1 (General Help) を使うな。F1 が開く Help モーダルは Esc で閉じないことがあり、開いたまま残ると以降の全ナビゲーションキーをブロックする (caret が固定値に張り付き「キー不達」に見える = 過去「KVM 劣化」と誤診した症状の主因)。制御確認は ArrowRight→ArrowLeft のタブ切替 (画面 size 変化で判定、popup を開かない) を使う。
- BIOS 最上位タブ (Main/Advanced) で Esc を押すな。「Exit Without Saving (Quit without saving? Yes/No)」モーダルが開き、これも synthesized 入力を受けず以降をブロックする。AVAGO サブメニュー内の Esc は安全 (上位へ戻るだけ)。
- Advanced タブ下部の密集項目で AVAGO 行への正確な着地が困難。iSCSI(caret y≈368) / AVAGO MegaRAID(≈393) / LSI Software RAID(≈406) が ~13px 間隔で、caret 検出 ±8px では 393 と 406 を区別しきれず LSI SW RAID 等に誤入する。要・狭 tol + 着地後の screenshot 文言確認 (「AVAGO MegaRAID」の文字)。
- KVM master セッションは閉じると数分スロットが残存。次の接続はスレーブ (キー無反応) になり再接続が要る。無人ループは 1 セッションを開いたまま全サイクル実行し、開閉を繰り返さないこと。
- 詰まった modal / スレーブ状態からの確実な復旧 = host を ForceOff → BMC reboot (Manager.Reset) → host を BIOS に起動。⚠️ Manager.Reset は host が ON / BIOS 設定中だと
Fujitsu.1.0.ActionRelatedFeatureBlocked で恒久ブロックされる。必ず先に host を ForceOff してから Manager.Reset すると通る (2026-06-01 実証、ユーザ指摘)。BMC 復帰後に boot-override BiosSetup + power on で fresh な BIOS Main タブ + 健全 KVM + セッション無し状態になり、その「最初の接続」だけが master かつ健全。
- 状態確認は KVM セッションを消費しない OEM Screenshot (
irmc-oem-screenshot.sh) を優先 (KVM master を奪わない)。
- 🚨 AVAGO のメニュー階層は入場ごとに見え方が変わる — caret_y やサイズで盲判定するな、必ず各画面の文字を読め。確認された 2 形態: (A) フル dashboard =
Main Menu / Help / PROPERTIES: Status.. / ACTIONS: Configure.. (Virtual Drives 数が見える)、その Main Menu を Enter すると Configuration Management / Controller Management / Virtual Drive Management / Drive Management / Hardware Components の 5 項目。(B) コンパクト = AVAGO 行 Enter 直後にいきなり Controller Management / Virtual Drive Management / Drive Management の 3 項目だけ (Configuration Management が無い = Create/Clear に到達できない)。2026-06-01 の careful ラウンドは (B) に入ったのに (A) のつもりで操作し、Controller Management 内を delete/create と誤認して空振りした。対策: AVAGO 進入後まず画面の文字を読み、Configuration Management 行が見える形態か確認する。無ければ一段 Esc して入り直す。VD の有無は最終的に Virtual Drive Management ページの Virtual Drive 0: RAIDx, ... 行を OEM で読むのが唯一信頼できる (dashboard カウントは stale)。
- per-key 駆動を徹底: 1 キー送るたびに screenshot を撮り、その画像の文字を読んでから次を決める。複数キーを 1 つの cmd にまとめて送ると、メニュー階層の取り違え・silent drop で容易に道を見失う (2026-06-01 で複数回実証)。eff率化は手順が完全に固まってから。
- RAID 構成は コントローラ NVRAM に永続し、host 電源断・BMC reboot では消えない (2026-06-01、VD0 が複数回の cold reset を生き延びて確認)。クリーン状態に戻したい時も RAID は明示的に Clear Configuration しない限り残る。
- 推奨フロー: [host off → BMC reboot → host on(BIOS) → OEM で BIOS 到達確認 → 介在セッション無しで単一セッションを開き全サイクル実行]。それでも Advanced→AVAGO の初回ナビ精度が課題で、無人完走の信頼性は低い。現実的には削除/作成の各 confirm を人手 (Web UI KVM) で行う協調方式が最も確実 (2026-06-01 で 1 サイクル実証済)。
KVM セッション運用の知見 (本セッションで確立)
- iRMC S4 は KVM master を 1 セッションのみ許可。閉じた master セッションが数分間スロットを保持し、その間に開いた新セッションは read-only スレーブ (キー silent drop)。スレーブは master 失効後も自動昇格しない (再接続が必要)。
- → 単一の永続 KVM セッションを保持し続ける運用が必須 (open/close を繰り返さない)。master 取得の確認は ArrowRight→ArrowLeft のタブ切替で画面 size が変化するかでテストする (F1 General Help は Esc で閉じないことがあり制御テストには使わない、上記ハードニング 1 参照)。取れなければ close → 40s 待 → 再接続をリトライ。これは昇格済みの永続セッションサーバ
scripts/irmc-kvm/server.py (コマンドファイル駆動、gain_control が ArrowRight 方式で master を確認) が実装済み。
- viewer 再接続直後は
#cursor_canvas overlay で canvas が一時 invisible になり screenshot が timeout することがある → bounding_box の width/height>100 を待つ。
- 🆕🆕 (2026-06-01 jiggly12 で実証) modal ダイアログを開くと canvas がキーボードフォーカスを失う。Clear/Save Configuration の確認ダイアログ・Confirm ドロップダウン・OK メッセージボックスを開いた直後は、
press した矢印キーが全て silent drop され、▶No 等の静的マーカーに騙されて「効いていない」と誤認する (実際は届いていない)。対策: ダイアログを開いたら必ず実マウスクリック mouse 512 384 を 1 回送ってフォーカスを再確立してからダイアログキーを送る (focus コマンド = force-click では不十分、mouse の実クリックが必要)。メニュー階層のキーはフォーカス喪失の影響を受けない (ダイアログ限定)。なお BIOS Aptio はマウスで選択を動かさないので mouse 512 384 (画面中央の空白) はカーソル位置を壊さず安全。
- 🆕🆕 ダイアログ内のカーソル位置は「Confirm ドロップダウンが開くか」で決定的に判定できる。reverse-highlight は間欠的に非描画になり ▶No は静的なので画面から位置が読めないことが多い。
ArrowUp×2 → Enter で Confirm ドロップダウン (Disabled/Enabled) が開けば cursor は Confirm 行にいた証拠 (開かず dialog が閉じれば No 上だった)。最終 commit の ArrowDown→Enter も結果で分岐してよい: 成功メッセージ=Yes 押下成功 / ドロップダウン再展開=Confirm 上 (Arrow drop) / メニュー復帰=No 上 — Yes 以外は全て非破壊なので安全にリトライできる。
- 🆕🆕 (jiggly12) サブメニューから Escape で戻った直後はカーソル位置が不定 (下方向にドリフト)。VDM → Escape → Main Menu の後に
ArrowUp×2 を送っても Configuration Management(1番目) でなく Drive Management(4番目) に着地する事例が 2 回再現。Escape 後は行位置を固定送信せず、右ヘルプ文言で現在行を確認してから ±補正する。「メニューキーはダイアログと違い影響なし」は同一画面内の話で、画面遷移 (Escape) はカーソルをずらす。
- 🆕 Create VD フォームの
Protect Virtual Drive [Disabled] は非選択 (カーソルが止まらない) 表示行。Select RAID Level から ArrowDown×2 がちょうど Select Drives (Protect はスキップ)。×3 だと CONFIGURE ヘッダもスキップして Virtual Drive Name へ行き過ぎる (→ ArrowUp×1 で戻す)。
🆕 標準手順: スクリーンショット分析はサブエージェントに委任する
per-key 操作の各 shot は、主エージェントが画像を直接 Read してはならない。general-purpose サブエージェント (Agent ツール) に screenshot の絶対パスを渡し、構造化報告だけを受け取って次キーを決める。 これは 2026-06-01 (503d9361) の 3 サイクル検証で確立した方式で、(1) per-key の状態確認が確実になり、(2) 主エージェントの context を画像で埋めずに済む (長い AVAGO HII セッションでは数十〜百枚の shot を撮るため必須)。
運用ルール:
- 1 shot = 1 サブエージェント呼び出し。
scripts/irmc-kvm/server.py の shot <name> で <srv-dir>/shots/<name> を生成 → そのパスを Agent に渡す。
- 主エージェントはサブエージェントの報告 (テキスト) だけで判断し、画像そのものは読まない。判断に迷う時のみ自分で Read する (例外)。
- サブエージェントには必ず次の 6 項目を構造化報告させる:
- 選択中タブ (Main / Advanced / Security / Boot / Save&Exit のどれがハイライトされているか)
- カーソル行のテキスト — ▶ 静的マーカーではなく反転背景 (白背景に暗い文字) の行を読む。AVAGO の ▶No 等は実フォーカスを示さない
- 右ヘルプペインの全文 (行の同定に最も信頼できる。例:
"Deletes all existing configurations..." = Clear Configuration)
- ダイアログの有無と状態 (Confirm が [Disabled]/[Enabled] のどちらか、Yes/No のどちらが反転背景か)
- 黒画・凍結の有無 (全黒 / 同一フレーム)。ただし KVM canvas 黒画は framebuffer artifact のことがあるので黒画単独で hang 判定しない (真実は OEM 真VGA と SOL)
- 画面見出し (例:
CONFIGURE VIRTUAL DRIVE PARAMETERS, Virtual Drive Management)
コピペ用サブエージェントプロンプト雛形 (Agent ツール, subagent_type=general-purpose):
次の iRMC KVM スクリーンショット画像を Read して、AVAGO MegaRAID HII / Aptio BIOS Setup の
画面状態を構造化報告してください。判定は ▶ 等の静的マーカーではなく「反転背景 (白背景に暗い文字)
のハイライト行」で行うこと。
画像: /home/ubuntu/projects/pvese/tmp/<sid>/srv/shots/<name>.png
以下を箇条書きで報告:
1. 選択中タブ (Main/Advanced/Security/Boot/Save&Exit のどれが選択されているか。BIOS タブが見えなければ "なし")
2. カーソル(反転背景ハイライト)が乗っている行のテキスト全文
3. 右ヘルプペインの全文 (画面右側の説明。無ければ "なし")
4. ダイアログ有無と状態 (Confirm=[Disabled]/[Enabled]、Yes/No のどちらが反転背景か。無ければ "ダイアログなし")
5. 画面が全黒か / 凍結 (描画不全) しているか
6. 画面の見出し・タイトル行のテキスト
推測は避け、画像から読み取れた文字をそのまま引用すること。
⚠️ commit が不可逆な操作 (Save Configuration / Clear Configuration の Yes 押下) の直前は、サブエージェント報告で 項目4 の「Yes が反転背景」を確認してから Enter を送ること。盲目送信は禁止。
🎯🎯🎯 2026-06-01 (503d9361): 削除→再作成 3 サイクル完遂 — レシピ反復再現性確定 + ハードニング知見
cosmic-aho 続きで確立した削除→再作成レシピを 3 サイクル連続で完遂し、反復再現性を確定 (issue #73)。構成: ベースライン作成 + 3×(削除→検証→再作成→検証) = 削除レシピ ×3 + 作成レシピ ×4 を全て KVM canvas + OEM 真VGA で二重裏取り。最終状態 VD0 RAID0 3.272TB Optimal。
このセッションで上記レシピ (確認ダイアログ commit / Create VD / Clear Configuration) はそのまま安定動作し、信頼できると確定。ただし無人完走には以下の per-key ハードニングが必須:
- 🆕 KVM canvas にスクリーンショット遅延がある — press が実際には登録済でも、直後に撮った shot が 1 つ前の stale フレームを返す。ArrowLeft を 2 回送って「1 回目が効いてない」と誤認したが、実際は両方効いており shot が遅れていただけだった (Security→Advanced→Main と 2 タブ動いていた)。→ press 後に
sleep 2.5 を挟んでから shot を撮る。盲目で「効いてない」と判断して再送するとオーバーシュートする。
- 🆕 コミット確認ダイアログは 2 段階に分けて裏取りする — 確認レシピ (ArrowUp×2→Enter→ArrowDown→Enter→ArrowDown→Enter) を盲目で一括送信せず: (段階1)
ArrowUp×2→Enter→ArrowDown→Enter まで送り Confirm が [Enabled] になったか screenshot 確認 → (段階2) ArrowDown を送り Yes の反転背景 (ハイライト) を確認してから最後の Enter (commit)。commit は不可逆なので Yes ハイライトの目視確認は必須。▶No は静的マーカーで実フォーカスを示さない — 判定は必ず「反転背景 (白背景に暗い文字)」で行う。
- 🆕 Create VD form の Select Drives ナビは ArrowDown×2 が 1 手前に着地することがある — キードロップで
Select Drives (▶) でなく Select Drives From [Unconfigured Capacity] で止まる。右ヘルプ Dynamically updates to display as Select Drives or Select Drive Group based on the selection made in Select Drives From. が出る行が Select Drives (▶)。ズレたら ArrowDown/ArrowUp で ±1 キー補正。CONFIGURE VIRTUAL DRIVE PARAMETERS ヘッダ行はカーソルがスキップするので ArrowDown 1 で Select Drives→Virtual Drive Name へ飛ぶことに注意。
- 🆕 作成完了の 2 つ目メッセージは Escape、削除完了の OK は Enter — 作成 commit 後の
"The operation has been performed successfully." (►OK) を Enter で閉じると次に "Virtual Drive creation was successful. All free configurable space has been used." (OK ボタン無し) が出る → Escape で閉じる。一方削除 commit 後の "The operation has been performed successfully." (►OK) は Enter 1 回で Config Mgmt に戻る (2 つ目メッセージ無し)。
- 🆕 ArrowDown が稀に ArrowRight に誤登録しタブ移動 (Advanced→Security 等) が起きる → 各操作後にタブ名を確認、ズレたら ArrowLeft で戻す。
- 🆕 アイドルタイムアウトからの復旧フローを実証 (1 スクリプトに昇格済) —
server.py の idle timeout (既定 7200s) で master を失った場合は ./scripts/irmc-kvm-recover.sh config/training_tx1320.yml 1 本で復旧する (kill → host ForceOff → Manager.Reset リトライ → BMC 復帰 poll → boot-override BiosSetup + power on → POST 待ち → OEM で BIOS 到達確認)。完了後に scripts/irmc-kvm/server.py を再起動し === KVM server READY === を待つ。復旧後 master は attempt 数回でクリーン取得でき、RAID は NVRAM 永続なので無影響。復旧後は BIOS Main タブから AVAGO へ再ナビ (Main→ArrowRight→Advanced→ArrowDown×14→AVAGO 行)。
- 🆕 画像分析はサブエージェントに委任 (標準手順へ昇格済) — per-key の各 screenshot 判読は主エージェントが直接 Read せず general-purpose サブエージェントに委任する。確実かつ context 消費を抑えられる。具体手順・報告 6 項目・プロンプト雛形は上記「🆕 標準手順: スクリーンショット分析はサブエージェントに委任する」節を参照。
運用ニュアンス (頻度・等価性):
- drives popup の Apply Changes は上部/下部どちらでも等価 — Check All の後
ArrowDown×2 が wrap して「上部 Apply Changes」に着地することがあるが、上部・下部とも右ヘルプは "Submits the changes made to the entire form." で機能同一。どちらに着地しても Enter でよい (どちらかに固執して補正し過ぎない)。
- Select Drives ナビのキードロップは散発 —
ArrowDown×2 での Select Drives 着地は 3 サイクル中ほぼピタリで、1 手前 (Select Drives From) に止まるのは散発 (4回中1回)。毎回ズレる訳ではないので、まず ×2 を送って右ヘルプで確認し、ズレた時だけ ±1 補正すればよい。
- OEM 真VGA スクショは初回空振り→retry することがある —
irmc-oem-screenshot.sh は健全時でも Preview not available after 12s, retrying で 1 回目空振り→2 回目成功になることがある (frame buffer 詰まりとは別)。retry 機構が吸収するので失敗扱いせず待つ。
- Config Management メニューは VD 有無で項目数が変わる + stale は非決定的 — VD あり時の正常 =
View Drive Group Properties / Clear Configuration (2項目)、VD なし時の正常 = Create Virtual Drive / Create Profile Based Virtual Drive / Clear Configuration (3項目)。操作直後は前状態の構成を残す (stale) ことがあるが回によって stale になったりならなかったりする。→ Clear Configuration の行位置は構成で変わる (2項目なら ArrowDown 1、3項目なら ArrowDown 2) ので行位置を固定送信せず、行テキスト + 右ヘルプ "Deletes all existing configurations..." を確認してから Enter。VD 有無の最終判定は常に Virtual Drive Management で。
- 🆕 KVM セッションは正常終了 (close/quit) させてから切ると次の master 取得が速い — idle timeout で
exit 0 正常終了した後の復旧では lingering master が残らず初回接続で即 master 取得できた (cosmic-aho の「BMC reset 直後 slave 着地リトライ要」と対照的)。無人運用で session を畳む時は強制 kill より quit を優先。
検証に使ったツールは scripts/ に正式昇格済 (2026-06-01 issue #73、下記「昇格済みツール (scripts/) と使い方」節)。詳細な per-key ログ + 確立レシピは tmp/503d9361/CYCLE_LOG.md (コピー元として温存)。
昇格済みツール (scripts/) と使い方
3 サイクル検証で機能した KVM 駆動・復旧フローを scripts/ に昇格した (旧 tmp/503d9361/ 使い捨て版から: 認証情報を引数化、session dir をパラメータ化、復旧フローを 1 スクリプトに集約)。
| スクリプト | 役割 |
|---|
scripts/irmc-kvm/server.py | 永続 KVM セッションサーバ (FW 9.69F)。master 制御を 1 セッションで保持し、コマンドファイル駆動で per-key 操作 |
scripts/irmc-kvm/kvmlib.py | FW 9.69F cookie ログイン open_viewer (sid cookie 方式)。_util.py のナビ/検出ヘルパーを再エクスポート |
scripts/irmc-kvm/_util.py + fingerprints.json | ナビ/検出エンジン (shot/press/nav_cursor_to_y/detect_*) + AVAGO 画面 size 指紋。tmp/iter/ から昇格 |
scripts/irmc-bmc-reset-retry.sh | Manager.Reset を "Blocked" の間リトライ (host Off で通る) |
scripts/irmc-kvm-recover.sh | BIOS Setup + KVM 取得可状態への復旧フロー (config 駆動、上記ハードニング 6) |
昇格しなかったもの: cycle_runner.py (caret 盲信欠陥で NIC 画面誤入する自律ループ — 非推奨)、pw.sh/snap.sh (既存 bmc-power.sh/irmc-oem-screenshot.sh の薄ラッパー)。
永続 KVM サーバの起動 (run_in_background で起動し === KVM server READY === を待つ):
BMC_IP=$(./bin/yq '.bmc_ip' config/training_tx1320.yml)
BMC_USER=$(./bin/yq '.bmc_user' config/training_tx1320.yml)
BMC_PASS=$(./bin/yq '.bmc_pass' config/training_tx1320.yml)
.venv/bin/python scripts/irmc-kvm/server.py \
--bmc-ip "$BMC_IP" --bmc-user "$BMC_USER" --bmc-pass "$BMC_PASS" \
--srv-dir tmp/<session-id>/srv
コマンドファイル駆動: <srv-dir>/in/NNN.cmd (連番、1 行 1 コマンド) を投入 → NNN.done への rename を待つ → <srv-dir>/shots/<name> をサブエージェントで判読 (上記標準手順)。コマンド:
| コマンド | 意味 |
|---|
press <key> [ms] | キー押下 (既定 700ms 待ち)。stale フレーム回避に press 後 sleep 2.5 推奨 |
keyrepeat <key> <n> [ms] | n 回押下 |
shot <name> | shots/<name> に screenshot + caret_y/hl_y をログ |
navy <y> [caret|highlight] [maxpress] [settle_ms] | カーソルを Y 座標まで移動 |
sleep <s> / note <text> / quit | 待機 / メモ / 終了 |
復旧 (master 喪失・idle timeout 時): ./scripts/irmc-kvm-recover.sh config/training_tx1320.yml → server.py 再起動。
⚠️ AVAGO HII の重大落とし穴 (2026-05-17 新発見)
#28. RAID 10 は最低 2 span 必須
LSI MegaRAID の RAID 10 では Span 0 = N drives + Span 1 = N drives (各 span 同数) が必須。 4-drive RAID 10 を作る場合は Span 0=2 + Span 1=2 構成。 単一 Span に 4 drives を入れると Save Configuration で:
"To create Virtual Drives for the selected RAID level, more than one span and an equal number of Drives in each span is required."
Create VD form では:
- Span 0 の Select Drives popup で 個別に 2 drives を toggle
- Apply Changes
- Add More Spans で Span 1 追加
- Span 1 の Select Drives popup で 残り 2 drives を toggle (Check All で OK)
- Apply Changes
- Save Configuration
#29. AVAGO controller NVRAM の Pending state 永続
Create VD form の Pending state (RAID Level、 Span 構成、 drive 選択など) は AVAGO controller NVRAM に永続化される。 Host reboot しても消えない。 S1+S2 (Manager.Reset + boot-override + cycle) してもリセットされない。
リセット手段は Configuration Management → Clear Configuration のみ:
- Configuration Mgmt submenu に navigate (M1+M2+M3)
- ArrowDown 2 → Clear Configuration
- Enter → Clear Config dialog
- Confirm field を [Enabled] に toggle (+ キー)
- ArrowDown → Yes
- Enter → クリア確定
#30. AVAGO HII drives popup の個別 toggle 信頼性問題
drives popup 内で ArrowDown 4 + Enter で個別 drive を toggle する経路は、 WAIT_MS=1500ms でも 30-50% の確率でキーが silent drop。 Playwright keyboard.press が CDP で送られても BMC frame buffer pipeline で drop されるケースあり。
回避策:
- screenshot で位置 verify + 想定外位置ならリトライ (アダプティブ navigation)
- Check All / Uncheck All ボタンで bulk toggle (single key で済むため信頼性高い)
- 個別 drive toggle が必須なら、 各 ArrowDown 後に screenshot 取得 + size 比較で cursor 位置確認
詳細→ report/2026-05-17_054151_tx1320_raid10_playwright_partial.md + reference.md
🚨 Manager.Reset 多用注意 (2026-05-16 #69、 #25 と関連)
BMC OEM Screenshot pipeline 詰まりの回復に Manager.Reset が必要になるが、 多用すると 1 回 200s のコスト + (前述の通り KVM 自体は壊さないと判明したものの) 各種 BMC 内部状態への影響が読みにくい。 OEM Screenshot は milestone ごと 1 回限定 に絞り、 Make POST → 5-15s 待 → Preview の単一サイクルで完結させる運用に統一する。
制限事項:
- 連続して OEM Screenshot Make を投げると BMC 全体 (Web UI/Redfish) が 60-90s 程度無応答になる。 撮影回数を限定し、 各 oem-shot 失敗時は早期 fail (poll_timeout=5s, max_attempts=3) で BMC を休ませる
- 新規 viewer session の最初の sendkeys が swallowed されることあり (canvas focus 確立に時間)。
wait:5; oem-shot:initial.jpg; を冒頭に置いて canvas refresh + focus を establish してから sendkeys する
- KVM canvas screenshot は黒のまま使えない (oem-shot を使う)
現状の workaround:
BMC Manager Reset → VGA pipeline 再初期化 — 改善せず (#69 検証済み)- OS Live ISO +
storcli で RAID 作成 (broadcom 提供 CLI) — 推奨次手 (reference.md の代替案参照)
- AVAGO HII を粘り強く操作: 1 viewer session 内で all-in-one、 OEM Screenshot は要所のみ (Main 進入、 AVAGO Main、 Create VD form、 Save 完了)
- Aptio BIOS の "BIOS Frame Buffer Mode" 設定変更 (HII でしか変更不可で chicken-and-egg)
raid status 手順
- iRMC Web UI (https://10.254.254.9/) にブラウザで接続
- claude / Claude123 でログイン
- 左メニュー → System Information → Storage タブ
- RAID コントローラ Model、VD、物理ディスク (Slot, Size, Status) を確認
raid create-r10 手順 (BIOS RAID Configuration Utility 経由)
bios enter で BIOS Setup に入る (上述)- iRMC Web UI → Console Redirection → KVM (HTML5) 起動
- BIOS Setup → Advanced → RAID Configuration Utility (LSI MegaRAID 系なら "MegaRAID Configuration Utility")
- Configure Virtual Drives → Create New VD
- RAID Level: RAID 10
- 物理ディスク 4 本選択
- Stripe Size: 64 KB (デフォルト)
- Initialization: Fast
- Save → Exit → 再起動
- 起動後に
raid status で VD0 (≒ 1.8 TB) が Optimal で表示されることを確認
物理ディスクのセクタサイズ (520B / 528B) で BIOS RAID Util から認識されない場合は、OpenWrt rescue image (reference: training_tx1320 memory) で sg_format --size=512 --pinfo=0 を実施してから再試行。
raid delete 手順
同様に BIOS RAID Configuration Utility → Virtual Drives → Delete。データ消失するためユーザ確認必須。
SOL (Serial Over LAN)
本 skill では電源・BIOS が中心だが、SOL も使える (次セッションの OS install 監視用)。
ipmitool -I lanplus -H 10.254.254.9 -U claude -P Claude123 sol payload enable 2 4
ipmitool -I lanplus -H 10.254.254.9 -U claude -P Claude123 sol activate
ipmitool -I lanplus -H 10.254.254.9 -U claude -P Claude123 sol deactivate
注意事項
oplog.sh で電源・boot-override 系は記録すること (./oplog.sh ./scripts/bmc-power.sh ...)pve-lock.sh は不要 (training-tx1320 は PVE クラスタ非メンバー)- BIOS Setup へ入った後、boot-override は自動で消費される (
Once)。明示的に boot-override-reset する必要はない
- Web UI ログインは Basic Auth で通らない。form login が必要 (Console Redirection 等の機能ページに到達するには)
RAID10 storcli + preseed 経路 (2026-05-17 #5 d-eager-island で確立)
⚠️ 2026-06-02 (d0a59391, issue #69) 更新: かつて KVM HII 経路は 2026-05-17 #4 で「dead end 確定」とされたが、これは 偽陰性であり覆った。FW 9.69F + ハードニング済みツールで Select RAID Level に到達でき、RAID10 を含む全レベルが HII KVM で作成可能（上記「🎉🎯🎯🎯 2026-06-02 ... RAID10 dead end は覆った」節）。以下の旧「dead end」記述は 歴史的経緯として残す。storcli + preseed 経路は HII KVM 経路とは独立した有効な代替であり、OS install 中に RAID10 を作る用途では引き続き第一候補。
旧判定 (2026-05-17 #4、現在は覆った):
- Aptio HII Create VD form の "Select RAID Level" (y=128) に ArrowDown/Up/Tab/Click/Home/End/PageUp/PageDown の全 9 経路で navigation 不能（と当時は判断 → 旧 FW/旧ツール/カーソル誤検出の複合アーティファクトだった）
- Profile-Based VD は Generic RAID 0/1/5/6 のみで RAID 10 不在（→ Profile 経路に依らず通常の Create Virtual Drive で RAID10 を直接選択可能と判明）
- 詳細: report/2026-05-17_101536_tx1320_raid10_dead_end.md
storcli 経路の方針: Debian preseed partman/early_command で storcli64 を実行して RAID10 を作成 → そのまま OS install へ続行。
KVM 操作を一切使わずに RAID10 + Debian + 必要パッケージまで 1 ISO・1 boot で完結する。
Web 版 Claude の知見:
- MegaRAID は RAID 10 を「RAID 1 + Span 2」として実装 (基本 level: 0/1/5/6 + spans: 10/50/60)
- HII Profile-Based に RAID 10 が無いのは仕様 (シンプルウィザード保護)
storcli /c0 add vd type=raid10 size=all drives=<EID>:0-3 pdperarray=2 が業界標準の一発作成
使い方 (一発実行)
./scripts/tx1320-raid10-orchestrate.sh apply config/training_tx1320.yml
これで以下が順番に実行される:
scripts/fetch-storcli-deb.sh で Broadcom 公式 zip から storcli_007.2705.0000.0000_all.deb を抽出 → /var/samba/public/storcli64.deb (既存ならスキップ)scripts/generate-preseed.sh --with-raid10-storcli で partman/early_command directive 入り preseed.cfg 生成scripts/remaster-debian-iso.sh --include=... で debian-13.3.0-amd64-netinst.iso を base に preseed + storcli64.deb + setup-raid10-storcli.sh を ISO ルート同梱 → debian-training-tx1320-raid10.isoscripts/irmc-virtualmedia.sh config で SMB (10.1.6.1/public) CDImage に新 ISO を mountscripts/bmc-power.sh boot-override Cd UEFI + forceoff + on で CD boot
その後 SOL 監視:
./scripts/tx1320-raid10-orchestrate.sh monitor config/training_tx1320.yml --timeout 1800
preseed 経由で実行される RAID10 作成 (scripts/setup-raid10-storcli.sh)
ISO 内 /cdrom/setup-raid10-storcli.sh が installer 環境で実行される。 内部処理:
dpkg -i /cdrom/storcli64.deb (失敗時は in-target 経由 + dpkg-deb -x fallback)storcli64 /c0 show で controller 認識確認storcli64 /c0/vall delete force で既存 VD クリア (失敗は無視)storcli64 /c0/eall/sall show で物理ドライブ列挙 → awk で先頭 4 本の EID:Slot を抽出storcli64 /c0 add vd type=raid10 size=all drives=<EID:Slot,...> pdperarray=2 wb ra direct strip=256storcli64 /c0/vall show | grep RAID-?10 で assert
ログは /var/log/raid10-setup.log に蓄積 (install 完了後 SSH で cat /var/log/raid10-setup.log 確認可)。
終了コード意味:
- 0 = OK
- 4 =
/cdrom/storcli64.deb 不在 (ISO remaster 失敗 / mount 失敗)
- 5 = storcli64 install 失敗 / 認識不可 (controller 型が想定外)
- 6 = 物理ドライブ数 < 4 (drive 故障 / slot 構成変更)
- 7 =
add vd type=raid10 が成功しなかった (controller がコマンド拒否)
検証
OS install 完了後、 DHCP で取得した IP に SSH:
ssh -F ssh/config <dhcp_ip> 'lsblk; storcli64 /c0/vall show all'
失敗時のフォールバック
| トリガ | 対応 |
|---|
| Broadcom URL が dead | fetch-storcli-deb.sh の STORCLI_URL env で旧バージョン指定。https://downloadmirror.intel.com/685225/StorCLI_007.1704.0000.0000.zip が Intel mirror として使える |
dpkg -i /cdrom/storcli64.deb が installer 環境で失敗 | setup-raid10-storcli.sh が in-target 経由再試行 + dpkg-deb -x で /usr/local/bin/storcli64 直接配置にフォールバック |
add vd type=raid10 失敗 | controller が SAS3108 ではない可能性。`storcli64 /c0 show all |
| iRMC SMB Virtual Media attach 失敗 → 解決済 (2026-05-17 #6 p-effervescent-kahn) | 真因: スクリプトが irmc-virtualmedia.sh config に smb_user/smb_pass を渡さず 空文字列で PATCH していた → iRMC が guest 認証として処理せず silent reject。 Members@odata.count=0 のまま、 Samba log にも接続痕跡なし、 ARP L2 reachable でも attach trigger されない症状を呈していた。 解決策: config/training_tx1320.yml に smb_user: guest / smb_pass: guest を追加 + tx1320-raid10-orchestrate.sh の deploy で yq 読み込み + irmc-virtualmedia.sh config に引数 7-8 として明示渡し。 加えて、 OEM Action POST /redfish/v1/Systems/0/Actions/Oem/FTSComputerSystem.VirtualMedia {"VirtualMediaAction":"DisconnectCD"} → ConnectCD で USB redirector を fresh attach できる (BIOS POST 中 USB enumeration の遅延を吸収して boot-override Cd UEFI が機能する)。 注意: VirtualMediaAction@Redfish.AllowableValues は接続状態に応じて Connected→["DisconnectCD"] / Disconnected→["ConnectCD"] で動的、 BIOS Setup 中は [] で発行不可。 |
| boot 進まない / GRUB 出ない | Secure Boot 状態を BIOS Setup で確認、ISO の hybrid UEFI 構成 (-update efi.img) が成功しているか remaster ログで確認 |
| installer cdrom-detect が iRMC Virtual CD を見つけない → kernel cmdline 注入は無効 (2026-05-18 #7 s-peaceful-hinton) | 症状: CD boot + kernel boot は成功するが、 d-i [!!] Detect and mount installation media — No device for installation media was detected で停止し、 Load drivers from removable media? <Yes><No> dialog で input 待ち。 #7 で kernel cmdline (GRUB legacy / ISOLINUX / EFI 全 3 経路) と preseed.cfg.template の両方に cdrom-detect/try-usb=true cdrom-detect/scan=true hw-detect/load_media=false を仕込んで再試行 → 効かず。 真因仮説: iRMC OEM CDImage は GRUB レベル (BIOS USB CD-ROM emulation) では読めるが、 Linux 起動後の installer cdrom-detect は udev/sysfs に依存し、 iRMC の USB CD emulation が installer の udev rule にマッチしない。 preseed.cfg は /cdrom/preseed.cfg から load される設計上 cdrom-detect 失敗の時点で適用されない (chicken-and-egg)。 次に試す候補 (優先順、 未実施): (1) initrd preseed 注入 + preseed/early_command で自前 mount /dev/sr0 /cdrom (cdrom-detect/cdrom_device=/dev/sr0 等 combined cmdline も試す)、 (2) iRMC HDImage (USB Mass Storage) 経由配信 — CDImage の代わりに HDImage で ISO を送れば /dev/sdX として block device 認識される可能性、 (3) hd-media モード (vmlinuz-hd-media + initrd-hd-media.gz) + ISO ファイル mount、 (4) PXE / netboot 経路 — 完全に iRMC Virtual Media 廃止、 (5) Live ISO + 手動 storcli RAID 作成 + 別経路で OS install pivot |
| 全自動化失敗 | last resort: iRMC KVM Web UI をブラウザで開いて Aptio HII で Select RAID Level に直接 mouse click → 手動で RAID 10 作成 |
🎯 NFS Virtual Media 経路 (2026-05-21 s-snuggly-goblet → s-linear-gizmo で確立)
背景: SMB 死亡 → NFS bypass
iRMC S4 FW 9.08F の SMB worker は 2026-05-20 以降死亡継続中 (silly-token で Manager.Reset / VirtualMediaServiceRestart / RemoteMountEnabled toggle / OEM ConnectCD / 物理電源切離 の 5 経路すべて試行で復活せず確認)。 代替として s-snuggly-goblet が NFS worker は別 process で生存していることを実機実証 (report/2026-05-21_081642_tx1320_raid10_nfs_attempt.md)。
s-linear-gizmo (Phase 2) で本コードに統合済。 training_tx1320 のデフォルト経路は NFS。
SMB vs NFS スキーマ比較
| 項目 | SMB | NFS |
|---|
CDImage.ShareType | "SMB" | "NFS" |
CDImage.UserName / Password | 必須 (guest/guest) | 空文字列 (iRMC が null 化) |
CDImage.ShareName | "public" (バックスラッシュ無し) | "/var/samba/public" (POSIX export path) |
AutoAttach (RemoteMountEnabled=true で attach 成立) | ✅ する (worker 生存時) | ❌ しない — ConnectCD POST 必須 |
Actions...VirtualMediaAction@Redfish.AllowableValues | 動的: ["ConnectCD"] ↔ ["DisconnectCD"] | 同左 |
| 認証 | Samba ACL | IP based (/etc/exports の subnet 指定) |
| 交渉 protocol | SMB1/2/3 (worker bug で 4.19.5 死亡) | NFSv4 (v4root pseudo-fs 自動 export) |
使い方 (NFS)
config/training_tx1320.yml に NFS keys が設定済:
virtual_media_type: nfs
nfs_host: 10.1.6.6
nfs_export_path: /var/samba/public
orchestrator は yq でこれを読み、 Phase 5a で以下を自動実行:
./scripts/irmc-virtualmedia.sh --share-type=NFS config \
10.254.254.9 claude Claude123 \
10.1.6.6 /var/samba/public debian-training-tx1320-raid10.iso
./scripts/irmc-virtualmedia.sh connect-cd 10.254.254.9 claude Claude123
./scripts/irmc-virtualmedia.sh --share-type=NFS mount 10.254.254.9 claude Claude123
mount は /redfish/v1/Systems/0 の Actions.Oem.#FTSComputerSystem.VirtualMedia.VirtualMediaAction@Redfish.AllowableValues を 12 回 × 5 秒で polling し、 ["DisconnectCD"] 出現で attach 成立と判定。
NFS server (10.1.6.6) セットアップ
s-snuggly-goblet で構築済 (nfs-kernel-server + rpcbind):
/var/samba/public 10.0.0.0/8(ro,no_subtree_check,all_squash,insecure,anonuid=65534,anongid=65534)
sudo exportfs -ra で reload。 ISO は /var/samba/public/debian-training-tx1320-raid10.iso に配置 (orchestrator が build したものを rsync で push)。
落とし穴
| 症状 | 対処 |
|---|
| PATCH HTTP 412 | ETag が古い。 irmc_get_etag で再取得 (既存 quirk) |
| ConnectCD HTTP 204 だが AllowableValues 未遷移 | /redfish/v1/Systems/0 を見ているか確認 (OEM VM endpoint には AllowableValues は無い)。 NFS server 側で sudo tcpdump -i ens19 -nn 'host 10.254.254.9 and port 2049' で packet 到達確認。 0 packet なら L2/route、 packet あって stuck なら export 権限 |
| ConnectCD だけで Web UI 上は接続表示なし | 正常。 host が PowerState=Off の間は DMTF /Managers/iRMC/VirtualMedia の Members.count は 0 のまま。 host boot 時に USB redirector が device を expose する |
| NFS export 範囲外 (10.0.0.0/8 以外から) | training-tx1320 (10.254.254.9) は 10.0.0.0/8 内。 別 server を使う場合は export 範囲を調整 |
| ✅ GRUB→kernel jump 後 SOL/VGA 完全沈黙 (2026-05-22 Phase 13 silly-rocket で真因確定・解消、 詳細は本 skill 末尾の Phase 13-19 セクション) | NFS attach + GRUB boot は正常で Booting Automated Install まで届く。 ところが直後の kernel printk が 0 行、 KVM VGA も完全黒で host 凍結。 Phase 3 で quiet 除去でも earlyprintk=ttyS0,115200n8,keep 追加でも効かず、 さらに NFS pcap で host からの READ packet が一切無いことを確認 (kernel が CD-ROM device を access していない = USB CD-ROM enumeration 以前で hang/panic)。 真因は kernel cmdline option では治らない。 次セッションは BIOS XML backup (bios backup) で Console Redirection / Secure Boot / Boot Mode を 2026-05-18 SMB session #6 当時と比較 + git log --since=2026-05-15 -- scripts/remaster-debian-iso.sh で cmdline diff 確認、 USB stick 等で NFS Virtual Media を bypass した切り分けが必要。 詳細 → report/2026-05-22_004000_tx1320_raid10_kernel_silent_persist.md + memory training_tx1320_kernel_silent_post_grub.md |
SMB フォールバック (緊急時のみ)
万一 NFS worker も死亡した場合:
./scripts/irmc-virtualmedia.sh disconnect-cd 10.254.254.9 claude Claude123
./scripts/irmc-virtualmedia.sh --share-type=SMB config 10.254.254.9 claude Claude123 \
10.1.6.1 public debian-training-tx1320-raid10.iso guest guest
ただし FW 9.08F の SMB worker 死亡は wontfix 確定なので、 NFS が動かない場合は別 NFS server (proxy-ARP 配下) を立てる方が現実的。
RAID10 storcli + preseed 経路 — 2026-05-17 #5 d-eager-island の実機検証結果
- ✅
scripts/fetch-storcli-deb.sh で Broadcom 公式 zip → storcli64.deb (2 MB) 取得成功 (URL: https://docs.broadcom.com/docs-and-downloads/007.2705.0000.0000_storcli_rel.zip)
- ✅
scripts/generate-preseed.sh --with-raid10-storcli で preseed に partman/early_command directive 挿入確認
- ✅
scripts/remaster-debian-iso.sh --include=... で 764 MB の Debian + storcli64.deb + setup-raid10-storcli.sh 同梱 ISO 生成成功
- ✅
irmc-virtualmedia.sh config で OEM Redfish に CDImage 設定書込成功 (HTTP 200、 ETag 通る)
- ❌ iRMC が SMB 経由で CDImage を実際に attach しない —
/Managers/iRMC/VirtualMedia/Members 0 のまま、 Samba 側にも接続痕跡なし、 ConnectCD OEM action 発行も無効
- ❌ BIOS は boot-override Cd UEFI を消費したが、 attach されていない CD は boot 不可 → BIOS Setup に fallback
- 次セッションへ: 上記フォールバック表の (b)〜(d) のいずれかで配信経路を解決すれば、 残りのワークフローは即実行可能
Phase 13-19 で確定・解消した課題 + PXE 経路への pivot
🎯 Phase 13 (2026-05-22 silly-rocket): kernel silent hang の真因 = console=tty0
D3373 では cmdline に console=tty0 が含まれると kernel が VGA console init で hang する (SOL printk ゼロ、 VGA も凍結)。 これが Phase 2-12 で「kernel hang」 「triple-fault」 と切り分けに苦労した silent 沈黙の真因。
- 対策済:
scripts/remaster-debian-iso.sh L124/L134/L197、 scripts/generate-preseed.sh (CONSOLE_ORDER) から console=tty0 削除済 (commit 履歴参照)
- 検証手順: cmdline 変更後 ISO/preseed 再生成 → deploy → SOL に
Linux version printk が出れば成功
- 詳細:
report/2026-05-22_*_tx1320_raid10_phase13*.md、 memory training_tx1320_kernel_silent_post_grub.md
✅ Phase 15 (2026-05-23 bubbly-ripple): cdrom-detect sr0→sr1 patch
cdrom-detect が物理空 DVD (/dev/sr0) を先に試して諦め、 iRMC 仮想 CD (/dev/sr1) をスキャンしない問題。 remaster-debian-iso.sh に PVESE_PATCH_CDROM_DETECT=1 環境変数 + awk in-place patch を実装、 /dev/sr1 優先 block 挿入で fall-through 化。 Phase 16 で実機検証済。
⚠️ Phase 16-18 (2026-05-23): iRMC USB redirector 累積劣化は FW 9.69F でも解消しない
- Phase 16-17: NFS Virtual Media + PSU cold reset で apt/partman 段階まで到達。 ただし install 中も USB redirector が累積劣化 → 3 deploy で BIOS POST 99 stuck
- Phase 18: iRMC FW 9.08F → 9.21F → 9.69F 段階 update を
scripts/irmc-fw-update.sh (multipart field 名 = "file" empirical 検証、 /irmcprogress Value=0/8/9 解読、 flashSelect=255 で両 image 書込) で完遂。 ブリックなし、 auth/network/BIOS drift なし。 だが BIOS POST 99 stuck は FW level では解消しない (config/training_tx1320.yml に FW 9.69F 適用済)
- FW 9.69F の OEM Redfish API 破壊的変更:
VirtualMediaAction → FTSVirtualMediaAction、 ResetType (OEM Reset) → FTSResetType、 ScreenshotType → FTSScreenshotType。 FW 9.08F は両形式受容、 9.69F は schema-qualified のみ。 scripts/irmc-virtualmedia.sh 修正済 (commit 86f9f7e)
- 教訓: iRMC USB redirector は長時間運用で累積劣化し、 FW update では回復しない HW level の現象。 install 経路は USB redirector を bypass する PXE pivot が決定打
🎉 Phase 19 (2026-05-30 phase19a): PXE pivot で完遂 → pxe-deploy skill
iRMC USB redirector を完全 bypass する PXE/netboot 経路を確立、 Debian 13 + HW RAID10 install + claude 自力 SSH 到達まで物理操作なしで達成。 詳細手順 + 9 つの壁 + 落とし穴は pxe-deploy skill に分離記録 (skill サイズ + 経路独立性のため)。
PXE pivot に向けた iRMC BIOS の事前準備 (本 skill の bios apply-config で実施)
UEFI PXE boot option が生成されるよう、 config/<host>.yml の bios_settings.supported に追加:
bios_settings:
supported:
BootOptionFilter: "UEFI only"
LaunchPxeOpRomPolicy: "UEFI only"
NetworkStack: "Enabled"
IPv4PxeSupport: "Enabled"
→ bios apply-config で BSPBR backup → 編集 → restore → cycle (boot phase で適用)。 これが Disabled だと boot-override Pxe が BIOS Setup に落ちる (Phase 19 壁 #1 で実証)。
関連知見 (本 skill にも記録すべきもの)
- SOL は read-only (D3373 は Console Redirection 機能なし、 SOL stdin は host UART RX に届かない)。 console login 不可。 状態判断は
scripts/irmc-oem-screenshot.sh (真の VGA capture) が一次情報、 KVM canvas は黒画 artifact なので使用禁止 (本 skill の Playwright KVM セクションでも既述)
- install 進捗の真の指標: nginx access.log (preseed/storcli/phonehome fetch)。 sol-monitor の stage 検出は SOL ring buffer replay で誤検出する (前回 boot 内容を新しい install の進捗と誤認)
- 闇ネット (10.0.0.0/8) 経由 SSH: PXE install 後の installed host は eno1 (拠点 LAN、 NAT 背後で claude 不達) + eno2 (闇ネット、 gateway なし、 claude 到達可) の 2 NIC DHCP。 IP 特定は
ip neigh | grep <eno2-MAC> (phone-home が cross-site 不達でも代替可能)
詳細は pxe-deploy skill + report/2026-05-30_050830_tx1320_raid10_phase19_pxe_autonomous_ssh.md + 総括 report/2026-05-30_053607_tx1320_raid10_overview_phase1-19_summary.md。
