DMG镜像写入硬盘分区：x86平台完整实操指南

不管你是折腾黑苹果的玩家，还是系统维护工程师，想必迟早会遇到一类需求：手里有一个 .dmg 格式的镜像文件，目标却不是“双击挂载”这么简单，而是需要把它原原本本写到一块硬盘分区上，做成可以直接引导的安装盘或者恢复盘。这里说的“写入”，不是普通复制文件，而是逐字节地把镜像内容刻录到目标分区，像老式光盘刻录一样。

这类操作在网上搜出来的资料往往比较零散，有的讲 U 盘启动盘，有的讲磁盘工具恢复，还有的用一堆术语把人绕晕。作为一个在 x86 平台上反复踩过坑的实践者，我打算把 dmg 写入硬盘分区这件事从头到尾捋一遍，把真正能用的命令行、图形化方案、以及那些一碰就炸的注意事项都讲清楚。无论你是在 macOS 系统里操作，还是因为工作需要跑到 Windows 环境下处理 dmg，这篇文章都可以给你一份能直接照做的参考。

1. 场景与前置知识

1.1 dmg 到底是个什么东西，为什么非要“写入”而不是“复制”

.dmg 是苹果磁盘映像格式的缩写，全称 Apple Disk Image。它本质上是一个容器文件，里面可以封装整个文件系统的结构、引导信息、分区布局，甚至多个分区。你从 App Store 下载的 macOS 安装器，或者从各种渠道获取的系统恢复镜像，通常都是 dmg 格式。也有人会把整个 Linux 文件系统打包成 dmg 用在虚拟化场景，但最常见的使用场景依然集中在 macOS 生态。

为什么要把 dmg“写入”分区？因为 dmg 内部往往包含引导扇区、恢复分区等底层结构，如果只是用文件管理器把里面的安装包拖到磁盘里，那些引导信息根本不会生效。磁盘在启动时，固件会按照预定义的顺序去读取特定位置的引导代码和数据，只有把 dmg 的原始数据完整地刻录到目标分区上，才可能让这块分区具备可引导性。道理等同于把 ISO 镜像刻录到光盘或者写到 U 盘，单纯把 ISO 里的文件拷进去是启动不了的，这一点玩过 Linux 装机的人应该深有体会。

1.2 x86 架构下的特殊之处

标题里特意标注“x86”，不是没有原因的。x86 架构指的是采用 Intel 或 AMD 处理器的平台，和手机、平板、Apple Silicon 设备上的 ARM 架构不同。x86 环境下跑 dmg 写入，通常面临三种情况：

• 在真实的 Intel Mac 上操作，这最顺利，因为 macOS 原生提供了一套完整的磁盘和映像工具。
• 在 Windows PC 上操作，但目标是为某台 x86 设备准备引导盘，这时候需要借助第三方工具才能读写 dmg。
• 在虚拟机（如 VMware、VirtualBox、QEMU）里模拟 macOS 或 Windows 后操作，磁盘设备命名和真实硬件会有差异，需要格外留意。

x86 和 ARM 的底层差异主要体现在引导协议、分区表规范、以及对文件系统格式的支持上。比如在 ARM 平台（Apple Silicon Mac）上，系统要求分区使用 GUID 分区表（GPT），启动卷通常采用 APFS 格式；而在 x86 平台，除了 GPT，比较老的机器还保留了 MBR 引导方式的支持。写入 dmg 的时候，如果分区表类型和镜像内部的引导方式不匹配，哪怕 dd 成功了，磁盘依然启动不了。这一点我在实际操作中吃过亏，后面会详细讲。

1.3 工具与环境准备

开始操作前，先盘点需要准备的东西。核心工具其实很少：

