SDK Manager for Windowsで発生する「writing last chunk header fail - Input/output error」 — Jetson Orin NanoをNVMeへフラッシュするときの原因と回避策

Jetson Orin Nano（開発キット）をWindows上のSDK ManagerでNVMeやSDカードへフラッシュしようとすると、Sparseイメージ変換で必ず失敗する問題が報告されています。本稿では発生環境、原因の技術的な背景、実証済みの回避手順、そして長期的に取るべき対策を平易に整理します。開発現場で時間を奪われないよう、すぐ使える対処法を先に示し、そのあとで詳しい理由を解説します。[:contents]

発生環境（要点）

ホストOS：Windows 11（x86_64）
SDK Manager：Windows版（例：2.4.0 系列）
ターゲット：Jetson Orin Nano Developer Kit（例：8GB）
JetPack：6.x 系列（例：6.2.2）
ターゲットストレージ：NVMe SSD（SDカードでも同様に再現）

フラッシュ処理はWindows上のSDK Managerが内部でWSL2を使って実行する一連のスクリプトを呼び出す流れになっており、問題はSparseイメージ（system.img等）を生成する工程で発生します。NVIDIA Developer Forums

具体的な症状

フラッシュのログは以下のようなエラーで止まります（抜粋）：
Converting RAW image to Sparse image... writing last chunk header fail - Input/output error
command error code: 135
Installation failed.

これはおおむね「mksparse」などのツールが約4GB級の大きなファイルを書き込む際に、書き込み先ファイルシステムへ正しく最後のチャンクを書き込めないために起きます。問題はWindows側のNTFSドライブをWSL2側から/mnt/<ドライブ>（drvfs / 9P）越しに使っている点にあります。NVIDIA Developer Forums+1

根本原因（技術的な背景）

WSL2のマウント方式
WSL2がWindowsドライブを扱うとき、drvfs（実際は9Pプロトコル）を通じてWindows上のNTFSをマウントします。この実装はネイティブのext4等と挙動やバッファリングの特性が異なります。特に大容量ファイルの連続書き込みやスパースファイル操作で不整合やIOエラーが起きやすい事例が報告されています。Super User+1
mksparseとdrvfsの相性
mksparse等のツールは大きなRAWイメージを変換するときにファイルオフセットやチャンクヘッダを書き換えますが、この一連の操作がdrvfs（9P）上だとうまく同期されなかったり、チャンク書き込みが途中で失敗することがあるようです。フォーラム報告では、WSL2のdrvfsマウント時にmsize等のパラメータをいじっても根本解決しなかった例が記録されています。NVIDIA Developer Forums+1
appendWindowsPath の影響（副次的因子）
WSL側の /etc/wsl.conf 設定で appendWindowsPath=true にしていると、Windows側のPATHがWSL環境へ追加され、意図せずWindowsバイナリや環境が参照されることがあります。これがスクリプトの挙動を変え、フラッシュ処理が失敗するケースが確認されています。多くのユーザは appendWindowsPath=false に変更することで余計な干渉を回避しています（ただし設定反映のためにはWSLの再起動が必要）。Zenn+1

確実に動く回避手順（実証済み）

以下は実際に成功が確認された手順です。要点は「Windows上のNTFS領域ではなく、WSL2のネイティブファイルシステム内でイメージ作成／フラッシュを行う」ことです。

SDK Managerでダウンロードしたルートファイルシステムやツール類をWSLのネイティブ領域へ移す（例：/home/<user>/nvidia/.../rootfs/）。
例（WSL内で実行）:
sudo tar -I lbzip2 -xf /mnt/g/.../Tegra_Linux_Sample-Root-Filesystem_R36.5.0_aarch64.tbz2 -C ~/nvidia/.../rootfs/
sudo ./apply_binaries.sh
WSL内で直接フラッシュスクリプトを実行する（SDK ManagerのWindowsフロントエンドを使わず、WSLのシェルで実行）。
例（WSL内で実行）:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 -p "--no-systemimg -c bootloader/generic/cfg/flash_t234_qspi.xml" jetson-orin-nano-devkit-super internal

この流れでSparse変換はWSLのネイティブext4上で行われ、高確率で成功します。NVIDIA Developer Forums

一時的／恒久的な対策提案

短期（すぐできる）：SDK Managerのダウンロード先やインストール先をC:直下に置く、あるいはWSL内へファイルを移してからフラッシュする（上記手順）。GUIで設定できない場合は、SDK Managerでダウンロードしたファイルを手動でWSL側へコピーしてください。NVIDIA Developer Forums
中期（運用ルール）：大容量イメージ操作は常にWSLネイティブ領域で行う運用ルールを社内で徹底する。WSLの自動マウントに依存しないスクリプトを用意するのが安全です。サヌキテックネット
長期（SDK側対応）：SDK Manager（Windows版）が内部でWSL2を呼ぶ際に、大きなファイル操作はWSLのネイティブパス（例：/home/<user>/...）へ自動的に移して処理するよう修正することをメーカーへ要望してください。ユーザ側からのバグ報告やフィードバックが迅速な改善につながります。NVIDIA Developer Forums

FAQ（よくある質問）

Q. なぜSDK Managerは最初からWSLネイティブを使わないのか？
A. GUIがWindows上で動作しているため、ダウンロード先や作業ディレクトリを手軽にユーザがWindowsドライブで選べる設計になっています。ただし内部でWSLへ橋渡しする実装があるため、橋渡し先のファイルシステム特性に依存する不具合が生じます。NVIDIA Developer Forums+1

Q. appendWindowsPath=false にすべきか？
A. 開発環境によりますが、WSL内でWindowsのPATHが邪魔をする（Windowsバイナリが優先される）事象がある場合は appendWindowsPath=false を検討してください。設定変更後は wsl --shutdown 等でWSLを再起動する必要があります。なお、環境によってはこの設定が期待通りに反映されない報告もあるため注意してください。Zenn+1

まとめ（実務向け要約）

問題：Windows上のSDK ManagerがWSL2経由で実行するフラッシュ処理で、NTFS（/mnt/…）向けの大容量スパースファイル生成が失敗する。NVIDIA Developer Forums
最速の回避策：ダウンロードしたrootfsやツールをWSLネイティブ領域へ移し、WSL内で直接フラッシュを実行する。NVIDIA Developer Forums
推奨：開発チームは運用ルールとして「大きなファイル操作はWSLネイティブへ」を徹底し、SDKベンダーへは「WSLネイティブパスを使う実装」または公式の手順書の公開を要望してください。NVIDIA Developer Forums+1

本稿は実例に基づいて技術的原因と現場で使える回避手順を整理しました。現場で再現する場合はログ（エラーメッセージ、WSLのdmesg出力、mountオプション）を手元で確認すると原因特定が速くなります。必要であれば、WSLのマウント設定や wsl.conf の具体的な編集手順、ログの読み方を別稿で詳述します。