可是逐步地，CPU 的短板还是被逐渐感知到了。更何况近些时来，大家热热闹闹地玩 AI，这个家伙不管是对 CPU 还是内存/GPU，都不会特别迁就。所以故技重施，先把办公室的干活儿主力机升了升格，从 Latitude 5401 升级到 Latitude 5431，再把退下来的 Latitude 5401 搬回家里来用（因为它也可以支持三硬盘）。不过比较讨厌的是，它已经不支持 BIOS/MBR 引导了，而且虽然没有实测，可直觉上其 m.2 插槽也不会支持 SATA 协议的 SSD 了。这就是说，现有的 T450s 上的三个系统，每一个都得换盘，不仅如此，还要视情况进行针对性的外科手术式迁移适配。

最先，也最顺利的是 Windows 10，毕竟咱有积累的经验打底。Ubuntu 的使用频度目前在家里不算高，因此暂时搁置。比较不好搞的是那份黑苹果。从以往的历篇博文也可以看出，在 T450s 上表现完美的Monterey 时至今日也已略显过时，而升级到 Sequoia 之后，本身在 T450s 上还算不得完美。历尽艰难，才把升级后遇到的无法登录的问题解决掉，而进入桌面后，陆续又发现一些使用上的毛刺。一是触控板驱动的不太对头，想触发点击操作，需要在触控板上连点两次；二是显示屏的亮度无法调节，这个情况应该是和显卡有关，理由是当我把这款盘从双显卡的 T450s 上平移到另一台只有核显的 T450s 上之后，调节亮度的控件就会正常出现；第三个问题也比较古怪，那就是如果把外置电池接上的话，系统引导的时候会卡死。基于这些，心想正好把黑苹果也干脆迁到 Latitude 5401 上就好了。