• 一个待写入的目标硬盘或分区，可以是 U 盘、移动硬盘、或者电脑内部的一块空闲分区。注意，如果目标是“分区”而不是“整块磁盘”，有些工具会限制你只能写入分区而非磁盘，所以要提前规划好。
• dmg 镜像文件，推荐放在本地磁盘上，不要放在待写入的目标盘上，否则可能出现设备繁忙或数据源被覆盖的问题。
• 在 macOS 环境，自带的 hdiutil、dd、diskutil、磁盘工具.app 就够了，不需要额外安装第三方软件。
• 在 Windows 环境，建议准备 TransMac 或者 Rufus（Rufus 对 dmg 的支持有限，但也不是没有办法），另外还需要一个能读取 dmg 格式的工具。

这里有一个容易忽略的前置条件：目标分区的容量必须大于等于 dmg 镜像解包后的大小。因为 dmg 可能是压缩过的，文件本身看着不大，但展开后可能占用好几 GB。写入时如果空间不够，会报出“No space left on device”之类让人摸不着头脑的错误，实际上就是容量没算好。

2. 实操：命令行方式写入

2.1 先认清楚你动的是哪块盘

我在各种教程里反复看到一个现象：很多人不知道自己的目标设备对应的是 /dev/diskX 中的哪个 X，结果把系统盘给写穿了，惨痛教训。所以第一步永远是查看当前磁盘列表。

在 macOS 终端里执行：

bash复制diskutil list

输出结果类似这样：

text复制/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                 Apple_APFS Container disk3          499.8 GB   disk1s2

如果目标是一块刚刚插入的 U 盘，一般会出现在 /dev/disk2 或 /dev/disk4 之类。利用容量大小和名称来判断，尤其要看 “TYPE” 列，如果它显示 GUID_partition_scheme 或 FDisk_partition_scheme，说明这整块盘是物理磁盘。如果目标是要写入某个具体分区，比如第 2 个分区，那就是类似 /dev/disk2s2 这种带 sX 后缀的命名。

这里要特别强调：dd 命令可以写入整块磁盘，也可以写入单个分区。如果写入整块磁盘，目标为 /dev/diskX；如果只写某个分区，目标为 /dev/diskXsY。两者效果不同。常见需求是制作可引导的安装盘，那么最好写入整块磁盘，因为 dmg 内部可能已经包含完整的分区表结构，写到分区上可能会破坏引导链。但如果 dmg 本身就是“恢复分区镜像”这种单卷映像，写进分区也说得通。要先弄明白你手里这枚 dmg 属于哪一种。

2.2 卸载目标设备：不卸载就 dding 的后果很严重

找到目标后，不能直接开写。macOS 会默认把插入的可移动磁盘自动挂载，如果你直接 dd，大概率会遇到 Resource busy，也就是设备正忙。原因是系统文件系统驱动占用了这个设备。

正确的做法是卸载这个设备（不是弹出硬盘），命令如下：

bash复制diskutil unmountDisk /dev/diskX

注意我用的是 unmountDisk，卸载的是整个磁盘，不是某个分区。如果你只需要卸载单个分区，可以执行：

bash复制diskutil unmount /dev/diskXsY

为什么要卸载而不是弹出？因为弹出会把设备从系统中断开，导致后面 dd 时找不到目标。而 unmount 只是让系统不再挂载文件系统，设备本身依然在线。

也有朋友问：我已经在磁盘工具里把分区抹掉了，还需要卸载吗？答案是仍然需要。抹掉操作只是重写了文件系统元数据，系统可能已经重新将其挂载到 /Volumes/xxx，所以 dd 前还是要确认目标处于未挂载状态。

2.3 dd 命令写入 dmg

当设备显示为未挂载状态，就可以开写了。假设目标磁盘是 /dev/disk2，dmg 镜像在 /Users/me/Downloads/install.dmg，使用下面这组命令：

bash复制sudo dd if=/Users/me/Downloads/install.dmg of=/dev/disk2 bs=4m status=progress

逐个参数解释一下：

• if=：输入文件，也就是你的 dmg 路径。
• of=：输出文件，这里直接指定块设备路径。
• bs=：每次读写的块大小。4m 是 4 MiB，这个值不算玄学，实际测下来 dd 的吞吐量在 4M 左右比较稳定，比默认 512 字节要快不少。如果遇到比较老的机器，可以考虑改成 1m。
• status=progress：这是在较新版本的 macOS 上才支持的参数，会实时显示进度和速度。如果没有输出，说明当前系统里的 dd 是从 BSD 来的旧版本，可以去掉这个参数改用 Ctrl+T 发送 INFO 信号来看进度。

