可是逐步地，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-69e05597eedb8311554728 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）。

首先当然是准备安装盘，之前给 MacBook Pro 升级时做过一个 macOS Sequoia 的安装盘，心想就别重新再做了，把 EFI 分区里的引导相关文件从适用于旧版本 MacBook Pro 的，换成适用于 T450s 的就好。

由于不知道继续沿用现在的 Monterey 所使用的各硬件 ID 是否可以，初步决定还是用 GenSMBIOS 重新生成一套得了。

把这些信息写到 OpenCore 的 config.list 里之后，用这一安装盘对 Monterey 进行升级。整个过程非常顺利，几次重启过后，看到了 Sequoia 的登录界面。

于是意外就来了：输入密码后，持续转圈，但就是无法进入桌面，也无法执行其它的任何操作。根据在网上检索到的各种信息，尝试，

• 又覆盖安装了一次，无效；
• 到 config.plist 中把独显禁用掉，无效；
• 把磁盘取出，换到另一台主板无独显的 T450s 上尝试，也无法进入。

迄今为止一个月过去了，无果。

讨论链接为：https://github.com/CLAY-BIOS/Lenovo-ThinkPad-T450s-Hackintosh-OpenCore/issues/137；

下载链接为：https://drive.google.com/file/d/1Wi4aq5cRqrWG0htYbBOUXW5_Mi7UpBTj；

是为备用。

这个东西的成熟度出乎意料。它可以自动把官方最近几个版本的 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 是同时带了指点杆的，仍可操作，否则就只能外接鼠标了。

选择的是方案二，也即从新安装一份 Ventura。在 MacBook Pro 2015 上不能直接下载安装应用，但是可以使用 OpenCore Legacy Pather 下载，速度嗖嗖的。比有的人分享在百度或者夸克网盘上的链接快多了。

先把目标磁盘按照计划准备好。第一是创建了 OpenCore 需要的 EFI 分区，大小 1GB，把适用于 Latitude 5400 的 OpenCore EFI 文件放置到其中，第二是创建 macOS 自己的 EFI 分区，409600 个 512 字节的扇区，并把一份真实的副本逐扇区覆写了上去。将此磁盘置于 Latitude 5400 硬盘仓内，又把 Ventura 的安装 U 盘插到 USB 接口上。通电开机。

按照计划执行的第一次尝试，开头很顺利，但后面不慎失败。原因在于，目标磁盘的准备工作中，仅仅创建了两个 EFI 分区，留待安装 macOS 的空白区域是想在 Ventura 的安装过程中创建分区的（macOS 采用的是卷宗还是宗卷这个术语）。但不曾想 Ventura 安装盘中自带的磁盘实用工具（Disk Utility）在做判断时，不会把 EFI 分区纳入有效数据的考量，悍然视已有的两个分区为无物，直接将整盘重新分区了，导致 OpenCore 灰飞烟灭。

不过在这个过程中有另外一个收获。可能是由于 OpenCore 的配置文件的原因，Ventura 安装器一开始的界面是一种不认识语言，严重影响阅读交互。到网上找，都是说需要重新修改 config.plist 后再次安装。要知道 config.plist 在 OpenCore 所在的 EFI 分区里，还得用 PE 之类的环境去修改。后来想通一节，这个玩意儿似乎是受 nvram 变量影响的，而依稀记得 macOS 是有 nvram 命令行工具的。于是摸索着打开终端，先是输入 nvram 试了一下，发现确实由此命令，并且会输出帮助。然后就照着帮助执行 nvram -p 把当前的各个变量打印了一遍，发现了网上说的那个要改动的值名 prev-lang:kbd，它的值是 hu-HU。老夫依葫芦画瓢，按照命令格式执行了 nvram prev-lang:kbd=zh-CN ，重启就好了，界面成了中文。其实原来的值在指定语言后面还有冒号隔开的一个串，带有百分号之类的东东，似乎是日期什么的格式，没有理会它，直接忽略掉了。

于是重新做两个 EFI 分区，而且偷了懒，没有再将第二个 EFI 分区内克隆真实的 macOS EFI 分区内容。但最重要的是要补上第一次缺失的环节：把剩余空间创建了一个分区，文件系统选择的是 Apple APFS。然后再次开始安装。安装过程可以用非常顺利来形容，中间仅有的一个小插曲是，DiskGenius 创建的那个分区，虽然选择的是 Apple APFS 格式，但安装器不承认，要到磁盘实用工具里选中这个分区，再次确认选中 Apple APFS 文件系统，应用即可。

现在，Ventura 已经在良好运行中了，貌似风扇转速有点大。

新买一台符合要求的 Mac 电脑当然是最省事的，可是却费钱，这年头，咱缺的就是钱。打量了一番 Latitude 5400，之前它跑 Monterey 也是可以的，查了一下，对 Ventura 的支持也有了（甚至是支持 Sonoma 的，只不过有人说有问题，触控板不工作）。

