引導恢復的 Ghost 映像時游標閃爍
我為通用工作站映像創建了自動部署腳本，但我發現了一些我無法解決的問題。我希望其他人以前遇到過這個問題，而我只是沒有正確搜尋，或者我在 16 小時內遺漏了一些明顯明顯的東西。
環境：
- 幽靈32 11.5
- WinPE 3.0
- Windows XP Sp3 單分區磁碟映像
似乎任何時候目標驅動器都是完全空白的；恢復並重新啟動後，我被左上角不斷閃爍的游標卡住了。
我將在下面詳細介紹我迄今為止嘗試過的場景，希望有人能看到我錯過的東西。
（在每一個中，WinPE 的啟動媒體都是 USB 驅動器（將 WinPE 載入到 RAM @ X:)，目標硬碟驅動器是 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 相同，只是它是
$$ not $$提前工作。
方案 3
（認為這可能與 WinPE 中的驅動器號分配以及 Ghost32 可能對恢復的磁碟所做的更改有關）
我啟動到 WinPE 和
CLEAN磁碟 0，然後再次重新啟動。當目標驅動器為空白時，源驅動器在 WinPE 中接收 C: 驅動器號。恢復後，新創建的分區將收到一個較晚的字母（E：在這種情況下，Cd-Rom 驅動器收到 D：
$$ It is empty $$). 重新啟動到 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 生成一個可用的恢復磁碟？
我在這裡做錯了什麼，我必須錯過一些東西。如果我要恢復整個磁碟，為什麼重要的是什麼
$$ or more precisely; wasn’t $$還原之前在目標磁碟上。我應該得到原件的精確副本，它也是磁碟 0 和系統上唯一的驅動器。 在這裡的任何幫助將不勝感激，我已經準備好扯掉我的頭髮了。我真的不想編寫腳本來創建原始分區並在檢測到空白目標時強制重新啟動（這是有人重建工作站時最有可能發生的情況）。
跟進
該問題似乎只出現在 HP nc6400 筆記型電腦上。我還沒有找到可以重現問題的另一種工作站模型。我現在已經能夠測試幾個，它們都表現出相同的行為*（幸運的是，由於年齡的原因，我們剛剛從現場撤出了所有這些）*。
從 DVD 載入時使用相同的圖像不會出現此問題；所以它似乎與源媒體有關。我原以為這可能是系統檢測 USB 驅動器的方式（有些將它們視為可移動媒體，有些則視為固定磁碟），但在我擁有的另一個允許控制此選項的系統上卻沒有表現出相同的情況任一模式下的問題。
使用 ImageX 還原系統時，不會出現問題，因此該特定係統處理 USB 驅動器的方式以及 Ghost32 執行的還原後操作似乎存在問題。
不幸的是，這個問題今天才出現在我的 RSS 閱讀器中，所以即使它已經有幾年了，我想我會為未來的讀者提供可能是正確的答案。
我不熟悉您描述為受影響的特定型號，但這聽起來確實與某些型號的 ThinkPad（我的記憶說 T60）中發生的問題非常相似，該型號使用了佔用多個扇區的非標準多扇區 MBR引導軌道而不是通常的引導軌道，結果與您描述的相同。
Ghost 在引入 -IB 開關之前的經典映像格式僅儲存原始的單個 MBR 扇區；這意味著實際上具有非標準、多扇區引導軌道內容的系統映像中只有一半的必要引導程式碼。
在幾乎所有未使用**-IB**開關獲取源映像的情況下，如果 Ghost 檢測到您要還原到的目標磁碟中的引導程式碼，它往往會保持原始引導程式碼完好無損，並且只是在引導扇區內操縱分區表. 這是為了處理確實使用特殊引導程式碼的系統（例如那些使用引導扇區掛鉤來替換 BIOS）的系統，這意味著在大多數情況下，如果目標系統需要這種自定義引導程式碼，它將被單獨放置，並且將繼續啟動。
但是，如果目標磁碟完全空白，Ghost將使用映像中的引導程式碼作為 MBR 扇區。如果與我們在 QA 實驗室中發現的 ThinkPad 案例一樣，您在沒有額外開關的情況下拍攝了映像，那麼它恢復的扇區會嘗試從引導軌道中的後續扇區載入自身的其餘部分，預設情況下，Ghost 會單獨離開。
因此，您有多種選擇；您可以在還原後使用gdisk /mbr來強制使用標準的“安全”MBR 而不是製造商自定義 MBR，或者您可以在擷取源映像時將**-IB**開關與 Ghost 一起使用以強制 Ghost 對所有扇區進行映像引導軌道，而不僅僅是 MBR。
以上是我們在奧克蘭的實驗室中發現的，我們在那裡開發了 Ghost（直到 2009 年，賽門鐵克關閉了該站點並取消了 Ghost 解決方案套件產品的開發）；我們的 QA 經理 Krish Jayaratne 發現了這一點，並對解決方法進行了主要調查，然後進行了一些檢查以確認是否存在額外的引導程式碼。
雖然您的情況可能不一樣，但聽起來確實與這種情況完全一樣，我懷疑解決方案應該是相同的。我確實在賽門鐵克官方論壇上向客戶介紹了幾次，並且記錄得相當詳盡，但是自從 Ghost 解決方案套件產品被取消後，賽門鐵克失去了有關這些東西的大部分機構知識。
編輯添加：正如我上面提到的，如果存在現有的 MBR，預設情況下，“正常”圖像的 Ghost 恢復會將 MBR 中的引導程式碼完全單獨保留。但是，如果使用**-IB開關來擷取圖像，則事實將被記錄為圖像文件元數據的一部分（事實上，相當多的開關都是如此；部分混淆文件頭具有很大的’ol 位數組從全域變數中填充 - 是的，真的 - 參數解析器將命令行開關提取到其中）。因此，使用-IB**拍攝的圖像不僅具有細微不同的結構來容納額外的引導扇區，而且程序的恢復端“知道” -IB用於拍攝圖像。
我對這個過程的回憶（雖然我沒有原始碼來確認它）是如果**-IB**用於擷取映像，預設情況下，將始終恢復引導程式碼和額外的引導扇區，從而使恢復過程具有與正常映像相反的引導程式碼的預設處理。其背後的部分邏輯是恢復 UI 沒有將引導程式碼儲存在圖像中的可選容器中 - 您無法表達是否輕鬆恢復它的選擇（添加有點可用性的複雜性；如果人們不理解 UI 的含義，那麼 UI 永遠不會是“免費的”）。另一個是 Ghost 的一些最重要的使用者是電腦製造商，他們為他們的 OEM 恢復磁碟授權。如果電腦製造商的工廠恢復映像由於某種原因包含自定義啟動程式碼，那麼通常預設情況下它們’也暗示恢復行為的細微差別似乎是“正確的”預設值。
對於這些奇特的特殊情況，決定是讓極其複雜的命令行更加複雜還是添加新的 UI 以使事情更加明確，與大多數人預設嘗試做“正確的事情”，這總是一個微妙的平衡行為人，而不是使預設 UI 變得複雜。毫無疑問，我們並不總是選擇正確，但我們確實總是為這種平衡而苦惱，特別是因為我們有數百萬客戶擁有我們不想破壞的腳本。