我为通用工作站映像创build了自动部署脚本，并且发现了一些我无法解决的问题。 我希望别人之前遇到过这个，我只是没有正确的search，或者我错过了明显的16小时。
环境：
看来任何时候目标驱动器都是完全空白的; 在恢复和重新启动后，我被困在左上angular无限闪烁的光标。
我将在下面详细介绍迄今为止我尝试的场景，希望有人看到我错过的东西。
（在WinPE的每个引导介质中都是一个Usb驱动器（将WinPE加载到RAM @ X :)，目标硬盘是74Gb内部SATA）
编辑：我以为Diskpart可能是问题，并重试这些使用Gdisk32完成磁盘操作，没有改变的结果。
（目标驱动器有一个工作的可启动主ntfs Windows XP分区，占用整个驱动器。）
我运行Diskpart，select磁盘（0）并CLEAN它。 （离开这一步将产生相同的结果）
然后我运行ghost32.exe，并从图像导航到本地磁盘，并select我的图像，目标磁盘0
一切按计划运行系统启动sysprep运行我们很好去。
（从上面的状态继续）
引导回WinPE。 运行Diskpart，select磁盘0并CLEAN它。 重新启动系统回到WinPE。
（我validation了磁盘0是空的）
我像上面那样运行ghost32.exe并从映像恢复磁盘。
闪烁光标没有结束。
如果我重新启动进入WinPE并在此时再次恢复，那么它将起作用，基本上与情况1相同，只不过是在手边工作。
（认为这可能与WinPE中的驱动器号分配有关，并且Ghost32可能会对恢复的磁盘进行更改）
我启动到WinPE和CLEAN磁盘0，然后重新启动。
目标驱动器为空时，源驱动器将收到WinPE中的C：驱动器号。 一旦恢复，新创build的分区将收到一个更晚的字母（E：在这种情况下，Cd-Rom驱动器收到D：[这是空的]）。
启动回WinPE; 我inputDiskpart并将源驱动器的盘符从C：重新分配给W：并退出Diskpart。
我像上面那样运行ghost32.exe并从映像恢复磁盘。
闪烁光标没有结束。
（引导，清理并重新启动）
我inputDiskpart并在磁盘0上创build一个主分区（尝试两个RAW并格式化为两个不同的尝试NTFS）。
我像上面那样运行ghost32.exe，并通过新创build的分区从映像恢复磁盘。
闪烁光标没有结束。
（引导，清理并重新启动）
我inputDiskpart并在磁盘0上创build一个大小为10MB的主分区，未格式化的RAW和未激活。
我重新启动系统回到WinPE （源仍然收到驱动器C：因为它是唯一的格式化分区）我像上面运行ghost32.exe，并从图像恢复磁盘。 …
一切按预期运行，sysprep运行和桌面出现。
为什么在构buildOS启动Ghost32生成一个可行的恢复磁盘时，在这个世界上是否需要在目标驱动器上有一个分区？
我在这里做错了什么，我必须失去一些东西。 如果我正在恢复整个磁盘，为什么它会更重要呢？ 在恢复之前不在目标磁盘上。 我应该得到原来的磁盘0和系统上唯一的驱动器的确切副本。
这里的任何帮助将不胜感激，我准备把我的头发。 我真的不想在脚本创build一个原始分区，并强制重新启动检测空白目标（这是最有可能的情况下，当有人正在重build工作站）。
该问题只出现在HP nc6400笔记本电脑上。 我还没有find另一个工作站的模型，将重现这个问题。 我现在已经能够testing几个，他们都performance出相同的行为（幸运的是，我们因为年龄的原因，把所有这些都从场上拉了下来） 。
从DVD加载时， 不会出现使用相同图像的问题; 所以它似乎与源媒体有关。 我以为这可能是系统检测USB驱动器的方式（有些人把它们当作可移动媒体，其他的则把它当作固定磁盘），但是在另一个系统上，我可以控制这个选项，问题在任一模式。
当使用ImageX恢复系统时，问题不会发生，所以这看起来是这个特定系统对待USB驱动器的方式以及Ghost32执行的恢复后操作的问题。
不幸的是，这个问题今天才刚刚在我的RSS阅读器中出现，所以即使已经有几年了，我仍然认为我会为未来的读者提供正确的答案。
我并不熟悉你所描述的特定型号受到影响，但这听起来与某些型号的ThinkPad（我的记忆说T60）中出现的问题非常相似，后者使用了一个非标准的多分区MBR，占用了几个扇区引导轨道而不是通常的轨道，结果与你描述的相同。
在引入-IB开关之前，Ghost经典的成像格式只存储原始的单个MBR扇区; 这意味着实际上具有非标准，多段引导轨道内容的系统的图像只有其中一半的必要引导代码。
在几乎所有不使用-IB开关拍摄源图像的情况下，如果Ghost检测到要还原到的目标磁盘中的引导代码，它往往会保持原始引导代码不变，只是在引导扇区内操纵分区表。 这是devise来处理那些使用特殊启动代码的系统（例如那些用boot-sector hook来代替BIOS的系统），并且意味着在大多数情况下，如果目标系统需要这样的自定义启动代码，会继续启动。
但是，如果目标磁盘完全空白，则Ghost 将使用MBR扇区映像中的引导代码。 如果与我们在QA实验室中发现的ThinkPad案例一样，您已经拍摄了没有额外开关的映像，那么它恢复的扇区会尝试从引导磁道中的后续扇区加载剩余的扇区，默认情况下，Ghost将独自离开扇区。
所以，你有几个select; 您可以在还原后使用gdisk / mbr以强制使用标准的“安全”MBR而不是制造商定制的MBR，也可以在捕获源图像时使用-IB开关与Ghost来强制Ghost将所有扇区引导轨道而不仅仅是MBR。
以上是我们在奥克兰实验室发现的Ghost（直到2009年赛门铁克closures网站并取消Ghost Solution Suite产品开发之前）的发现。 作为我们的QA经理的Krish Jayaratne发现了这个问题，并对这个解决方法进行了主要的调查，然后对这个额外的启动代码进行了一些检查。
虽然你的情况可能不一样，但听起来确实如此，我怀疑这个决议应该是一样的。 在官方的赛门铁克论坛上，我曾经多次为客户提供过这方面的介绍，并且logging得相当彻底，但是自从Ghost Solution Suite产品被取消以后，赛门铁克公司已经丧失了大部分关于这方面的知识。
编辑添加 ：如上所述，如果现有的MBR存在，则默认情况下恢复为“正常”映像的Ghost 会将引导代码单独留在MBR中。 但是，如果使用-IB开关来捕获一个图像，这个图像被logging为图像文件元数据的一部分（事实上，这在许多开关中都是这样;一部分被混淆的文件头有一个大的其中的ol位数组从全局variables中填充 – 是的，确实是 – 参数parsing器将命令行开关提取到中）。 因此，不仅用-IB 拍摄的图像具有微妙的不同结构来容纳额外的引导扇区，该过程的恢复侧“知道” -IB被用于拍摄图像。
我记得这个过程（虽然我没有源代码来确认它），如果-IB被用来捕获一个图像，默认情况下，引导代码和额外的引导扇区将总是被恢复，使得恢复过程有相反的默认处理引导代码到正则图像。 部分逻辑背后的原因是，恢复用户界面没有存储在可选容器的图像中的启动代码 – 你没有办法expression是否恢复它的select或不容易（添加是一个可用性复杂的一点;如果人们不明白它的意思，UI永远不是“自由”的）。 另一个是Ghost的一些最重要的用户是计算机制造商，他们为OEM恢复磁盘授权。 如果计算机制造商的工厂恢复映像包含自定义启动代码出于某种原因，然后通常默认情况下，他们会希望它放回，并有-IB还暗示恢复行为的细微差异似乎是“正确的”默认。
对于这些奇怪的特殊情况，决定是否让复杂的命令行变得更加复杂，或者增加一个新的UI来使事情更加明确，而对于大多数情况下默认做“正确的事情”人员，而不是使默认UI复杂。 没有任何争论说我们并不总是select正确的，但是我们总是为这种平衡而苦恼，尤其是因为我们有数百万客户使用我们不想破坏的脚本。
这听起来像一个鬼的错误。 有一件事我没有看到，或者可能会丢失：您是否尝试过使用脚本编写diskpart来清理，创build，激活和分配所有内容？
你可以在启动时打F8并进入命令行恢复模式？ 如果你到达那里试试FIXBOOT，或者如果不行的话，运行CHKDSK / r。