【macOS Sequoia】Kernel Panic！AppleAPFSMediaBSDClient/AppleAPFSVolumeBSDClientのエラー原因と対処法は？ | mac野郎なのか

macOS Sequoiaにアップグレードしたところ、kernel panicが発生するようになりました。

panic(cpu 0 caller 0xfffffe002c643de0): busy timeout[0], (60s): multiple entries holding the registry busy, IOKit termination queue depth 0: 'AppleAPFSMediaBSDClient' (1,1810001), 'AppleAPFSVolumeBSDClient' (1,1810001) @IOService.cpp:5811
Debugger message: panic
【macOS Sequoia】M2 MacBook Airで遭遇した不具合・問題と対策

原因は？macOS Sequoiaにアップグレードしたタイミングで、ディスクに異常が発生したと考えられます。

てっきり、macOS Sequoiaの不具合かと思っていました。

このkernel panic、AppleAPFSMediaBSDClientやAppleAPFSVolumeBSDClientでググると昔からあるkernel panicの一つということがわかりました。

ただ、具体的な解決方法はみつかりませんでした。
kernel panicのメッセージは特徴的なAppleAPFS[Media|Volume]BSDClientキーワードがありました。

AppleAPFS[Media|Volume]BSDClientのkernel panicはディスクがおかしい？

あくまでAPFSというキーワードからの推測です。APFSはAppleの最新ファイルシステムの名称で、Macintosh HDや外付けハードディスクもAPFS形式で利用しています。

ストレージの不調時は、First AIDですね！。ディスクユーテリティでFirst AIDを実行しました。

1. 通常起動中に、Macintosh HDのコンテナ、ボリュームに対してFirst AIDを行うと処理止まります。
   「起動ボリュームを検証すると、このコンピュータは応答を停止します。」と継続の意思を確認してくれます。
   

APPLE SSD AP0265Z Media→コンテナdisk3→Macintosh HD ボリューム下でFirst AIDできるボリュームは以下２つでした。

1. →Macintosh HD→APFS起動スナップショット（こちらは問題ありませんでした）
   
2. →Data（こちらは復旧できない問題を検知しました）

詳細に「UUIDが・・・のボリューム"/dev/rdisk3s5"が壊れています。修復する必要があります。」と表示されていることがわかります。

この修復する必要がありますメッセージは、ディスクユーティリティのFirst AIDでは修復できない問題という扱いです。修復できる期待ができる方法はスーパーユーザでfsckコマンド（filesystem consistency check and interactive repair）を実行することです。

M2 macをシャットダウン、電源長押しからオプションを起動

M1/M2/M3 Macは電源長押し→「オプション」から復旧システムを起動できます。
復旧システムでは

1. Time Machineから復旧
2. macOSの再インストール
3. Safari
4. ディスクユーティリティ
5. ユーティリティーメニュー→ターミナル

などの操作ができます。

ディスクユーティリティで再度チェックする

すでに一度はディスクユーティリティでFirst AIDを実行しています。先ほどは通常ログインモード、ここではシングルユーザーモードで確認できます。

ここでFirst AIDを実行することで修復できるかもと期待し、実行しました。

シングルユーザーモードでのディスクユーティリティはマウントのされ方が少し異なります。
「Data」ボリュームに対してFirst AIDを実行しました。

/dev/rdisk3s5で同様のUUIDで「corrupt and needs to be repaired.」でやっぱり修復が必要なことがわかりました

fsck -fyはサポートしてないって、mountされているボリュームはfsck対象外だってさ

ディスクユーティリティのメニューから終了し、ユーティリティメニューからターミナルを選んで、シングルユーザーモードのターミナルを開きます。

この手の情報は溢れているので、ググって見つけた情報を元にfsck -fyを実行します。

# fsck -fy
warinig: option -f is not implemented, ignoring
error : container /dev/rdisk5 is mounted. repairs in a mounted container is not supported yet.

1. warinig: option -f is not implemented, ignoring

   fsckに-fという引数指定は実装されてないとの警告です。

   復旧システムのfsckは対応していないのかもしれませんね。

2. error : container /dev/rdisk5 is mounted. repairs in a mounted container is not supported yet.

   fsckは-fオプション指定を無視し、継続して処理を行っています。
   修復は、mountされたディスクでは利用できないとエラーで終了しています。

unmountしてfsck -y /dev/disk3s5でappears to be OK.にできました、不安あり

