关于 Hekate 多 emuMMC 启动项配置这件事儿-终极方案

折腾的乐趣不来自折腾后的成果，而来自折腾本身，于是，需求有时候是为折腾服务的。

背景

最近 Switch2 带来了塞尔达系列的更新包，系统要求 20+，之前我将系统降到 19 后，就无法进行这次更新，主要是好奇，于是我去真实系统更新到了 20.1.1。

不过好在没什么难的，说说我的配置：原有虚拟系统 19.0.1 （分区格式），再选择虚拟系统-创建文件虚拟系统（这里没有复选确认，点了就开始无后悔药）。

理论

分区–文件共存，文件–文件共存都比较简单，默认都不会冲突。

• 文件–文件共存似乎要更简单，直接复制一份 emuMMC 中的 SD00（例）改名为 SD01（例）即可。
• 分区–分区共存会比较麻烦，需要使用 PC 进行分区操作，复杂后面单独讲，何况之前也测试过，文件格式与分区格式除速度外差异并不大。

随后更改 hekate_ipl.ini，复制原有启动项并由 emupath 字段区分，当然 GPT 、Deepseek 会推荐什么 emummc!path、emummc_path、emummc!id 总之别信，因为这是来自官方更新日志中的字段：

附上我的启动项模板：

[虚拟系统-PLAY]
fss0=atmosphere/package3
kip1patch=nosigchk
cal0blank=1
emummcforce=1
atmosphere=1
usb3force=1
icon=bootloader/res/icon_payloademu.bmp
emupath=emuMMC/RAW1

[虚拟系统-LAST]
fss0=atmosphere/package3
kip1patch=nosigchk
cal0blank=1
emummcforce=1
atmosphere=1
usb3force=1
icon=bootloader/res/icon_payloademu.bmp
emupath=emuMMC/SD00

至此最基础的双虚拟系统配置完成。

说说缺点：

1、不支持选择虚拟系统来进行第二个虚拟系统的创建，默认都是以真实系统做镜像。

2、文件系统创建方式占用的 SD 卡空间会很大，默认 29G 直接做的真实系统镜像，仅分区形式可调整大小。

3、20 系统可用的 System 内存还是太少了，仅剩余 8 M，而 19 余 39M 差距并不是一点点。

4、一张 SD 卡，大气层插件并没法按系统进行区分。像达达可能需要的只是 60FPS 解锁和 amiibo，其他不那么重要，内存更加捉急。

说说好处：

1、可以在不同版本的系统玩不同 HOS 支持级别的游戏，比如，塞尔达在 20 系统解帧后体验更好。

2、各自运行在各自系统，Nintendo 文件夹各自独立，并不会冲突。

3、Pro 手柄/蓝牙音箱不用担心双虚拟系统每次都得重连，可通过大气层配置：enable_external_bluetooth_db = u8!0x1 进行共享处理，前人栽树后人乘凉。

分区与分区共存（仅尝试）

操作

多分区的系统做起来实际很简单：用 PE 下的 DG，将 SD 卡划出两片空闲空间，随便选个格式比如 EXT、FAT32，然后保存分区表，不要格式化，就形成了两个 RAW 格式的分区。

这两个 RAW 和 hekate 分区工具抹盘创建的 RAW 一样，可以直接在创建虚拟系统时被识别，然后对应每个分区各创建一次虚拟系统即可。

分区表的坑

分区式的虚拟系统是一锤子买卖，定下来后，就不可后续增减。因为分区很讲究，无论如何都会是一张“错误”的分区表：

为什么这是”错误”的呢，再上一张 hekate 分区读取图：

SWITCH SD 分区对应的是第 0 部分，Unknown 10G 对应第 1 部分，Unknown 15G 对应第 2 部分。

而这个顺序是 hekate 默认做分区时的顺序，从左往右，从而导致了我在加分区时，经历了这样的变化：

• 如果我再加一个 Unknown 18G 在 Unknown 10G 的左边，毕竟只有 Unknown 10G 左边有空闲对吧，思路没问题。
• hekate 就会变成 Unknown 18G 为 第 1 部分，Unknown 10G 对应第 2 部分，Unknown 15G 对应第 3 部分。
• 因为 hekate 每一个部分对应的是 RAW1 RAW2 …类推，那么此时要被识别为 RAW3 只能选第 3 部分，因为 1，2 部分已经被之前的系统占用了地址与唯一 ID
• 最后不管是选第 1 部分 重做（ID 冲突了，旧的找不到了），还是选第 3 部分重做（旧的真实文件分区直接被覆盖），都会是失败的。