写入过程中终端会刷出一串串进度信息，耐心等待。速度取决于镜像大小和存储介质，U 盘一般 20MB/s 到 100MB/s 不等，SSD 移动硬盘可以到几百 MB/s。写大镜像的时候完全不用一直盯着，去做别的事，回来后看一眼是否回到命令提示符即可。

写完后系统不会有“写入成功”的庆祝语，dd 的特性就是静默成功。为了确认结果，可以执行：

bash复制sudo diskutil list

看看目标盘的分区结构是否发生了变化。或者用 hdiutil imageinfo 校验一遍镜像完整性，但那个校验的是镜像本身，不是写入结果。如果你不放心，可以在写入前记录整盘的分区签名，写完后再对比。

2.4 要不要先转成 ISO 或者 DMG 直接写

很多人会问：dmg 能不能直接用 dd 写？官方没有禁止，但有些情况下 dmg 内部包含多层封装。比如你下载一个 macOS 安装器，实际得到的可能是黄蓝色的安装器 .app 里面的 InstallAssistant.pkg，或者是一个 .dmg 里又套了另一个 .dmg，这就是热词里出现的 “failed to mount outer dmg” 的根源。这种嵌套结构如果直接 dd 到分区，结果是无法引导的。

我的习惯是：在写入之前，先用 hdiutil attach 挂载 dmg 看一层内容。如果挂载后看到的是一个 .app 或者 .pkg，说明它是安装器，不是那种可以直接写入分区的“可引导镜像”。你需要找的是包含完整系统文件的恢复镜像，或者通过 createinstmedia 一类官方工具去生成安装介质。

如果你手里的 dmg 只是某个文件系统的快照，那么 dd 完全够用。如果手头是 ISO 格式，想转成 dmg，也可以使用：

bash复制hdiutil convert -format UDRW -o output.dmg input.iso

其中 UDRW 表示读写模式，生成的文件可以直接 dd 写入。这个转换过程经常被用来把 Linux ISO 烧录到 U 盘后再改成 macOS 可读格式，实际项目中经常用。

3. 使用图形化工具写入

3.1 在 macOS 上使用磁盘工具

如果你不想用终端，macOS 自带的“磁盘工具”也能完成类似操作。打开磁盘工具后，从左侧边栏选择你要写的磁盘，但注意磁盘工具没有直接“写入 dmg 到分区”这个按钮。真正能做这件事的菜单是“恢复”标签页。

操作路径是：

1. 在磁盘工具中选择左侧目标磁盘。
2. 点击上方工具栏里的“恢复”图标。
3. 在“映像”旁边点击“选择”按钮，找到你的 dmg 文件。
4. 确认目标位置是否选对了。
5. 点击“恢复”，等待完成。

磁盘工具的作用原理和 dd 并不完全相同，它内部使用的机制有点类似 asr（Apple Software Restore），会进行一些格式转换和必要的分区布局调整。对于大多数系统镜像和恢复镜像来说，磁盘工具的成功率其实比裸 dd 更高，因为它会自动处理 APFS、HFS+ 这类文件系统细节。

不过磁盘工具有一个限制：它通常只能恢复整个磁盘，或者恢复到一个容量大于等于源映像的分区。如果你拿到的 dmg 内含分区表，那么建议恢复到整个磁盘，而不是某个分区。另外，如果磁盘工具在恢复过程中报错，比如 “Couldn't mount the image”，这时候请参照第 4 节的问题排查思路。

3.2 Windows 环境下处理 dmg 的替代方案

很多时候你的主力电脑是 Windows，手里却拿着一个 dmg 镜像，目标是要做一张给物理机用的启动盘。这时候 macOS 自带工具就用不上了，市面上能用的免费工具不多，我试过几种，靠谱程度排个序：

