☰

背景

tag-icon • tag-icon boot virtualbox iso-image deployment acronis-trueimage
背景

背景

我的职责之一就是在短时间内准备好多台装有一系列预配置软件套件的计算机以供使用。这些计算机的硬件各不相同，而且没有任何自动更新功能（更不用说集中式系统了）。为了解决部署和更新这些套件的问题，我一直在尝试使用 Acronis True Image。在通过 VirtualBox 托管在 macOS 上的 Windows 10 VM 中，我按照各种说明操作：

  1. 使用 Acronis Snap Deploy 5 创建 Acronis 可启动媒体 .iso。
  2. 从该图像启动。
  3. 离线创建主映像。
  4. 在新虚拟机上，从可启动媒体启动并成功部署主映像。

问题

虽然 .iso 可以很好地启动虚拟机：

在此处输入图片描述

尝试使用 unetbootin 刻录 .iso 只会导致它默默地挣扎，Rufus 说该图像不受支持，并且 Etcher 产生一个错误，说没有文件系统：

在此处输入图片描述

通过在 macOS 和 Windows 中安装映像可以确认这一点：

在此处输入图片描述 在此处输入图片描述

然而，图像中肯定有一些真实的数据：

在此处输入图片描述

问题

为什么 .iso 可以在 VirtualBox 上完美启动，但却没有明显的文件系统，无法映像到任何类型的 USB 驱动器？我如何创建此映像的可启动版本，以便在“真实”计算机上使用？

答案1

尝试写入图像没有使用转换工具（例如 unetbootin）。您可以使用普通的dd或直接映像工具，例如 Win32DiskImager。在 macOS 中，这个帖子建议：

  1. diskutil list找到“/dev/diskX”设备；
  2. diskutil unmountDisk /dev/diskX；
  3. dd if=/path/to/iso of=/dev/rdiskX bs=1M（评论建议使用“rdisk”以提高性能）
  4. diskutil eject /dev/diskX。

ISO 映像CD 映像（名称来自“ISO 9660”），其结构与“常规”磁盘不同。最重要的是，引导信息位于不同的位置 - CD 使用位于扇区 17 的“El Torito”引导记录；BIOS 兼容磁盘使用位于扇区 0 的 MBR；UEFI 兼容磁盘使用位于扇区 1 的 GPT 和一个完整的独立分区来包含引导加载程序。

因此，为了从 USB 启动 CD 映像，有两个选项：

  • Rufus 和 Unetbootin 等程序并不是简单地“刻录”映像；它们转变纯 CD 映像转换为 USB 映像。

    他们尝试识别图像的内容，将其提取到 USB 驱动器，并创建一个全新的引导加载程序 - 希望它与原始引导加载程序兼容。

    这要求转换程序真正理解 CD 映像的工作原理。（例如，如果 CD 使用 isolinux，则转换器需要将 syslinux 安装到 USB 记忆棒上。）

  • isohybrid 等程序准备图像它本身同时包含 CD（ISO 9660）、BIOS（MBR）和 UEFI 启动代码，因此无需进一步转换即可写入任何类型的磁盘。

    结果是一幅图像，其内容取决于你看待它的方式。当写入 CD 时，操作系统会找到常规 ISO 9660 文件系统。当完全相同的数据写入 USB 磁盘时，操作系统会找到一个很大的“空”分区和一个非常小的“EFI 启动”分区。例子。 例子。

这两种方法都很复杂，但最糟糕的情况是尝试结合两者。例如，Unetbootin 过去是一个很好的 CD→USB 转换工具，但现在 Linux 发行版通常以已经USB 兼容的混合 ISO 映像，Unetbootin 倾向于误解其内容并实际输出不再启动的图像。

最后，磁盘不需要有可见文件才能启动。制作光盘或磁盘启动所需的最低限度，但除此之外，一切都由 disc/k 自己的引导加载程序本身控制。所以你看到一个完全空的磁盘；引导加载程序可能只是在其他地方寻找自己的数据。

就你的情况而言，图像很可能已经是某种混合格式；它有刚刚够ISO 9660 文件系统让固件找到引导加载程序，但操作系统的其余部分则隐藏在其他地方。

您可以尝试使用以下方法确定它是否实际上与 BIOS MBR 启动格式兼容：

head -c 512 file.iso | hexdump -Cv

如果最后一行（000001f0）以 结尾55 aa，则表示存在 BIOS MBR 分区表。

相关内容