Я создаю сценарии автоматического развертывания для универсальных образов рабочих станций и обнаружил то, с чем не могу работать. Я надеюсь, что кто-то еще сталкивался с этим раньше, и я просто неправильно ищу, или что я упускаю что-то явно очевидное через 16 часов.
Окружающая среда:
Кажется, что всякий раз, когда целевой диск полностью пустой; после восстановления и перезагрузки я застрял с бесконечно мигающим курсором в верхнем левом углу.
Я подробно расскажу о сценариях, которые я пробовал до сих пор, в надежде, что кто-то увидит что-то, что я пропустил.
(В каждом из них загрузочный носитель для WinPE - это USB-накопитель (который загружает WinPE в RAM @ X :), а целевой жесткий диск - это внутренний SATA 74 ГБ)
Изменить: я подумал, что Diskpart может быть проблемой, и повторил их, используя Gdisk32, чтобы завершить операции с диском без изменения результата.
(На целевом диске есть рабочий загрузочный первичный раздел NTFS Windows XP, занимающий весь диск.)
Запускаю Diskpart, выбираю диск (0) и CLEAN Это. (Если оставить этот шаг, результаты будут те же.)
Затем я запускаю ghost32.exe, перехожу на локальный диск из образа и выбираю свое изображение, ориентируясь на диск 0.
Все работает, как запланировано, система загружается, запускается sysprep, мы в порядке.
(продолжение сверху)
Снова загрузитесь в WinPE. Запустите Diskpart, выберите диск 0 и CLEAN Это. Перезагрузите систему обратно в WinPE.
(Я проверил, что диск 0 пуст)
Я запускаю ghost32.exe, как указано выше, и восстанавливаю диск из образа.
Мигающий курсор без конца.
Если я перезагружусь в WinPE и снова восстановлю его на этом этапе, он будет работать, по сути, так же, как в сценарии 1, только он [не] работал до этого.
(думая, что это может иметь какое-то отношение к назначению буквы диска в WinPE и изменениям, которые Ghost32 может внести на восстановленный диск)
Я загружаюсь в WinPE и CLEAN диск 0, затем перезагрузите снова.
Если целевой диск пуст, исходный диск получает букву диска C: в WinPE. После восстановления вновь созданный раздел получит более позднюю букву (E: в этом случае диск Cd-Rom получает D: [он пуст]).
Загрузился обратно в WinPE; Я вхожу в Diskpart и переназначаю букву исходного диска с C: на W: и выхожу из Diskpart.
Я запускаю ghost32.exe, как указано выше, и восстанавливаю диск из образа.
Мигающий курсор без конца.
(Загрузился, почистил и снова перезагрузился)
Я вхожу в Diskpart и создаю основной раздел на диске 0 (пробовал как RAW, так и отформатировал как NTFS в двух разных попытках).
Я запускаю ghost32.exe, как указано выше, и восстанавливаю диск из образа на вновь созданном разделе.
Мигающий курсор без конца.
(Загрузился, почистил и снова перезагрузился)
Я вхожу в Diskpart и создаю основной раздел на диске 0 размером 10 МБ, неформатированный RAW, а не АКТИВНЫЙ.
Перезагружаю систему обратно в WinPE (источник по-прежнему получает диск C: это единственный отформатированный раздел) Я запускаю ghost32.exe, как указано выше, и восстанавливаю диск из образа. ...
Все работает как задумано, запускается sysprep и открывается рабочий стол.
Зачем вообще нужен раздел на целевом диске во время запуска ОС сборки, чтобы Ghost32 создавал работоспособный восстановленный диск?
Что я здесь делаю не так, я что-то упускаю. Если я восстанавливаю весь диск, почему это имеет значение, что было [точнее; не было] на целевом диске до восстановления. Я должен получить точную копию оригинала, который также был диском 0 и единственным диском в системе.
Любая помощь здесь будет принята с благодарностью, я готов вырвать волосы. Я действительно не хочу, чтобы сценарий создавал необработанный раздел и принудительную перезагрузку при обнаружении пустой цели (что является наиболее вероятным сценарием, когда кто-то восстанавливает рабочую станцию).
Проблема возникает только на ноутбуках HP nc6400. Мне еще предстоит найти другую модель рабочей станции, которая воссоздала бы проблему. Теперь я смог протестировать несколько, и все они демонстрируют одинаковое поведение (к счастью для меня, мы просто сняли все это с поля из-за возраста).
Проблема в том НЕ происходит с использованием того же изображения при загрузке с DVD; Так что, похоже, это связано с исходным СМИ. Я думал, что это может быть способ, которым система обнаруживает USB-накопитель (некоторые рассматривают их как съемные носители, другие как фиксированные диски), но в другой системе, которая была в моем распоряжении, которая позволяла контролировать этот параметр, не показывала то же самое. проблема в любом режиме.
При восстановлении системы с помощью ImageX проблема не возникает, поэтому, похоже, проблема связана с тем, как эта конкретная система обрабатывает USB-накопитель, и с операциями после восстановления, которые выполняет Ghost32.
Можете ли вы нажать F8 во время загрузки и перейти в режим восстановления из командной строки? Если вы попали туда, попробуйте либо FIXBOOT, либо, если это не сработает, запустите CHKDSK / r.
Похоже на ошибку Ghost. Одна вещь, которую я не вижу или может отсутствовать: пробовали ли вы написать сценарий diskpart для очистки, создания, активации и назначения всех сразу?
К сожалению, этот вопрос только сегодня появился в моем 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); Криш Джаяратне, который был нашим менеджером по обеспечению качества, обнаружил это и провел основное расследование в отношении обходных путей, и только тогда потребовалась небольшая проверка, чтобы подтвердить наличие дополнительного загрузочного кода.
Хотя ваша ситуация может быть не такой, это определенно звучит так, как в этом случае, и я подозреваю, что разрешение должно быть таким же. Я пару раз рассказывал клиентам об этом на официальных форумах Symantec, и это было довольно тщательно задокументировано, но с тех пор, как продукт Ghost Solution Suite был отменен, Symantec потеряла большую часть институциональных знаний об этом.
Изменить, чтобы добавить: как я уже отмечал выше, Ghost при восстановлении по умолчанию для "обычных" образов оставляет загрузочный код в MBR совершенно один, если присутствует существующая MBR. Однако если -IB переключатель был использован для захвата изображения, который записывается как часть метаданных файла изображения (на самом деле, это верно для довольно многих переключателей; часть запутанного заголовка файла содержит большой массив битов в нем заполняется из глобальных переменных - да, действительно - в которые парсер аргументов извлекает переключатели командной строки). Так что не только изображения взят с участием -IB имеют несколько иную структуру для размещения дополнительных загрузочных секторов, сторона восстановления процесса "знает", что -IB был использован для получения изображения.
Насколько я помню, этот процесс (хотя у меня больше нет исходного кода, подтверждающего его), заключается в том, что если -IB был использован для захвата образа, по умолчанию загрузочный код и дополнительные загрузочные секторы всегда будут восстанавливаться, в результате чего процесс восстановления будет иметь обратную по умолчанию обработку загрузочного кода по сравнению с обычными образами. Частично логика этого заключается в том, что пользовательский интерфейс восстановления не имеет загрузочного кода, хранящегося в образе в выбираемом контейнере - у вас нет способа выразить выбор, восстанавливать его или нет (добавление этого будет быть немного затруднительным для удобства использования; пользовательский интерфейс никогда не будет «бесплатным», если люди не поймут, что он означает). Во-вторых, некоторые из самых важных пользователей Ghost были производителями компьютеров, которые лицензировали его для своих дисков восстановления OEM; если заводской образ восстановления производителя компьютера по какой-то причине содержал пользовательский загрузочный код, то обычно по умолчанию они хотели бы вернуть его обратно и иметь -IB также подразумевают, что небольшая разница в поведении при восстановлении казалась «правильным» значением по умолчанию.
Это всегда было деликатным уравновешивающим действием, когда эти причудливые особые случаи решали, нужно ли сделать дьявольски сложную командную строку еще более сложной или добавить новый элемент пользовательского интерфейса, чтобы сделать вещи более явными, вместо того, чтобы пытаться сделать «правильную вещь» по умолчанию для большинства люди и не усложняют интерфейс по умолчанию. Нет никаких аргументов в пользу того, что мы не всегда выбирали правильный вариант, но мы всегда мучились из-за этого баланса, тем более что у нас были миллионы клиентов со скриптами, которые мы не хотели нарушать.