• TransMac：老牌共享软件，免费版有 15 天试用期。它可以直接识别 dmg 镜像并恢复到 U 盘或磁盘，界面上有明确的 “Restore with Disk Image” 选项。实测下来它对大多数 dmg 兼容性不错，但免费版每次打开会弹窗提醒，速度也偏慢，不过胜在能用。
• Rufus：Windows 上制作启动盘的神器，但它对 dmg 支持很弱，通常需要先把 dmg 转成 ISO 才能用。Rufus 在写入 ISO 时表现很好，支持 GPT/UEFI 和 MBR/Legacy 两种模式，适合 x86 平台。
• balenaEtcher：软件本身看着简洁，但实际上它主要写 ISO、IMG 格式，对 dmg 的兼容性一般，偶尔会出现解压失败。如果非要试，可以先把它当成“盲写”工具，能写入但不保证引导成功。
• 命令行方案：Windows 的 dd 并没有原生支持，需要安装 Cygwin 或者 Git Bash 中的 coreutils，再配合 Windows 的磁盘设备路径（比如 \\.\PhysicalDrive2）才能写入。这套方案坑很多，建议新手别碰。

如果在 Windows 上想把 dmg 转换成 ISO，推荐用 PowerISO 或者 UltraISO。转换后的 ISO 再用 Rufus 写入，整体成功率会高很多。注意转换过程不等同于解包，它只是重新封装了一层，文件系统和引导结构都会保留在 ISO 里。

3.3 虚拟机环境下的操作细节

如果你是想在虚拟机的 macOS 里给宿主机 U 盘写入 dmg，需要先把物理 U 盘透传给虚拟机。在 VirtualBox 里是 “Devices > USB”，在 VMware 里是 “Removable Devices”，连接后会看到虚拟机里出现一个新的 /dev/diskX。

这里有一个非常容易踩的坑：虚拟机看到的磁盘编号和宿主机上的物理磁盘编号不完全对应。比如宿主机上 U 盘是磁盘 2，虚拟机里可能因为虚拟磁盘的存在变成磁盘 3 或磁盘 4。所以在虚拟机里执行 diskutil list 之后，要通过容量大小和磁盘名称做双重判断，避免把虚拟机的系统盘当成 U 盘给 dd 了。我在 VMware 里有一次就差点把 macOS 虚拟机自己的虚拟磁盘给覆盖掉，那种情况哪怕是 Ctrl+C 都不能及时止损，因为 dd 写的速度非常快。

4. 常见问题与排查技巧实录

4.1 dmg 挂载失败：failed to mount outer dmg

这是热词里出现频率最高的问题，很多人下载完 dmg 后，双击挂载或使用 hdiutil attach 挂载时报错 “failed to mount outer dmg”。这个提示直译是“挂载外层 dmg 失败”，但实际上原因很多。

最常见的原因是网络下载不完整。dmg 文件没有严格的校验机制，丢几百 KB 数据也可能导致磁盘映像结构损坏，而操作系统在挂载时会去读取文件头里的分区块描述，一旦缺失就直接拒绝挂载。

排查方法是重新下载一次，最好用支持断点续传的下载工具，并在下载后对比文件大小，甚至计算 MD5 值看看是否和官方说明一致。其次，某些从非官方渠道获取的 dmg 可能被二次打包或者加密，也会触发同类错误。遇到这种情况，可以先用 hdiutil imageinfo 查看映像信息：

bash复制hdiutil imageinfo suspicious.dmg

如果该命令也报错，基本可以断定文件本身损坏。如果 imageinfo 能输出信息但 attach 失败，可以尝试强制挂载：

bash复制hdiutil attach suspicious.dmg -nobrowse -readonly

-readonly 参数可以避免在挂载时自动写入某些元数据，有些允许只读挂载的损坏镜像也能临时蒙混过关。但注意，就算挂载成功了，生成的 dmg 也不适合直接写入分区，因为内部数据可能不完整。