関連しそうな対処方法を見つけました。
superuser:Running fsck -fy on my mac throws a container write access error.How do i get around this?

1. 【修復が必要なディスクのマウントを解除する】
   • 暗号化されたVolumeが存在しない場合：diskutil umountDisk /dev/disk数字
     
   • 暗号化されたVolume: diskutil apfs unlockVolume /dev/disk数字s数字 -nomount
   
   
2. 【修復する】fsck_apfs -y /dev/disk数字s数字

fsckはumountしたデバイスにも使えるの？

使えました。
マウント解除して大丈夫でした。

「ボリューム"/dev/rdisk3s5"が壊れています」のumountは/dev/disk3

First AIDの結果、「ボリューム"/dev/rdisk3s5"が壊れています。修復する必要があります。」と指摘がありました。

以下を実行しました。
diskutil umountDisk /dev/disk3

diskではなく、rdiskとなっています。どちらも同じデバイスを表しています。修復時にはdiskを利用します。

通常1つのディスク、ボリュームに対して/dev/diskと/dev/rdiskのデバイスが作られます。diskはランダムアクセスデバイス、rdiskはrow diskという意味でシーケンシャルアクセスデバイスです。

fsck -fyではなくfsck_apfs -y

fsckはファイルシステム毎にコマンドが存在します。
fsckは適切なファイルシステムを把握して、ファイルシステムに対応したfsck_*を実行しているんでしょうね。

今回修復する必要があるボリューム"/dev/rdisk3s5"は、APFSです。そのためfsck_apfsを利用します。
デバイスはランダムアクセスデバイスの/dev/disk3s5を指定しました。

fsck_apfs -y /dev/disk3s5

しばらく待つとappears to be OK.でfsck_apfs -yが完了しました。

** The volume /dev/rdisk3s5 with UUID 84793F5-0910-4CF7-88D1-BEEF15253B0 was found to be corrupt and needs to be repaired.
** Verifying allocated space.
** Performing deferred repairs.
** The volume /dev/rdisk3s5 with UUID 847E93F5-0910-4CF7-88D1-B3EEF15253B0 appears to be OK.
-bash-3.2#

/dev/rdisk3s5はappears to be OK（大丈夫なようです）となりました。
修復できた感じですね

心配なので再度afps_fsck -yを実行、不安

再度実行しても、found to be corrupt and needs to be repaired.、appears to be OK.となりました。

** The volume /dev/rdisk3s5 with UUID 84793F5-0910-4CF7-88D1-BEEF15253B0 was found to be corrupt and needs to be repaired.
** Verifying allocated space.
** Performing deferred repairs.
** The volume /dev/rdisk3s5 with UUID 847E93F5-0910-4CF7-88D1-B3EEF15253B0 appears to be OK.
-bash-3.2#

２度目の実行ではfound to be corrupt and needs to be repairedメッセージは出力されないと思っていました。

これほんとに直っているんでしょうか・・・不安です。

目的としていたfsckでリペアすることはできたので、ひとまず様子見してみます。
[2024-10-19 16時頃 fsckでリペアを実行しています]

効果はあったのか？一定の効果を感じました

修復する前は、2,3日に1回はAppleAPFSMediaBSDClient' (1,1810001), 'AppleAPFSVolumeBSDClient' (1,1810001)に起因するkernel panicが発生し、強制再起動でした。

2024年10月19日16時ごろにfsckによる修復を実施。
その後kernel panicの発生はありませんでした。これは直ったかもと期待しました。
2024年10月27日 9時ごろ、AppleAPFSMediaBSDClient' (1,1810001), 'AppleAPFSVolumeBSDClient' (1,1810001)に起因するkernel panicが発生しました。

以前よりkernel panicの間隔が長くなりました。fsckによる修復は一定の効果があると思われます。ただ完璧な処方箋ではないようです。

まとめ

macOS Sequoiaへのアップデート後に発生したAppleAPFSMediaBSDClientやAppleAPFSVolumeBSDClientに関連するkernel panicは、ディスクのエラーが原因である可能性が高いです。

特にAPFSフォーマットのディスクが影響を受けやすく、ディスクユーティリティのFirst AIDやfsckコマンドを用いた修復が推奨されます。しかし、fsckの使用時にはマウントの解除が必要なことがあり、慎重な操作が求められます。

一度修復が完了したとしても、再度問題が発生する可能性があるため、バックアップを忘れずに行い、様子を見ながらシステムの安定性を確認することが重要です。