找了一块闲置的 m.2 的 SSD，用 DiskGenius 的磁盘克隆功能成功把原来 NGFF SSD 上的内容克隆了过来。需要说明的是，这份黑苹果目前面临着两个问题：1. 如何在 Latitude 5401 上才能引导起来；2. 它自身的状态与 Latitude 5401 是否能兼容。第一个问题的解决方法很标准，那就是在网络上找是否有现成的 EFI 被人分享了出来，幸运的很，确实有，在这里。不过在看作者的文档时，发现了一个之前少有的要求：需要使用技术手段微调这台本子的固件界面里不曾体现的选项。途径则是在 OpenCore 引导时，按空格键调出额外的引导项，进入到 OpenShell 控制台，按需执行 setup_var.efi 命令。要调整项的偏移和值文档中有现成的，但作者又提醒说，各人应该自行确认一下，以免失误导致设备变砖。于是三太爷不得不阅读 setup_var.efi 的文档，按步骤操作。首先去下载了 Intel 的 CSME System Tools 工具集中的 Flash Programming Tool（FPTW64.exe），执行 FPTW64.exe -bios -d bios-dump.bin 把设备当前的 BIOS 转储，然后使用 UEFITool 把所需的 Setup/* 节抽取出来，再用 IFRExtractor RS 把配置信息转为文本格式。最后打开转换后的文本文件，一一核对提及的需要修改的配置项的偏移，顺便把当前值记录下来，以便将来可能需要恢复回去。还好，所有的偏移均与 EFI 的作者列出的一致。

作为一个好奇宝宝，显然在修改之前必须尝试一次引导，以观察不修改的话会有什么后果。后果其实很直接：不能引导成功，会重启。老老实实修改后，引导进入到了 macOS 的安装器界面。令人痛苦的是，界面的文字非中非英，一眼看去像是俄文。为了后续的步骤可以看明白，总得把这个界面显示问题解决掉。问了 AI 若干次，也按照它的回复对 OpenCore 的 config.plist 调整了若干次，统统无效（例如在 boot-args 里加上 -apple-language en_US，并指定 SystemLanguage 等）。最后没辙儿了，拿出手机打开 Google 翻译，照着屏幕一看，翻译 app 判定显示语言为匈牙利语。靠着它，才发现第二菜单下的唯一下拉菜单项其实就是语言切换的入口，这样一来，引导问题算是基本搞定。

接下来就要尝试用这份 EFI 引导一下前面克隆完成的 SSD 上的 macOS Sequoia 了。把 SSD 插入插槽，用带着定制了的 EFI 的 macOS 安装引导 U 盘启动，结果是令人意想不到的失望，一而再再而三地重启，根本不能像之前那样进入到安装界面。后来不禁想，不会是 U 盘自己输了什么问题了吧，决定验证下。把 SSD 取下，用最简单的环境来测试，结果这次好了，又能进入安装界面（也是 macOS 的恢复界面）了。这下恍然大悟，看来是 SSD 在作祟。赶忙到搜索引擎里查询，果然有人早就警示：若干多的 SSD 与黑苹果相克，而老夫所用的海力士 BC711 赫然在列。好像说西部数据的好一些。

于是到闲鱼上查访，发现 SSD 这半年涨价的实在离谱，西数的 SN520，512GB 的竟然要 350 元上下（这还不算更离谱的标价）。要知道去年十月份，1TB 的 SSD 也就这个价。唉，黑苹果的迁移大业，先停停吧。

为了叙述方便，我把一开始升级成功时采用的 EFI 称为第一版本，简称 E1，后面找到的、测试离线新建用户成功的 EFI 称为第二版本，即 E2。当然，前文里其实也已经透露出，最后发现无论是 E1 还是 E2，都不能使得升级前已经存在的用户登录进入桌面，而离线新建的用户无论是用 E1 引导还是 E2 引导，也都能进入桌面。

区别在于，E1 的相关资料、讨论中，均未有进一步处理图形性能的内容，而 E2 的说明里则非常清晰地包括了此部分的内容。简而言之，其核心症结以及相应的处理手法如下：

• 为了能够顺利安装 macOS Sequoia，需要在 OpenCore 的 config.plist 中将 T450s 伪装为一台 MacBookPro16,3 设备；
• 安装成功后，图形处理方面是不完善的；此不完善之处，需要借用 OpenCore Legacy Patcher（也即 OCLP）来进行完善；
• 而由于 OCLP 运行时，是自动检测当前设备以进行修补，那么就不能让它把 T450s 识别为伪装的 MacBookPro16,3 设备，而要设别为真正与 T450s 匹配（接近）的 MacBookPro12,1，否则修补就会错位；
• 上述矛盾，需要借用 macOS Sequoia 的 USB 安装盘来解决：把安装盘上 EFI 里的伪装设备从 MacBookPro16,3 改为 MacBookPro12,1，并使用它把安装好的 macOS Sequoia 引导起来，这时执行 OCLP；
• 执行完毕后，把安装盘的 EFI 同步到硬盘上的 EPS 分区里，应该就告功成了；

再按照上述理解进行操作后，macOS 从硬盘引导起来就完全正常了，而且之前不能登录的那个用户自动就复活了。不过在过程中，也遇到了两个问题，记录于下。

第一就是出于已经形成的认知，认为 E1 和 E2 版本的 EFI 尽管不一样，但其功效应该无甚差别，因此在 USB 安装盘的 EFI 是 E1 的情况下，按照对 E2 文档的理解，直接把伪装设备的型号（以及序列号等）从 MacBookPro16,3 改为 MacBookPro12,1，但这样改后用 E1 引导硬盘上的 macOS 会失败。把 USB 安装盘上的 EFI 从 E1 替换为 E2 并设置型号等信息后，再次引导硬盘上的 macOS 则成功了。

第二是在引导成功后，执行 OCLP 时发生了错误，报 Unable to resolve dependencies: 'com.rim.driver.BlackBerryUSBDriverInt' names a dependency on 'com.apple.iokit.IOUSBMassStorageClass', which was not found.。在网络上搜索到此处，根据一名为 Rochmind 的回答，到 /Library/Extensions 下，把两个以 RIMBB 开头的内核扩展模块移走了，再尝试 Post-Install Patch 就顺利成功了。

为了解决登录不进桌面的问题，着实思索过不少可能的原因以及验证或者解决的路子，可惜得很，都没有奏效。从体感上，既然已经成功启动到了登录界面，EFI 其实是应该没什么问题的，但询问 AI 后，AI 的回答又让人不敢完全确定。AI 是这么说的，在登录界面时可能系统使用的是较为基础的显卡驱动程序，而当进入到用户桌面时，它会尝试加载可能更加匹配的高性能的显卡驱动，对应于本案例，则正好是发生卡死的时机。你看，这说法也相当成立。

昨晚又想尝试一次，是因为发现了另一个人在 GitHub 上公开新的 EFI。这个人看上去是个新手，写的说明文档是从制作安装盘开始的，但三太爷作为一个普通用户，在之前使用的 EFI 仓库 issue 帖下发表请教而无人问津长达数月，把新出现的 EFI 当作稻草救救命也应该无可厚非。过程相对顺利，结果如出一辙。问题还是那个问题，输入用户名和密码，有错误还则罢了，有视觉动效略作提醒，停留在本界面等待重试，而如若没有错误，则等候动画旋转不止，就此无限下去。

这次，三太爷感觉应该和 EFI 关联性不大了，毕竟这个新的 EFI 看上去和先前的 EFI 相关性极小，并非肉眼可见的衍生物。如果是这样的话，那么问题可能出在要登录的那个用户的软件环境上。要想验证这个想法，可行的方法有一个：为这个无法登录当前唯一用户的系统新建一个用户。经过查阅资料，发现大部分都要在恢复模式下进行操作，而这个黑苹果，如何进入恢复模式本身就是个讨厌差事。再度进行探求，发现了 dscl 命令的进阶用法，原来它是可以针对一份本机当前系统之外的系统进行操作的。

这个命令的相关信息不算多，如果你在打 AI 的主意的话，三太爷特别提醒，要非常小心，它的知识库很可能不足够准确，尤其是对各个参数的形式要求。历经在命令行下的种种组合尝试，三太爷终于在 MacBook Pro 2015 无头骑士上，把 ThinkPad T450s 所用的黑苹果的系统盘用 USB 外接起来，成功创建了一个新的管理员账户。

为了让可能的同路人少走弯路，此处将添加新用户的脚本给出。Monterey 是目标系统所在的宗卷，最后一行的 merge 是将新建用户指定为管理员。执行时会提示为新建用户输入密码，别不赘述。

[crayon-69e0587248633678039492 inline="true" ]export TARGET="/Volumes/Monterey"
export USERNAME="oldman"
export USERID="1976"

sudo dscl -f "$TARGET/var/db/dslocal/nodes/Default" localonly create ./Local/Default/Users/$USERNAME
sudo dscl -f "$TARGET/var/db/dslocal/nodes/Default" localonly create ./Local/Default/Users/$USERNAME UserShell /bin/zsh
sudo dscl -f "$TARGET/var/db/dslocal/nodes/Default" localonly create ./Local/Default/Users/$USERNAME RealName "Oldman"
sudo dscl -f "$TARGET/var/db/dslocal/nodes/Default" localonly create ./Local/Default/Users/$USERNAME UniqueID "$USERID"
sudo dscl -f "$TARGET/var/db/dslocal/nodes/Default" localonly create ./Local/Default/Users/$USERNAME PrimaryGroupID 20
sudo dscl -f "$TARGET/var/db/dslocal/nodes/Default" localonly create ./Local/Default/Users/$USERNAME NFSHomeDirectory /Users/$USERNAME
sudo dscl -f "$TARGET/var/db/dslocal/nodes/Default" localonly passwd ./Local/Default/Users/$USERNAME
sudo dscl -f "$TARGET/var/db/dslocal/nodes/Default" localonly merge ./Local/Default/Groups/admin GroupMembership $USERNAME

把黑苹果从 USB 上断开，放回到 T450s 重启，登录界面如愿出现了新创建的用户，并且在输入密码后成功登录。在界面里执行操作感觉很卡，不过这次老夫倾向于是 EFI 的锅了，因为这份新的 EFI 的安装指令中本就要求系统安装完成后还要使用 OpenCore Legacy Patcher 做一些善后事宜。但老夫的直觉想法是换回之前用的那份 EFI，:)。

附录。AI 其实还提出过一个思路，它说如果你把一份 macOS 系统中存放于 /var/db 下的 .AppleSetupDone 文件删除的话，重启系统会引发新装系统后的设置助理执行起来。然而事实是老夫多次尝试，并没有任何效果，且该文件会被重新创建出来（macOS Sequoia）。

出于各种各样的需要，有时候用户可能想选择性下载某个机型的 BootCamp 驱动合集，而不必非要借助于已经安装成功的 Windows 系统中被苹果植入 BootCamp 工具，于是催发了一些第三方工具的诞生。

有个图形化工具叫 Bombardier 的，可以用来执行这一任务。它会列出可供下载的机型列表，由用户选择后进行下载。它正常发挥了 GUI 程序的优点：直观且操作简单。这是一个开源项目，使用 Swift 语言写就，其官方地址在：https://github.com/ninxsoft/Bombardier。当你打开这个地址后，你会发现该项目已经归档，这通常意味着原作者不会再对它进行后续的维护和更新了。

另外还有一个工具叫 Brigadier，官方地址位于 https://github.com/timsutton/brigadier。它与前述的 Bombardier 功能类似，不过它是脚本工具，用 Python 写就，对命令行选手更加适合一些。令人略微惊讶的是，它比 Bombardier 出现得更早，但最后更新的时间更晚一些。

如果真要遇到这样的需求，GUI 模式的 Bombardier 应该还是首先尝试的选项，实在有问题的话，不妨再试 Brigadier。

回复一。找一台新版本的苹果电脑，打开钥匙串访问，选择“系统根”，将其导出为名为 rootcerts.pem 的文件，复制到古董机上。将以下脚本保存为名为trustroot 的文件，赋予其执行权限后，用 sudo 命令执行它，如 sudo ./trustroot rootcerts.pem。

#!/bin/bash
DIR=${TMPDIR}/trustroot.$$
mkdir -p ${DIR}
trap "rm -rf ${DIR}" EXIT
cat "$1" | (cd $DIR && /usr/bin/split -p '-----BEGIN CERTIFICATE-----' - cert- )
for c in ${DIR}/cert-* ; do
   security -v add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" "$c"
done
rm -rf ${DIR}

脚本所做的是将 .pem 文件拆分为临时目录中的多个证书，然后将它们作为 trustRoot 证书添加到系统钥匙链中；然后，它们将作为除原始“系统根”钥匙链中的证书之外的受信任根运行。要知道，你并不能将它们添加到 System Roots 钥匙链中，因为它只能由操作系统更新。注意，只有第一组证书（提问中的“受信任证书”）会被复制，第二组证书和第三组证书则不会。出于安全考虑，作者不会提供一组现成的证书供大家下载使用，以免夹带私货。

回复二。在 2009 年初带有 El Capitan （10.11.6） 的旧 iMac 上尝试了以下操作，一切都按预期工作。

• 从 http://x1.i.lencr.org/ 下载 ISRG 根 X1 证书文件；
• 打开“钥匙串访问”应用，然后将该文件拖到该应用的“系统”文件夹中；
• 在系统中找到 ISRG 根 X1 证书并双击它，打开“信任”菜单并将“使用系统默认值”更改为“始终信任”，然后关闭该证书并输入密码以确认更改（如果出现提示）。

回复三。给出的答案对控制台应用程序都没有帮助。我相信大多数需求都是基于 curl 的，可以做如下操作。

• 备份 /etc/ssl/cert.pem 文件；
• 用编辑器打开 /etc/ssl/cert.pem；
• 搜索 DST Root CA X3。如果发现此（已过期的）根证书 —— 它就是问题的根源；
• 删除此证书所有的 42 行。始于 ### Digital Signature Trust Co. 终于 -----END CERTIFICATE-----；
• 再使用 curl --cert-status https://example.com 命令检查是否正常。

此方法因何有帮助：由兼容性考虑，LE 证书有两条路可抵达根证书。出于某种原因（兼容性？），带有“DST 根 CA X3”证书的验证路径是首选路径。而且，据我了解，curl 更喜欢自己的根证书集（而不是系统证书），这些证书位于 /etc/ssl/cert.pem。因此，删除过时的根证书会强制 curl 使用“ISRG Root X1”（当然，如果它已存在）。不过，如果你在一个非常旧的系统上执行此操作，则可能需要再执行一个步骤 —— 将此根证书添加到此文件（译者注：此处未完全理解）。只是要小心，应从可信赖的来源获取它。

于是寻找预编译好的高版本的 curl。到其官网上看，最新版本是 8.7.1，它列出了两条路子，一个是下载 Travis Lee 的项目里的包，链接 https://guthub.com/stunnel/static-curl/releases/download/8.7.1/curl-macos-x86_64-8.7.1.tar.xz。另一个是到 conda-forge.org 网站去。后者看的比较蒙，没接触过，于是先搞下来了前者，痛苦的事情来了，tar x 命令解不开，显然，这个系统不支持 xz 命令。首先想到的是 7z，也去看了一眼，看完苦笑，它的命令行版本在 macOS 平台下也是 xz 格式的 tar 包。

如此一来，只好找到 xz 的源码，特意选了非 xz 格式的源码包。下载后解压，按惯例执行 ./configure，最后报错，说没有找到 C 编译器。打开 Xcode（5.1.1 新装的版本，从官网下载的），从 Preferences 的 Downloads 里下载，发现空空如也，看来苹果的服务端已经放弃支持。又到命令行下执行 xcode-select --install 碰运气，报 --install 不认识。最后还是再次登录开发者账户后下载到的 Command Line Tools（期间还经历了要解锁因不明安全原因锁定了的账户）。安装之后，xz 配置、构建、安装一气呵成。

这下就可以把 curl 从 xz 里释放出来了。第一时间执行 curl --help 成功，满心欢喜地将之把系统自带的 /usr/bin 下的原始档给替换掉了。再次执行 iOSOpenDev 的 .pkg 安装包，再次失败。再次查看日志，发现这个新版本的 curl 运行竟然报错！错误信息是 _clock_gettime 这个符号找不到。搜到 curl 官方项目中的一个 issue，正是此事，但可惜没有看到可靠的解决方案。

其实吧，变通方案心里一直是有的。那就是老夫自己写个名为 curl 的脚本临时替掉系统内的 curl，把已经在其他地方下载好的文件直接放到期望的目录中，一次性即可完成此工作。再探探正路，不行就这个办法了。

更新（2024-04-24）：已经使用变通方案搞定。

另，存一个开发介绍贴：iOS越狱开发指南 – 简书 (jianshu.com)。

下载 OS X 10.8 的安装映像也是需要寻找的，官方有个页面，Mac OS X Mountain Lion Installer – Apple Support，里面号称提供安装器，但这个需要在现有版本的 OS X 上升级，而不是一个支持引导 USB 的映像。最后是在 archive.org 上找到可引导的映像才搞定烧录 U 盘的，直链是 https://archive.org/download/os-x-mountain-lion-bootable-image/OS%20X%20Mountain%20Lion%20Bootable%20Image.dmg。

接下来要下载 Xcode 5.1.1 的安装包。找到个页面里列出了直链 http://adcdownload.apple.com/Developer_Tools/xcode_5.1.1/xcode_5.1.1.dmg，但是直接访问会报未授权的错误，登录苹果的开发者账户后，再次访问仍然报错。后来在 https://developer.apple.com/download/all/ 页面里不停地点击 View More 向下滚动，就能找到正确的下载入口，可以看到真正的直链是 https://download.developer.apple.com/Developer_Tools/xcode_5.1.1/Xcode_5.1.1.dmg。

到现如今，开发上架到 AppStore 的供 iOS 5 使用的 app 那就是天方夜谭了，所以趁早转向更加“开放”的方向。多年前就知道 iOSOpenDev 的存在，没想到一直还在。它的下载页面是 iOSOpenDev—Download，在列表里面找一个合适的下载安装就行。它在 GitHub 上的项目地址是 GitHub – kokoabim/iOSOpenDev: iOSOpenDev，Wiki 页面在 https://github.com/kokoabim/iOSOpenDev/wiki/。

这个东西的成熟度出乎意料。它可以自动把官方最近几个版本的 macOS 系统安装包列出，任君选择，然后帮你下载后放到 Applications 文件夹中（也可以把链接复制出来）。下载完成后，它还可以帮你制作并校验安装 U 盘，然后再把 OpenCore 装到 U 盘上，以供重启后从 U 盘开始安装。黑苹果里装的是 Ventura，这个半黑苹果可以激进一些，老夫选择了最新的 Sonoma。虽然网上有人说最好是新装，但老夫头铁（出于对苹果的残存信任），直接覆盖安装。整个安装过程仅第一次从 U 盘引导时需要开机按 Option 键干预选择，后续一直是自动完成的，多次重启后可以直接正常登录。中间有一次重启后，进度条刚刚前进一点即停滞了许久，一度以为出问题了，就在要出手强行重启时，它自己又恢复其既定进程（尬，也是重启）了。升级完成的第一次登录后，OpenCore Legacy Patcher 甚至会自动询问要不要把 OpenCore 安装到硬盘里以免后续每次都需要 U 盘引导。

升级后首先发现的就是，Xcode 被系统标志为不可使用，强制需要到 AppStore 中更新为更高的版本。更新后用它打开旧工程，没有发现特别的问题。

就此告一段落，又能战两年。

也许有朋友对最后这个问题还有印象，因为在前几天换主板之前去戴尔维修点换连带着键盘和触控板的整个 C 面就是这个问题。现在很可能老夫找到了问题的根源：硬件响应异常是由于黑苹果导致的。说不定就是黑苹果自带的某些驱动/固件的问题，有待观察。
​
​不过即使 Latitude 5400 再次抱恙，老夫也已有了 Plan B，有个叫 OpenCore Legacy Patcher 的项目，可以让老 MacBook 电脑安装官方不允许升级到的新版本的系统。

一开始以为这是个很简单的事，毕竟咱“有无线网在”，只可惜，把两台电脑都接入到同一个 WiFi 下，各自都把迁移助理打开，目的机都已经能检测到来源机了，可是只要尝试连接，就会报“无法连接”，跟着是一句长长的废话，也就是检查网络啊，防火墙啊啥的，其实两台电脑的防火墙都关着呢。

接着想到数据线直连好像是可以的，可是 MacBook Pro 2015 太老，它只有 Mini DP 口，好像就是后来一度也叫雷雳口的那个，当然是在没有跟 USB Type-C 同化之前。Latitude 5400 倒是有个 USB Type-C 的接口，可是也不知道那玩意儿到底支持什么协议，退一步说，即便支持，手里也没有现成的两头是 Mini DP 和 USB Type-C 的公对公的连接线啊。一度还想，不会还得找个移动硬盘用 Time Machine 中转吧？大几百 GB 的数据来回折腾两回，听上去就有点傻。

无奈之下开始摸鱼，把郭杰森演的《养蜂人》收了个尾，看完了。然后就突然想到，哎？应该可以双绞线直连吧？查了一下，似乎是可以的。看了一眼 MacBook Pro 2015，又特么给我出难题，已经没有 RJ45 口了，不过转眼就看到了一个老兄弟送我的 USB hub，竟然在上面有个网线口。这下可以了，Latitude 5400 自带有线网口，MacBook Pro 使用这个 USB 转接出来的有线网口，拿了一根双绞线连起来，开搞。

迁移助理智能得有点过头，仍然坚持自动打开无线网络并使用，两台机器都是，只好反复先关闭无线网络开关，再运行迁移助理。迁移助理的运行，应该是使用了一个系统内置的特殊账户，而且它要把当前所有登录了的用户登出。Ventura 的迁移助理是接收方的角色，在运行时会显示当前使用的无线网络名称，而且还可以切换无线网络，但是没有切换到以太网的支持。Monterey 的迁移助理是发送方的角色，界面上并不显示当前网络，只能看系统顶部状态栏上的无线网络的指示图标。无论哪一种，发现使用的是无线网，就得关闭迁移助理，重新登入正常帐户，关闭无线网络，再次执行迁移助理，如此反复。而且 Monterey 的迁移助理还会出现一种奇怪的情况，就是将用户登出退出到锁定界面后，它自己消失了。在这种状态下，能看到有一个叫“Setup User”的用户，跟其他本机用户一同显示在屏幕上。

就这么跟迁移助理斗智斗勇了若干个回合，总算进入双方显示安全验证码的环节了，再往后就正常开始即使、传输了。预估时间，最开始显示 30 多个小时，一会儿降到 20 多个小时，有一会儿变成了 3 个多小时，大概靠谱了，希望中间别出娄子。一般来说，如果过后老夫没来再次更新本文，那就应该是没出问题，:）

对了，还发现个问题。这份黑苹果如果从迁移助理退出，再次登录进入系统，则触控板会失灵。幸好老夫这台 Latitude 5400 是同时带了指点杆的，仍可操作，否则就只能外接鼠标了。