2019款16英寸MacBook Pro可用Monterey，但T2固件更新崩溃回退，如何进一步诊断？

Question

级别 1

4 积分

2019款16英寸MacBook Pro可用Monterey，但T2固件更新崩溃回退，如何进一步诊断？

设备：2019款16英寸MacBook Pro A2141，MacBookPro16,1 / J152FAP / iBridge2,14。当前可正常进入Monterey 12.7.6（21H1320），T2为23P6068。

这台机器曾成功从Catalina升级到Monterey，并非所有系统升级都不能完成。但两端采样T2均为23P6068，不能据此证明T2固件版本转换成功。

最近两次不同入口（安装U盘启动支持更新、未插U盘的互联网恢复安装）都尝试把T2从23P6068更新为24P6005，随后崩溃并回退。日志记录ota-result=crash、MobileSoftwareUpdateErrorDomain 1105、Preserved reason 11、BridgeOSSoftwareUpdateError 21，以及Previous bridgeOS update failed backward。第一次完整BridgeRestore报告还包含otaChildFailures={initial:SIGNAL(11)[REBOOT]}；第二次保存的Recovery日志没有这一信号详情，不能假定内部完全相同。

第二次Recovery日志说收集了119494字节bridgeOS诊断数据，但这部分载荷不在保存的install.log内。已用管理员权限补采限定诊断目录，仍未找到第二次对应的新报告，因此目前没有实际崩溃进程或堆栈。

此前DFU曾有一次Erase和一次Update尝试，均在update_NAND_firmware阶段出现nvmefwupdater --query退出2（060E.0006）；另一次指定旧固件的Update被TSS以94/3194拒绝。以上与最近更新崩溃是不同错误，未继续重复。

已检查：Apple诊断ADP000，APFS验证通过，SMART显示已验证；锁定8GiB内存完成一轮18项测试通过。这些不能排除全部硬件问题，也不覆盖T2自身内存。安装U盘已做文件读回哈希、镜像及工具签名验证。尚没有主板内部腐蚀检查结论。

还有一个需保留的反例：Tahoe 26.6（25G72）一次准备日志显示No bridgeOS update needed，最终也回到了Monterey。因此不能认定T2是全部升级失败的唯一原因。最近准备的完整安装器为26.7.1（25G241）。

想请教：

1. 不再次刷写的前提下，怎样定位T2实际崩溃进程，区分更新程序问题与存储、内存或供电异常？

2. 返回macOS后，有没有官方方法取回Recovery已收集的bridgeOS载荷？系统sysdiagnose是否包含这部分诊断？

3. 是否有相同错误组合且确认修复的案例，或应向Apple支持提供哪类报告进行进一步诊断？

希望避免无变量重复安装/DFU、盲目抹盘或关闭安全保护。本文只含脱敏日志摘要。

MacBook Pro 16″, macOS 12.7

发布日期 2026年10月24日下午10:48

Answer 1

senrong 作者

级别 1

4 积分

2026年10月24日下午11:03 回应 senrong

补充新证据：已完成完整sysdiagnose，约298MiB，传回SHA256一致、gzip完整性校验通过。其中包含约6.98MB的T2自身bridge_sysdiagnose子包，统一日志已成功解码。原始包没有公开上传。

这次T2日志独立确认：21:51互联网恢复更新同样记录otaChildFailures={initial:SIGNAL(11)[REBOOT]}。lastApplyTime对应北京时间21:51:27，updateFinished对应21:51:59；targetOSVersion=24P6005，original/currentOSVersion=23P6068，result=crash，otaOutcome=back_to_original_os。此前只有20:48那次有这个字段，现在第二次也有直接证据。

但仍未识别到崩溃的具体进程、故障地址或调用堆栈。回退后的CleanupPreparePathService两次记录：_migrate_ramdisk_logs: No ramdisk created CrashReporter dir found。主机代理目录和T2子包均未找到对应panic报告。新出现的stacks报告是在22:54执行sysdiagnose时生成，不是21:51失败现场。

因此不能把initial当作已识别的可执行文件名，也不能单凭SIGNAL(11)判断RAM/NAND/SEP损坏。工具总体退出0，但部分采集子任务有缺工具/权限错误，不能保证所有报告均被收集。Recovery所称119494字节载荷仍未作为独立原件找回。

请问这个initial子阶段通常对应哪个更新组件？是否存在无需再次刷写、无需关闭安全保护的官方取证方式，可以定位该子进程并取得异常堆栈？

Answer 2

senrong 作者

级别 1

4 积分

2026年10月24日下午11:14 回应 senrong

继续离线分析现有诊断包，有以下新发现（没有再次刷写）：

119494字节载荷已定位为FetchBridgeOSLogs接口的FullLogString响应，不能预设为异常堆栈。13:52:59 UTC请求指定LogStartDate=13:51:19 UTC、MaxLogSizeKB=256；13:53:01响应声明length=119494，其可见开头是回退后softwareupdated在常规环境启动和清理。

两个记录副本都截断了。用JSON格式重新读取logarchive，每条eventMessage仅1020个UTF-8字节，末尾均有<…>；不是终端宽度问题，仍未取回完整正文。

13:51:59.372 UTC清理服务找不到ramdisk生成的CrashReporter目录；13:51:59.400记录删除/private/var/MobileSoftwareUpdate//ramdisk。这是当时系统自动清理，不是本轮操作。ota-initial-result、ota-initial-failure-reason、ota-initial-breadcrumbs在清理时均显示不存在，仍没有initial到具体可执行文件/PID的映射。

宿主的UpdateBrainService/softwareupdated .diag是较早的disk writes资源统计，并非这次T2异常堆栈。另有一条历史事件同样收集119494字节，但内部更新日期不同，不能仅凭字节数将其归为本次。

想进一步请教：能否在不再次更新、不关闭SIP或启动保护的前提下，通过官方只读取证工具重新取回已失败更新的完整FetchBridgeOSLogs响应，或从现有固件/更新元数据确认initial子阶段对应的进程？若只能由Apple支持进一步解析，应该提供哪项现有材料？原始诊断包未公开上传。