【体験談】「修復が必要」ループに陥った iPad を DFU 復元で救出した記録

iPad が「修復が必要」の画面から出てこなくなりました。

言われるまま Wi-Fi を繋ぐと、診断が走って、再起動して、また同じ画面。設定から「すべてのコンテンツと設定を消去」をやっても、何も変わらない。

普通ならここで青ざめるところですが、正直そこまで悲観はしていませんでした。この時代の AI なら、まあ何とかしてくれるだろうと。

ケーブルを繋いで、状況を全部投げて、それでもどうにもならなければハンマーで壊すか。だいたいそのくらいの気持ちで MacBook の前に座りました。

結果から書くと、壊さずに済んでいます。ハードウェアはどこも壊れていませんでした。必要だったのは、DFU モードから復元することだけ。

今回の環境です。

初期化しても直らないのには理由がある

「すべてのコンテンツと設定を消去」は、動いている iPadOS が自分自身に対して実行する処理です。自分でデータボリュームを消して、自分で初期状態を組み直す。

修復する側と、修復される側が同じ。

壊れているのがシステムボリュームや APFS のメタデータ側だと、消去の命令を受け付けて実行する当人がすでに壊れています。同じ壊れた状態を、丁寧に作り直して終わる。

記憶をなくした人に「自分で思い出して」と頼んでいるようなものです。何度頼んでも無理。

「修復が必要」の画面のほうも、実は小さな復旧用 OS が起動している状態です。あの裏では、こういう周回が起きています。

1. 復旧用 OS が起動する
2. Wi-Fi を要求する
3. Apple から修復用のデータを取ってくる
4. 本体のシステム領域に当てる
5. 再起動する
6. うまく当たっていなければ、1に戻る

無限ループの正体はこれ。当てる先が「復旧用 OS の手に負えない壊れ方」をしていると、永遠に同じ輪を回ります。ユーザーから見えるのは「Wi-Fi 繋いだのにまた同じ画面」だけ。

だから、輪の外に出る必要がありました。

DFU（Device Firmware Update）モードは、iPad 側のソフトウェアが一切関与しません。SoC に焼き込まれた、書き換えのきかない最初の一段が、直接 USB を待ち受ける。iPadOS も復旧用 OS も動いていない。ブートローダーすら Mac から流し込まれます。

壊れた当人に頼むのをやめて、外から丸ごと上書きする。やったことは、要するにそれだけです。

修理に出す前に、USB で見えるかだけ見る

修理に出そうか迷っている人がいたら、その前にこれを叩いてほしい。

system_profiler SPUSBDataType | grep -B2 -A8 -iE "iPad|Apple Mobile Device"

通常モードで繋いだときの出力がこれでした。

iPad:
  Product ID: 0x12ab
  Vendor ID: 0x05ac (Apple Inc.)
  Serial Number: 00008030xxxxxxxxxxxxxxxx
  Speed: Up to 480 Mb/s

ここまで出れば、電源、USB、SoC、ブートチェーンの初段は生きています。ストレージが本当に死んでいたら、普通はここまで到達しません。

この数行を見た時点で、だいぶ気が楽になりました。

ついでに Mac 側の地雷も潰しておきます。/etc/hosts に Apple の署名サーバへのブロック行が残っていると、復元がエラー 3194 や 17 で落ちる。昔なにかのツールを入れた Mac にありがちなやつです。

grep -inE "apple|albert|gs\.|itunes" /etc/hosts
df -h /

IPSW に 9GB 前後は要るので、空き容量も一緒に。

繋ぐ前に、Apple ID だけは確認する

手順に入る前に。ここだけは本当に取り返しがつきません。

「探す」がオンだった iPad を復元すると、復元後に元の Apple ID とパスワードの入力が必ず求められます。アクティベーションロックというやつです。

これが分からないと、直すどころか、二度と起動できない板が手元に残ります。中古で買った端末、家族のお下がり、会社支給の端末は、ケーブルを挿す前に持ち主と Apple ID を確認してください。

他の前提はこのあたり。

• データは完全に消える
• 5〜9GB を転送するので、純正か MFi のケーブルを Mac に直挿しする。ハブや粗悪ケーブルはエラー 4005 や 4013 の温床
• バッテリーはある程度充電しておく
• Mac をスリープさせない

DFU モードに入れる

ホームボタンのある機種（iPad 第9世代はこれ）の手順です。

1. ケーブルを繋いだまま、電源ボタンとホームボタンを同時に約10秒
2. 電源ボタンだけ離して、ホームボタンはさらに約5秒
3. 画面が真っ暗のままなら成功

