我为通用工作站映像创建了自动部署脚本，但我发现了一些无法解决的问题。我希望其他人之前也遇到过这种情况，只是我没有正确搜索，或者我在 16 小时内遗漏了一些显而易见的东西。
环境：
- Ghost32 11.5
- WinPE 3.0
- Windows XP Sp3 单分区磁盘映像
似乎任何时候目标驱动器都是完全空白的；恢复并重新启动后，我被困在左上角一个不断闪烁的光标。
我将在下面详细介绍我迄今为止尝试过的场景，希望有人能够发现我遗漏的东西。
（在每个启动介质中，WinPE 的启动介质都是 USB 驱动器（在 RAM @ X: 中加载 WinPE），目标硬盘驱动器是 74Gb 内置 SATA）
编辑：我认为 Diskpart 可能是问题所在，并使用 Gdisk32 重试这些操作以完成磁盘操作，但结果没有改变。
场景 1
（目标驱动器上有一个可启动的主 ntfs Windows XP 分区，占据了整个驱动器。）
我运行 Diskpart，选择磁盘 (0) 并CLEAN执行此操作。（省略此步骤将产生相同的结果）
然后我运行 ghost32.exe 并从映像导航到本地磁盘并选择我的映像，目标磁盘 0
一切都按计划进行，系统启动，sysprep 运行，一切准备就绪。
场景 2
（接上文）
重新启动进入 WinPE。运行 Diskpart，选择磁盘 0 并CLEAN重新启动系统进入 WinPE。
（我确认磁盘 0 是空的）
我如上所述运行 ghost32.exe 并从映像中恢复磁盘。
无休止闪烁的光标。
如果我重新启动进入 WinPE 并在此时再次恢复，它就会工作，本质上与场景 1 相同，只是它之前 [不] 工作。
场景 3
（认为这可能与 WinPE 中的驱动器号分配以及 Ghost32 对恢复的磁盘所做的更改有关）
我启动到 WinPE 和CLEAN磁盘 0，然后再次重新启动。
当目标驱动器为空时，源驱动器在 WinPE 中会收到 C: 驱动器号。恢复后，新创建的分区将收到较晚的字母（本例中为 E:，Cd-Rom 驱动器收到 D: [它是空的]）。
重新启动到 WinPE；我进入 Diskpart 并将源驱动器的驱动器号从 C: 重新分配给 W:，然后退出 Diskpart。
我如上所述运行 ghost32.exe 并从映像中恢复磁盘。
无休止闪烁的光标。
场景 4
（启动、清理并再次重启）
我进入 Diskpart 并在磁盘 0 上创建一个主分区（两次尝试 RAW 并格式化为 NTFS）。
我如上所述运行 ghost32.exe 并从新创建的分区上的映像恢复磁盘。
无休止闪烁的光标。
场景 5
（启动、清理并再次重启）
我进入 Diskpart 并在磁盘 0 上创建一个主分区，大小为 10MB，未格式化为 RAW 并且不处于 ACTIVE 状态。
我重新启动系统回到 WinPE（源仍然接收驱动器 C:，因为它是唯一格式化的分区） 我如上所述运行 ghost32.exe 并从映像中恢复磁盘。...
一切都按预期进行，sysprep 运行并且桌面出现。
问题
为什么在构建操作系统启动时，目标驱动器上需要在 Ghost32 上有一个分区才能生成可用的恢复磁盘？
我哪里做错了，我肯定漏掉了什么。如果我要恢复整个磁盘，那么恢复之前目标磁盘上有什么（或者更准确地说，没有什么）又有什么关系呢？我应该得到原始磁盘的精确副本，它也是磁盘 0，也是系统上唯一的驱动器。
任何帮助都将不胜感激，我已经准备好大发雷霆了。我真的不想编写脚本来创建原始分区并在检测到空白目标时强制重新启动（这是重建工作站时最有可能出现的情况）。
跟进
该问题似乎只发生在 HP nc6400 笔记本电脑上。我还没有找到另一种会重现该问题的工作站型号。我现在已经能够在几台工作站上进行测试，它们都表现出相同的行为（幸运的是，由于年代久远，我们刚刚把这些都从田里撤了出来）。
问题确实不是使用从 DVD 加载的相同图像时会出现此问题；因此，这似乎与源媒体有关。我曾认为这可能是系统检测 USB 驱动器的方式（有些系统将它们视为可移动媒体，有些系统将其视为固定磁盘），但在我手头的另一个允许控制此选项的系统上，在任一模式下均未出现相同的问题。
当使用 ImageX 恢复系统时，问题不会发生，因此这似乎是此特定系统处理 USB 驱动器的方式以及 Ghost32 执行的后恢复操作存在的问题。
答案1
不幸的是，这个问题今天才出现在我的 RSS 阅读器中，所以尽管它已经有好几年了，我仍然想为未来的读者提供可能正确的答案。
我不太了解您所描述的受影响的特定型号，但这听起来确实与某些 ThinkPad 型号（我记得是 T60）中出现的问题非常相似，该型号使用非标准多扇区 MBR，占用了引导轨道的几个扇区而不是通常的扇区，其结果与您描述的完全相同。
在引入 -IB 开关之前，Ghost 的经典映像格式仅存储原始的单个 MBR 扇区；这意味着实际上具有非标准、多扇区引导轨道内容的系统的映像仅包含必要引导代码的一半。
在几乎所有情况下，如果源图像不是用—IB开关，如果 Ghost 检测到您要恢复的目标磁盘中的引导代码，它往往会保留原始引导代码，而只操作引导扇区内的分区表。这是为处理使用特殊引导代码的系统而设计的（例如那些使用引导扇区挂钩来替换 BIOS 的系统），这意味着在大多数情况下，如果目标系统需要此类自定义引导代码，它将被保留下来并继续引导。
但是，如果目标磁盘完全空白，Ghost将要使用来自 MBR 扇区的映像的引导代码。如果您在获取映像时没有使用任何额外的开关（就像我们在 QA 实验室中发现的 ThinkPad 案例一样），则它所恢复的扇区会尝试从引导轨道中后面的扇区加载其余部分，默认情况下 Ghost 不会理会这些扇区。
因此，您有多种选择；您可以使用gdisk /mbr恢复后强制使用标准“安全” MBR 而不是制造商自定义 MBR，或者您可以使用—IB在捕获源映像时与 Ghost 切换，以强制 Ghost 对引导轨道中的所有扇区（而不仅仅是 MBR）进行映像。
以上是我们在开发 Ghost 的奥克兰实验室中发现的（直到 2009 年，赛门铁克关闭了该站点并取消了 Ghost Solution Suite 产品的开发）；我们的 QA 经理 Krish Jayaratne 发现了这一点，并对解决方法进行了主要调查，然后进行了一点检查以确认存在额外的启动代码。
虽然您的情况可能不一样，但听起来确实与此完全一样，我猜解决方案应该是一样的。我确实在 Symantec 官方论坛上向客户介绍了几次这个问题，并且记录得相当详尽，但自从 Ghost Solution Suite 产品被取消后，Symantec 就失去了有关这个问题的大部分机构知识。
编辑以添加：正如我上面提到的，如果存在现有 MBR，Ghost 默认在恢复“正常”映像时将引导代码保留在 MBR 中。但是，如果—IB开关用于捕获图像，事实上，该开关被记录为图像文件元数据的一部分（事实上，很多开关都是如此；部分模糊文件头中有一个大的 'ol 位数组，由全局变量填充 - 是的，真的 - 参数解析器将命令行开关提取到其中）。因此，不仅图像已采取和—IB有一个略有不同的结构来容纳额外的引导扇区，恢复过程的一方“知道”—IB用于拍摄图像。
我对这个过程的记忆（虽然我没有源代码可以证实这一点）是，如果—IB用于捕获映像，默认情况下，引导代码和额外的引导扇区将始终被恢复，从而使恢复过程具有与常规映像相反的引导代码默认处理方式。这背后的部分逻辑是恢复 UI 没有将引导代码存储在映像中的可选容器中 - 您无法轻松表达是否恢复它的选择（添加这一点会有点可用性复杂化；如果人们不理解它的含义，UI 永远不会“免费”）。另一个原因是 Ghost 的一些最重要的用户是计算机制造商，他们将其授权用于 OEM 恢复磁盘；如果计算机制造商的工厂恢复映像出于某种原因包含自定义引导代码，那么通常默认情况下他们会希望将其放回原处，并且—IB也暗示恢复时的行为略有不同似乎是“正确的”默认值。
这始终是一个微妙的平衡行为，因为这些花哨的特殊情况决定是让极其复杂的命令行变得更加复杂还是添加新的 UI 来使事情更加明确，还是尝试默认为大多数人做“正确的事情”而不让默认 UI 变得复杂。毫无疑问，我们并不总是做出正确的选择，但我们确实一直在为这种平衡而苦恼，特别是因为我们有数百万拥有我们不想破坏的脚本的客户。
答案2
听起来像是 Ghost 的一个错误。有一件事我没有看到，或者可能遗漏了：您是否尝试过编写脚本来一次性清理、创建、激活和分配 diskpart？
答案3
您可以在启动时按 F8 并进入命令行恢复模式吗？如果可以，请尝试 FIXBOOT，如果不起作用，请运行 CHKDSK /r。