这并非三分区的问题，二分区也会，我这里只是用更加复杂的举例了。如何解决？假设分区表倒过来：

此时理论上，空闲空间在 unknown 10G 右侧，增加的新分区自然而然成为了第 3 部分，也对应了 RAW3 并具有新的唯一 ID。

但不幸的是，此路不通。

1、首先 RAW 分区不能是最左第一个分区，因为第 1 部分会无法被识别，原第 2 部分会成为第 1 部分，SWITCH SD 因此成为第 2 部分，推测是为 Linux / Android 留的 EFI 引导分区。

2、位置问题好解，前面做一个空分区，虚拟系统就可以创建在我们想要的位置。但创建完成启动就会发现，这个顺序做的虚拟系统无法启动。不是大气层报错，而是 hekate 根本找不到虚拟系统所在位置。

所以分区-分区式 是一锤子买卖，一开始就做好，永不变动。hekate 必然有他这么做的理由，不必折腾。

这套方案致命的弱点除了无法变动，同时 hekate 并不支持备份第二分区，也就无从恢复，当然可以整盘 DD ，可几百 G 的空间 DD 很麻烦。

双分区示例：

其他细节

缩小 USER 分区

因为是虚拟系统，都在 SD 上，内置 USER 空间太大不方便备份也不方便移动，有必要了解这部分。

缩小 USER 分区的原理：按磁盘地址截断。意思就是，比真实系统小的空间，或者任何不由 hekate 创建的RAW 都会视为修改过的分区， 会对应文件系统碎片不全的文件映射（文件记录在，文件实际上不在）。

这也是分区类型多次操作后将导致文件系统交叉读写错误的来源。从而虚拟系统启动后一堆游戏打开/安装错误，碰到对应不存在的碎片地址大气层就直接崩溃。

解决办法是：在设置中初始化主机或直接 daybreak 降级恢复出厂。NS 的虚拟系统创建没有 DG 那种划配空间时的文件碎片整理功能，这也是 NxNandManager 不清除 User 分区数据就无法缩小的原因。

NxNandManager 缩小 SD00 式虚拟系统很简单，5.2 版本即可，支持 20.1.1 最新系统：https://github.com/eliboa/NxNandManager/releases，教程网上有很多，这里不赘述。

降级失败/初始化失败问题

另外值得一提的是，多系统因为是一张 SD 卡，共用一套大气层，从而产生的文件可能会导致某个系统在降级/恢复初始化后启动蓝屏。从而无法进入初始化流程，浅层的解决办法是：降级完成后，启动之前，将大气层还原到初始状态，不过这样治标不治本。

如果去检测 FAT32 文件系统，会发现频繁出现文件无法删除/一直占用等问题，DG 会提示文件交叉读写错误/分区损坏。这时候用 DG 检查磁盘坏块，就会得到答案。(注： DG 的坏块检测原理决定了对于不支持的磁盘格式会误判，需格式化对应位置为FAT32后单独对该区检测)

解决办法是：整盘格式化为 FAT 32 后再对虚拟分区那块地址检测坏块，如果不存在错误，就只是折腾时 hekate 多次来回创建虚拟系统累积导致的文件系统错乱。如果依旧存在错误，很不幸，SD 已经被折腾坏了，尽早换卡。

终极方案总结

经过多次双分区尝试，总结最合适方案为 10G RAW1（分区式主力 19.0.1）+ 8G SD00（文件式备用 20.1.1）的组合，好处如下：

1、最适合备份/恢复，RAW1 可直接通过 hekate 备份/恢复，单分区的情况下，换卡也可还原。SD00 直接拷贝即可备份/恢复。

2、最适合动态扩增，RAW1 虽然依旧是一锤子买卖，但 SD00 可通过 NxNandManager 进行空间缩小或者扩大，文件形式也不会存在分区那种 ID 或者物理地址覆盖问题。

文件式缺点：无法开启 USB 3.0。

当然有人会疑问为什么不是 文件 + 文件，很显然 FAT32 文件系统交叉读写导致的磁盘坏柱一旦发生，就不会是简单的修复可以还原，MacOS 操作下这类事件很常见。

以上。

参考：

Multiple emuMMC setup, including restoring a clean NAND for online use

Hekate v5.2.0 & Nyx v0.9.0 發佈啦！