秒数がシビアで、押しすぎると Apple ロゴが出て振り出しに戻ります。

※ ホームボタンのない機種は、音量↑を短く押す、音量↓を短く押す、電源ボタンを長押し（画面が消えてもさらに約5秒）、電源を押したまま音量↓を約10秒、電源だけ離して音量↓を約5秒、という順番です。今回の端末では試していないので、伝聞として書いておきます。

真っ暗な画面は、何も教えてくれない

真っ暗というのは、何も表示されていないというだけの話です。電源が落ちているのか DFU なのか、見た目では区別がつきません。

そこでもう一度 system_profiler を叩きます。

system_profiler SPUSBDataType | grep -B2 -A8 -iE "DFU|Recovery|Apple Mobile Device"

返ってきたのがこれ。

Apple Mobile Device (DFU Mode):
  Product ID: 0x1227
  Vendor ID: 0x05ac (Apple Inc.)
  Serial Number: CPID:8030 CPRV:11 CPFM:03 SCEP:01 BDID:18 ECID:xxxxxxxxxxxxxxxx IBFL:3C SRTG:[iBoot-4479.0.0.100.4]
  Speed: Up to 480 Mb/s

Product ID が 0x1227 なら DFU。通常モードのときは 0x12ab でした。

面白いのは Serial Number の欄で、番号どころか端末の素性が並んでいます。

個人的にいちばん嬉しかったのが SRTG でした。ここに出ているのが SecureROM のタグである以上、リカバリーモードの iBoot よりさらに下、本当に最下層まで降りていることになります。画面の見た目に頼らず、機械的に DFU が確定する。

CPFM:03 は製品版でセキュリティが有効な状態を指す、というのが一般に知られた読み方です。Apple の一次情報で裏は取れていないので、そういう解釈があるという程度で。ただ、この後の復元が完走したことと合わせると、チップ側に異常フラグは立っていないという見立てで合っていそうでした。

なお CPID の 8030 を、最初は A12 だと読み違えています。8020 が A12、8030 が A13 で、ひとつずれていたんですよね。ダウンロード済みの IPSW から裏を取り直しました。

cd ~/Library/iTunes/"iPad Software Updates"
unzip -p iPad_10.2_2021_26.6_23G71_Restore.ipsw BuildManifest.plist \
  | grep -oE "<string>(iPad[0-9,]+|j[0-9a-z]+ap)</string>" | sort -u

iPad12,1 iPad12,2 j181ap j182ap が返ってきて、iPad 第9世代で確定。推測で機種を語らずに済みました。

復元する前に、ログを仕掛けておく

失敗したときにエラー番号だけ渡されて途方に暮れるのが一番つらいので、始める前にログを流しておきます。

log stream --style compact --level info \
  --predicate 'process == "MobileDeviceUpdater" OR process == "AMPDevicesAgent" OR subsystem CONTAINS "MobileDevice" OR eventMessage CONTAINS[c] "restore"' \
  > ~/ipad-restore.log 2>&1 &

Mac が途中でスリープすると悲惨なので、これも一緒に。

caffeinate -dimsu -t 7200 &

今回は約9,100行が残りました。この9,100行が、後でだいぶ役に立ちます。

あとは Finder のサイドバーに出てきた iPad をクリックするだけです。「ソフトウェア: iPad DFU モード」と表示されて、「アップデートを確認」はグレーアウト。DFU は完全復元しか受け付けないので、押せるボタンが最初から1つしかありません。迷う余地がないのは、正直ありがたかった。

IPSW のダウンロードに約9分。そこから復元本体が動き出しました。

ログに FormatForAPFS => True が出た

後から読み返して、決定的だったのが3行あります。

amai: AMAuthInstallBundleCopyBuildIdentityForVariant: searching for variant Erase
(MobileDevice) Automatically set FormatForAPFS => True
(MobileDevice) State Machine Dump, status:RUNNING -
    [state:DFU remaining-cycles:2 (current state)]
      -> [state:Recovery remaining-cycles:2]
        -> [state:RestoreOS remaining-cycles:1]

variant Erase で、完全消去のコードパスが選ばれています。

問題は次の FormatForAPFS => True のほうで、これを見た時点で勝ちが決まりました。ファイルを消したのではなく、APFS コンテナそのものを作り直しています。パーティション構造もメタデータもシステムボリュームも封印も、全部捨てて更地。本体側の初期化では絶対に届かない層です。