对老夫老说，黑苹果的来源有两个途径：一是把一份现有的白苹果复制出来，成为黑苹果，二是像大家通常那样，新安装一份。第一种方法的局限在于，源系统的版本要直接就符合要求，如果寄望于黑苹果从官方途径升级，现实中的情形是，更新大版本不翻车的概率是比较低的。但奇怪的是，老夫的心里通常比较抵触新安装，总是觉得麻烦，甚至抵触到不想去捋清楚究竟有多麻烦，麻烦在哪儿。这儿先把一些基本情况记录一下，这些知识对实际操作是必然有用的，无论最后采用什么方式。

对 MacBook Pro 2015 的磁盘布局查看了一下，发现眼下苹果的做法已经相当简洁了，整个系统盘，以 GPT 方式作为分区布局，仅划了两个分区，一个是 EFI 分区（也叫 ESP），剩下的就是 macOS 系统的整个所在，是一个容器分区。

黑苹果的磁盘布局，有个痛点是需要新增一个 ESP，以供 OpenCore 或者 Clover 使用，而且这个 ESP 必须位于 macOS 自己的 ESP 之前。这是老夫之前的实践结论。如果你跟老夫一般，比较习惯观察，你会发现一些奇怪的点：macOS 的 ESP 上是没有文件的，也就是说，从文件系统的角度来看，这是一个空白分区。然而，如果你把这个分区干掉，macOS 系统就无法被发现并引导。而且，如果你把这个分区上写了文件（老夫就曾想把 OpenCore 的文件直接放到这个空白分区上），那么，它也就自动失效了。这个事实也许并不是必须，因为老夫也曾亲眼见过在 macOS 下制作的系统安装 U 盘，虽然绝大部分的情况下也会有这个分区，但确实有一次，没有这个分区，它也可以正常执行安装。最诡异的是，有和没有这个分区的情况，就是在什么都没变的情况下先后两次操作而产生的。

所设想的步骤如下：

1. 在 macOS 环境之外，先把磁盘清空，创建 GPT 格式的分区表，并在此盘头部创建一个 ESP 出来，大小 1GB 左右基本够用了，以供 OpenCore 使用；
2. 在紧挨着 OpenCore 的 ESP 之后，再创建一个 ESP，它要跟白苹果的 ESP 完全等大；根据 diskutil info disk0s1 的输出，
   

   % diskutil info disk0s1
      Device Identifier:         disk0s1
      Device Node:               /dev/disk0s1
      Whole:                     No
      Part of Whole:             disk0
   
      Volume Name:               EFI
      Mounted:                   No
   
      Partition Type:            EFI
      File System Personality:   MS-DOS FAT32
      Type (Bundle):             msdos
      Name (User Visible):       MS-DOS (FAT32)
   
      OS Can Be Installed:       No
      Media Type:                Generic
      Protocol:                  PCI
      SMART Status:              Verified
      Volume UUID:               0E239BC6-F960-3107-89CF-1C97F78BB46B
      Disk / Partition UUID:     0D7FDA06-6DEF-4C0A-AEE5-5C1403C97804
      Partition Offset:          20480 Bytes (40 512-Byte-Device-Blocks)
   
      Disk Size:                 209.7 MB (209715200 Bytes) (exactly 409600 512-Byte-Units)
      Device Block Size:         512 Bytes
   
      Volume Total Space:        0 B (0 Bytes) (exactly 0 512-Byte-Units)
      Volume Free Space:         0 B (0 Bytes) (exactly 0 512-Byte-Units)
   
      Media OS Use Only:         No
      Media Read-Only:           No
      Volume Read-Only:          Not applicable (not mounted)
   
      Device Location:           Internal
      Removable Media:           Fixed
   
      Solid State:               Yes
      Hardware AES Support:      No

   
   可以清楚知道所需扇区数，这个活儿用 DiskGenius 非常合适，后续把一份白苹果上此分区的映像文件（用 dd 命令应该可以备份出来）覆盖上去即可。
3. 至于最后整个的 macOS 系统，把这块准备好的磁盘用 USB 连接到源 macOS 所在电脑，引导进入恢复模式，用 Disk Utility 的恢复功能，从源分区回复到目标分区即可。当然，这是把白苹果迁移为黑苹果的模式。如果是新安装的话，最乐观的推测是：将这块准备好的磁盘置入目标电脑内，并将 macOS 的安装盘插入，OpenCore 会识别出安装盘并允许将至引导起来进行安装过程。然后把 macOS 安装到目标分区即可。

以上均为在大脑中的推演，尚未实战。不过理论上感觉把步骤都想到了，带有结果了再来汇报更新。

当然，当务之急是，要么把一台白苹果升级到 Ventura，要么下载一份 Ventura 的安装包，制作一个安装盘。