还有一个鲜为人知的点：某些 dmg 使用 zlib 或 bzip2 压缩算法，老版本 macOS 对 bzip2 压缩的 dmg 支持不完善，也会出现挂载失败。解决方式是换一台较新系统的设备挂载，然后把内容复制出来重新打包成 UDRW 格式的 dmg。

4.2 写入成功却无法引导：分区表类型和固件引导模式

这是 x86 环境下最让人抓狂的问题：dd 写完了，没有报错，目标盘插到机器上就是不引导。我把这类问题总结成一个速查表，方便你自己对照排查。

其中最容易忽略的一点是：对 x86 传统 BIOS 机器来说，如果镜像内部的分区表是 GPT，而这些机器不支持从 GPT 引导（除非开启了 UEFI CSM），那么写入后是无引导能力的。对于新一些的 UEFI 机器，如果分区表是 MBR，但没有正确的 EFI 系统分区（ESP），同样也可能无法引导。所以在动手之前，最好先了解目标机器的固件设置，实在不确定就优先采用 UEFI+GPT 组合，这兼容性最广。

4.3 dd 写入到一半卡死或报错

dd 中途卡死是另一个高频故障。表现有两种：进度条长时间不变，或者干脆直接输出 dd: /dev/diskX: Input/output error。

第一种，进度条长时间不动，可能是源镜像存放在移动硬盘上，而移动硬盘进入了低功耗休眠，dd 在等待磁盘响应。这时候千万别急着拔线或者 Ctrl+C，否则很容易得到一块分区表写到一半的坏盘。正确做法是等待一两分钟，通常磁盘会自己恢复。如果实在等不了，可以在保持其他程序不干扰的情况下，用另一个终端执行 top 查看 dd 进程是否还在占用 CPU 或磁盘 I/O。

第二种，I/O error，基本是硬件层面的问题：U 盘主控过热、硬盘有坏道、USB 供电不足等。这属于物理故障，只能换一个存储设备重试。我遇到过很多廉价 U 盘标称 64GB，实际写入到 50GB 后就频繁报错，厂家用了黑片闪存，容量虚标。所以做重要安装介质，建议选大品牌的 U 盘或移动固态硬盘。

还有一种情况属于“软错误”：dd 写入的目标磁盘比源镜像容量小。dd 不会自动判断容量是否足够，它只会一直写，直到目标写完才报 No space left on device。这时候目标盘的分区表已经被覆盖了一半，基本废了，只能重新抹掉再来。所以写之前务必对比一下两个尺寸，使用 df -h 查看目标磁盘容量。

4.4 写入后 macOS 无法识别分区

这种情况常见于在 Windows 下用 TransMac 写完后，插回 Mac 上发现磁盘工具里看不到，或者显示成一整块未初始化的磁盘。

原因在于 TransMac 写入的 U 盘分区格式并非 macOS 默认支持的 HFS+/APFS，而可能变成了 Windows 能识别的其他格式，或者在写入过程中把 GPT 备份分区表弄丢了。此时可以尝试在 macOS 终端里用 diskutil list 查看，如果能看到 /dev/diskX 但看不到分区，说明分区表损坏。可以用 sudo gpt -r show /dev/diskX 查看 GPT 头，进一步确认分区表是否完好。

如果确认分区表损坏，最简单的修复办法是重新执行一次 dd，这次换一台稳定的机器，或者改用磁盘工具恢复。如果只是想救回数据，可以用 TestDisk 这类分区恢复工具扫描，但失败率不低，不如重新写入来得干脆。

5. 避坑建议与实际体会

5.1 写入分区而不是整盘时，千万别忽略备份

分区级写入的风险比整盘写入更高。因为 dd 会在分区的起始位置写入数据，如果你选错了分区，覆盖的就是该分区的头部区域。但问题在于，虽然分区表里标注了分区边界，DD 并不会受这个边界限制，它只会从目标设备的起始偏移开始写。如果你把目标写成 /dev/disk0s2 里的 s2，那么 dd 会直接从这个分区的起始扇区开始写，但它不会“跳过”分区表或者自动停在分区尾部，所以其实是有可能溢出写到相邻分区甚至整个磁盘的。