本体の初期化はデータを消すだけ。DFU 復元は器から作り直す。

最後の State Machine Dump は、DFU から Recovery、RestoreOS へと、Mac が iPad のブート段階を一段ずつ手で組み上げている様子です。ここは眺めていて面白かった。

エラーに見えるけど無害な行

ログを流していると赤い行が出てぎょっとしますが、次の2行は正常動作です。

(MobileDevice) failed to get board config from DFU mode device
(MobileDevice) failed to get serial number from DFU mode device

DFU モードはそもそもこれらの情報を出しません。取得に失敗するのが正しい挙動。

[com.apple.amp.core:assertions] Assertion failure: err == (-43)

-43 は file not found です。IPSW のダウンロード直後にキャッシュを照合していて、まだ DB にエントリがないだけ。実害なし。

com.apple.SkyLight から出る CGSWindowShmemCreateWithPort failed も見かけますが、あれは Finder の描画まわりで、復元とは無関係です。

このへんで怖くなって手を止め、DFU を抜けてしまうのが一番もったいない。

復元が落ちたときの切り分け

今回はどのエラーにも遭遇していないので、ここは一般に流布している解釈として読んでください。

特に 4014 は、失敗ではないことが多いようです。ダウンロードが長引いている間に DFU が外れただけ、というケース。IPSW は ~/Library/iTunes/iPad Software Updates/ にキャッシュ済みなので、DFU に入れ直して再実行すれば、今度はダウンロードなしで即座に始まります。ここで諦めるのは早い。

データを残したい場合

今回はデータを捨てる前提で進めましたが、選択肢は他にもあります。

Apple Configurator 2 の「復活（Revive）」は、データ領域を触らずにファームウェアと OS だけ入れ直す機能です。うまくいけばデータが残る。ただしデータ領域や APFS コンテナ自体が壊れているなら直りません。

今回は「本体側で初期化しても直らなかった」時点でデータ領域側の破損が濃厚だったので、最初から完全復元を選びました。

ちなみに DFU モードは時間では解除されません。ケーブルを抜かずボタンも触らなければ維持されるので、DFU に入れてからゆっくり Configurator を入れて考える、という進め方もできます。リカバリーモードと違う、地味に便利な点です。

原因は、分からないままになった

正直に書いておくと、なぜ壊れたのかは、もう永久に分かりません。

ログ監視を仕掛けたのが復元の直前だったので、記録に残っているのは復元処理そのものだけ。端末側に残っていたはずのパニックログは、その復元で消えました。

原因究明を優先するなら、先に端末からログを吸い出すべきでした。直すことと原因を知ることは、両立しない場面があります。

一般論として、この症状で多いとされるのは iPadOS のアップデート中の中断です。電池切れ、強制再起動、電源断あたりで、システムボリュームが書きかけのまま確定してしまうパターン。アップデート時のストレージ不足も候補に挙がります。今回がどれだったかは判別できません。

はっきりしているのは、ハードウェアが正常だったことだけ。APFS コンテナの再フォーマットと 8.9GB の書き込みが最後まで通りました。ストレージや基板が劣化していれば、この規模の全面書き込みは途中で必ず落ちます。完走したこと自体が、ハードは無事だったという証明になっています。

おわりに

今回覚えて帰ることにしたのは、このへんです。

• 初期化しても直らないのは、故障の証明ではない。初期化を実行する当人が壊れている可能性がある
• USB で列挙されるなら、まだ望みがある。修理に出す前に system_profiler SPUSBDataType を一度叩く
• DFU は端末を説得する手段ではなく、黙らせて上書きする手段。本体側のソフトウェアを一切信用しないのが強い

Apple 製品のトラブルで記事を書くのは、これで2本目になりました。

Macbook Air の ファンが止まらない 問題の解決 | Lazy Developer

この記事では、Macbook Air の ファンが止まらない 問題の解決方法を記載します。 あくまで、私の環境で有効だっただけで、万人の問題が解決するわけではないと思いますがご了承ください。 前提 MacBook Air メモリ8GB Intel チップ macOS：13.3.1（更新しろというツッコミはなしで） 直面

lazy-developer.jp

文鎮化したと思っていた板が、ケーブル一本で普通の iPad に戻ったのは、素直に気持ちよかったです。ハンマーの出番はありませんでした。

もっとも、そのぶん原因の手がかりは全部消えたわけで。次に同じことが起きたら、今度は先にログを吸い出してから直します。たぶん、また忘れるんでしょうけど。