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を実行しました。
- 通常起動中に、Macintosh HDのコンテナ、ボリュームに対してFirst AIDを行うと処理止まります。
「起動ボリュームを検証すると、このコンピュータは応答を停止します。」と継続の意思を確認してくれます。
APPLE SSD AP0265Z Media→コンテナdisk3→Macintosh HD ボリューム下でFirst AIDできるボリュームは以下２つでした。
- →Macintosh HD→APFS起動スナップショット（こちらは問題ありませんでした）
- →Data（こちらは復旧できない問題を検知しました）
詳細に「UUIDが・・・のボリューム”/dev/rdisk3s5″が壊れています。修復する必要があります。」と表示されていることがわかります。
この修復する必要がありますメッセージは、ディスクユーティリティのFirst AIDでは修復できない問題という扱いです。修復できる期待ができる方法はスーパーユーザでfsckコマンド（filesystem consistency check and interactive repair）を実行することです。
M2 macをシャットダウン、電源長押しからオプションを起動
M1/M2/M3 Macは電源長押し→「オプション」から復旧システムを起動できます。
復旧システムでは
- Time Machineから復旧
- macOSの再インストール
- Safari
- ディスクユーティリティ
- ユーティリティーメニュー→ターミナル
などの操作ができます。
ディスクユーティリティで再度チェックする
すでに一度はディスクユーティリティで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.
- warinig: option -f is not implemented, ignoring
fsckに-fという引数指定は実装されてないとの警告です。
復旧システムのfsckは対応していないのかもしれませんね。
- 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?
- 【修復が必要なディスクのマウントを解除する】
- 暗号化されたVolumeが存在しない場合：diskutil umountDisk /dev/disk数字
- 暗号化されたVolume: diskutil apfs unlockVolume /dev/disk数字s数字 -nomount
- 【修復する】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の使用時にはマウントの解除が必要なことがあり、慎重な操作が求められます。
一度修復が完了したとしても、再度問題が発生する可能性があるため、バックアップを忘れずに行い、様子を見ながらシステムの安定性を確認することが重要です。