虽然从机制上看，写分区比写整盘安全一点，但只要有轻微的偏移错误，就会破坏整个磁盘的分区结构。我的建议是：凡是涉及 dmg 写入，一律先备份分区表。

备份分区表用以下命令：

bash复制sudo gpt -r show /dev/diskX > gpt_backup.txt

备份完成后，把输出文件保存到安全位置。万一写入失误，可以用 gpt 工具把原来的分区表恢复回去。当然，前提是你没有把整个磁盘的开头部分全部覆盖，否则光恢复分区表也救不回已经覆盖的数据。

5.2 关于 bs 参数的实测心得

很多教程推荐 bs=1m 或者 bs=4m，我发现这个参数在不同环境下差异很大。在我日常工作的 Intel Mac 上，bs=4m 写入移动固态硬盘大约 500MB/s，而 bs=1m 只有 250MB/s 左右。但插在慢速 U 盘上，bs=1m 和 bs=4m 几乎没区别，瓶颈全在 U 盘本身。

bs 值设置得太大也不是好事，比如 bs=64m 在某些 U 盘上反而会变慢，因为底层驱动需要分配大块连续的 DMA 缓冲区，一旦失败就会退化为逐块拷贝，速度反而下降。如果没有特殊需求，就按我前面说的 bs=4m 来，不会有太大问题。

另外，conv=sync 参数要不要加？这个参数的意思是：当输入文件读到末尾不足一块大小时，用零填充到整块大小。如果你确定 dmg 的完整大小是目标分区容量的整数倍，或者不想在分区尾部留怪异的数据，可以加上。但在大多数场景下，不要加，因为它可能掩盖源文件长度不足的问题，导致目标分区尾部多出一堆零，反而影响了分区表的备份结构。

5.3 写入后立刻验证

很多人 dd 完就拔盘了，直到下一次插上才发现盘有问题。我建议写入后不要立刻拔，先做一次验证。

在 macOS 下，可以重新挂载目标盘，然后检查其文件系统是否可读：

bash复制diskutil mount /dev/diskXsY
ls -la /Volumes/xxx

如果能够看到文件列表，说明文件系统层面没问题。但这还不能保证引导一定成功，要验证引导，需要把目标盘接到实际的目标机器上试一次，或者在虚拟机里用该盘作为启动磁盘测试。对于 x86 平台，最实用的做法是把 U 盘插到一台装有 Windows 或 Linux 的机器上，在启动时进入引导菜单，看看是否多出设备和相应引导项。

5.4 后续扩展：从 dmg 制作可启动 ISO

最后分享一个我经常用的小技巧。如果手里的 dmg 不希望直接写到分区，而想转换成一个标准的 ISO，用于虚拟机挂载或共享给 Windows 用户，可以执行：

bash复制hdiutil convert install.dmg -format UDTO -o install.iso

这里的 UDTO 参数表示 DVD/CD-R 主映像格式，实际上就是 ISO 的另一种叫法。转换完成后，把生成的文件后缀改成 .iso，就可以被 Rufus、VMware 直接使用了。第一次我做完这个操作的时候，一度怀疑是不是尾部少了 2048 字节的块，后来发现是文件扩展名的问题，hdiutil 默认生成的文件并不带 .iso 后缀，直接重命名即可。

如果你需要对镜像进行更精细的编辑，比如替换里面的引导文件，可以先把 dmg 挂载为可读写，然后用 asr 工具分卷恢复。这些都是后续深入的话题，但基础分区写入能跑通，玩别的就顺手多了。

我个人的经验里，dmg 写入分区其实不是技术门槛多高的事，真正难的是事前判断这个 dmg 能不能直接引导、目标盘容量够不够、以及提醒自己不要选错设备。每当我看到网上有人把系统盘 dd 掉然后哀嚎时，我都想说：命令本身不危险，危险的是以为所有命令都像 Windows 安装包一样弹窗问你“是否继续”。把 diskutil 和 dd 的每一步都当回事，把备份做到位，这种操作完全可以成为熟手日常的常规动作。