Мигает курсор при загрузке восстановленного изображения Ghost

К сожалению, этот вопрос только что появился сегодня в моем RSS-ридере, поэтому, хотя ему и исполнилось пару лет, я подумал, что предложу правильный ответ для будущих читателей.

Я не знаком с конкретной моделью, которую вы описали как затронутой, но это звучит довольно похоже на проблему, которая возникла в некоторых моделях ThinkPad (моя память говорит T60), которые использовали нестандартную многосекторную MBR, которая занимала несколько секторов загрузочный трек, а не обычный, с результатами, идентичными тому, что вы описываете.

Классический формат изображений Ghost до введения ключа -IB хранил только оригинальный единственный сектор MBR; это означает, что образы систем, которые на самом деле содержат нестандартный многосекторный контент дорожки загрузки, содержат только половину необходимого загрузочного кода.

Почти во всех ситуациях, когда исходный образ не был взят с помощью ключа -IB, если Ghost обнаруживает загрузочный код на целевом диске, на который вы восстанавливаете, он имеет тенденцию оставлять исходный загрузочный код нетронутым и просто манипулирует таблицей разделов в загрузочном секторе., Это сделано для того, чтобы иметь дело с системами, которые использовали специальный загрузочный код (например, системы с хуками загрузочного сектора для замены BIOS), и означает, что в большинстве случаев, если целевой системе нужен такой пользовательский загрузочный код, ее оставляют в покое и будет продолжать загрузку.

Однако, если целевой диск полностью пуст, Ghost будет использовать загрузочный код из образа для сектора MBR. Если, как и в случае ThinkPad, который мы обнаружили в наших лабораториях контроля качества, вы взяли образ без дополнительных переключателей, то сектор, который он восстанавливает, пытается загрузить оставшуюся часть себя из более поздних секторов в дорожке загрузки, которые по умолчанию Ghost оставляет в покое.

Итак, у вас есть несколько вариантов; вы можете использовать gdisk / mbr после восстановления, чтобы принудительно использовать стандартную "безопасную" MBR вместо настраиваемой MBR производителя, или вы можете использовать ключ -IB с Ghost при захвате исходного изображения, чтобы заставить Ghost отображать все сектора в загрузочный трек, а не только MBR.

Вышесказанное - это то, что мы обнаружили в наших лабораториях в Окленде, где мы разрабатывали Ghost (до 2009 года, когда Symantec закрыла сайт и отменила разработку продукта Ghost Solution Suite); Криш Jayaratne, который был нашим менеджером по контролю качества, обнаружил это и провел основное расследование в отношении обходных путей, а затем он провел небольшую проверку, чтобы подтвердить наличие дополнительного загрузочного кода.

Хотя ваша ситуация может не совпадать, это, безусловно, звучит точно так же, и я подозреваю, что решение должно быть таким же. Я несколько раз проходил через клиентов на официальных форумах Symantec, и это было довольно тщательно задокументировано, но поскольку продукт Ghost Solution Suite был отменен, Symantec утратила большую часть институциональных знаний в этой области.

Изменить, чтобы добавить: как я уже отмечал выше, Ghost при восстановлении по умолчанию для "обычных" образов оставляет загрузочный код в MBR полностью одним, если присутствует существующий MBR. Однако, если ключ -IB был использован для захвата изображения, этот факт записывается как часть метаданных файла изображения (на самом деле, это справедливо для довольно многих ключей; часть обфусцированного заголовка файла имеет большой в нем есть битовый массив, заполненный глобальными переменными - да, действительно, - в которые анализатор аргументов извлекает переключатели командной строки). Таким образом, не только изображения, снятые с -IB, имеют слегка различную структуру для размещения дополнительных загрузочных секторов, сторона процесса восстановления "знает", что -IB использовался для получения образа.

Мое воспоминание о процессе (хотя у меня больше нет исходного кода для его подтверждения) таково, что если бы -IB использовался для захвата образа, по умолчанию загрузочный код и дополнительные загрузочные секторы всегда будут восстанавливаться, делая Процесс восстановления имеет обработку по умолчанию, противоположную загрузочному коду для обычных образов. Часть логики заключается в том, что в интерфейсе восстановления нет загрузочного кода, хранящегося в образе в выбираемом контейнере - у вас нет способа выразить выбор, восстанавливать его или нет (добавив, что быть немного усложненным юзабилити; пользовательский интерфейс никогда не бывает "бесплатным", если люди не понимают, что это значит). Другое - некоторые из наиболее важных пользователей Ghost были производителями компьютеров, которые лицензировали его для своих дисков восстановления OEM; если по какой-либо причине заводской образ восстановления изготовителя компьютера содержал пользовательский загрузочный код, то обычно по умолчанию они хотели бы его вернуть, и наличие -IB также подразумевает, что небольшая разница в поведении при восстановлении выглядит как "правильное" значение по умолчанию.

Это было всегда деликатное уравновешивание с этими причудливыми особыми случаями, решающими, следует ли сделать изощренно сложную командную строку еще более сложной или добавление нового элемента пользовательского интерфейса, чтобы сделать вещи более явными, по сравнению с попыткой сделать "правильную вещь" по умолчанию для большинства люди и не делают интерфейс по умолчанию сложным. Нет никаких аргументов в пользу того, что мы не всегда выбирали правильно, но мы всегда мучались из-за этого баланса, тем более что у нас были миллионы клиентов со скриптами, которые мы не хотели нарушать.