Структура разделов GPT в Windows 8

Метки:  , , , , , , ,

В процессе движения в сторону изучения структуры разделов GPT в Windows 8, в какой-то момент наметилась необходимость детально рассмотреть принципы формирования структуры разделов на физическом носителе. Хочется понять, как формируется структура разделов GPT в Windows 8, какие именно разделы создает операционная система на этапе инсталляции, как она их размещает на пространстве физического носителя (диска), какие данные ОС хранит в тех или иных разделах, каким образом она использует разделы в процессе работы? Эти, а так же некоторые другие вопросы и призвана осветить (я на это в какой-то мере надеюсь) данная статья.
С чего же нам начать? С выбора платформы. Поскольку я не имел под рукой, на момент написания материала, никакого дополнительного аппаратного обеспечения, то и решил остановить свой выбор на виртуальной среде. Для полноты эксперимента, было бы корректно выбрать новую модель какого-нибудь ноутбука, по той лишь причине, что производители подобных устройств часто дополнительно размещают на носителях разделы, содержащие образы для восстановления ОС. Очевидный плюс данного подхода в том что мы имеем дополнительный раздел со специфическим ПО от производителя, которое необходимо для восстановления ОС в "исходное" состояние. Но, поскольку у меня и этой возможности не представилось, то я просто решил выполнить новую, "чистую" инсталляцию Windows 8 на имевшуюся в наличии виртуальную машину. Быть может, в будущем удастся дописать в эту статью недостающую информацию.
Изначально я хотел найти диск объемом более 2Тб, с целью проверить некоторые мои предположения, но, к сожалению, мне не удалось найди подобный носитель, а делать программную эмуляцию столь большого объема в VMWare не было ни малейшего желания.

Эксперимент будет производиться на следующей конфигурации:

  • VMWare ESXi v5.5.0 build 1331820.
  • Виртуальная машина VMWare: с диском объемом в 32Гб. (Thick Provision Eager Zeroed), то есть диск "занулен" при создании (записаны нули по всему пространству).
  • Boot options заданы в EFI. Тем самым мы исключаем вариант использования MBR разметки.
  • Windows 8.1 update 1 - x64 Профессиональная. Русская. версия 6.3.9600.

Мой выбор не случайно остановился на 64-разрядной версии Windows 8. Для себя я объяснил его довольно просто - 64-битная версия Windows сейчас является "вытесняющей" конфигурацией на рынке ПО, то есть наблюдается тенденция перехода на данную разрядность все большего и большего числа пользователей. Не спорю, что и 32-битная версия Windows 8 умеет прекрасно работать с GPT как на загрузку так и на хранение данных, однако будет придерживаться "мейнстрима".

С целью получения именно типовой структуры разделов GPT в Windows 8, в процессе инсталляции (на этапе разметки диска) мы оставляем всё "как есть" и выбираем довольно часто используемую пользователями схему разметки - используем все доступное пространство без ручного разбиения на разделы:

Установка Winsows 8 на GPT раздел

После этого продолжаем установку ОС, даем необходимые ответы на вопросы по параметрам и завершаем инсталляцию ОС. После финальной перезагрузки мы получаем на нашей виртуальной машине новую, девственно-чистую ОС Windows 8.1.
Теперь, при старте, Вы можете залогиниться в систему под своей учетной записью. Теперь, мы выберем традиционный и самый доступный метод для изучения структуры разделов Windows 8 - оснастку "Управление дисками" Для этого щелкнем правой кнопкой мыши по значку "Этот компьютер" и выберем пункт "Управление", затем запустим оснастку "управление дисками".
На скриншоте ниже можно увидеть типичную разметку диска на разделы:

GPT разделы Windows 8

В этой оснастке мы наблюдаем три раздела, которые были созданы на этапе инсталляции Windows.
Однако, имея некоторый опыт общения с продуктами MS, не будем делать скоропалительных выводов не о количестве, ни о содержимом разделов.
Для подтверждения структуры разделов GPT в Windows 8 нам потребуется дополнительная проверка. Попробуем перепроверить и подтвердить полученную информацию с помощью утилиты diskpart:

Во-первых, с помощью утилиты diskpart мы можем удостовериться, что действительно сделали всё правильно, не ошиблись с режимом загрузки и имеем дело с разметкой GPT: на это указывает значок звездочки (*) напротив записи о диске в столбце GPT.
Во-вторых, разделов на единственном установленном в системе диске оказалось, по какой то причине, четыре?! Вот и верь после этого MS с их высокоуровневыми средствами работы с диском.. Как же так? В оснастке "управление дисками" мы видели всего-навсего три раздела, а diskpart показал четыре? До конца пока не разобрался в ситуации, но могу предположить, что раздел MSR (Microsoft System Reserved) имеет характеристики (GUID), на основе которых ОС (либо код утилит работы с дисками) скрывает его из оснастки "управление дисками". При анализе через низкоуровневые утилиты, выяснилось, что кроме GUID MSR и названия, раздел не содержит каких-либо специфических атрибутов, которые можно было бы отслеживать. Можно попробовать вручную, с помощью редакторов диска, преобразовать раздел MSR в обычный базовый, при этом не забыв поправить контрольную сумму в заголовке GPT, и посмотреть, появится ли он в оснастке "управление дисками".
Сам стандарт GPT не позволяет скрывать от пользователя разделы, поэтому MS использует для разделов "Системный" и "Восстановление" пользовательские атрибуты в битах 48-63 параметра атрибутов раздела GPT и сама же их и обрабатывает, что позволяет блокировать некоторые пользовательские действия с данными разделами через высокоуровневую оснастку "Управление дисками".
На основе все вышеизложенного, мы удостоверились в том, что оснастка "управление дисками" скрывает от нас массу полезной информации. Напрашивается логичный вывод:

Для работы с дисками настоятельно рекомендуется использовать утилиту diskpart. Утилита diskpart всегда показывает актуальную информацию, вне зависимости от атрибутов разделов.

Итого, на диске после инсталляции Windows 8 присутствует четыре раздела, которые выглядят следующим образом (и следуют в том же порядке):

  1. Раздел восстановления. Размер 300Мб.
  2. Системный (шифрованный EFI) раздел. Размер 99Мб.
  3. Зарезервированный раздел. Размер 128Мб.
  4. Основной раздел. Размер - оставшееся место.

В стандартной инсталляции структура разделов GPT Windows 8 содержит четыре раздела. Однако, на некоторых предустановленных заводских конфигурация (в которые входят большинство ноутбуков), можно увидеть дополнительные разделы производителя оборудования.

Далее перед нами встает задача попытаться изучить содержимое данных разделов. Для решения этой задачи, нам надо добраться до файловых систем, размещенных на разделах. Тут на ум приходит, как минимум, два явных способа достижения цели:

  1. Нетривиальный: использовать сторонние утилиты для просмотра содержимого раздела;
  2. Тривиальный: попробовать просмотреть разделы в самой Windows, назначив буквы разделам с помощью системных утилит. Затем получить доступ к данным напрямую из утилит пользовательского уровня;

Для этой цели мы будем использовать уже полюбившуюся нам утилиту diskpart. Выполним команды в приведенной последовательности:

В показанном выше примере описана процедура назначения имени одному из разделов. Используйте подобный алгоритм для назначения букв всем разделам, предварительно переключая разделы командой "select partition N", где N - номер требуемого раздела из таблицы. В нашем случае мы должны назначить буквы первым трем разделам: Раздел 1, Раздел 2, Раздел 3. Смысла сопоставлять букву последнему, четвертому разделу "Раздел 4" нет, поскольку она уже назначена и мы видим его в системе в виде диска C:.

В процессе назначения имен у меня случился казус. По непонятной мне пока причине не удалось назначить букву разделу под номером 3 (MSR, Зарезервированный). diskpart выдает ошибку: "Указанный том не существует. Выберите том и повторите попытку". Вероятно, это связано с тем, что MSR разделу в стандарте GPT не сопоставлена файловая система.

После всех указанных манипуляций, список томов у меня лично выглядел следующим образом:

Скрытые GPT разделы Windows 8

Как Вы наверняка уже заметили, изучив рисунок, в системе появилось два дополнительных диска, ранее отсутствовавших, это X: и Y:. С этого момента их содержимое стало доступно утилитам пользовательского уровня. Проще говоря, изучить информацию на этих томах можно всеми теми утилитами, к которым Вы уже успели привыкнуть. Существует лишь одна рекомендация с моей стороны, позволяющая исключить появление непредвиденных ошибок:

Открытие вновь подключенных дисков следует производить из-под учетной записи, имеющей привилегии администратора.

Сам я тоже провел изучение информации, находящейся на служебных разделах, и теперь предоставлю свои выводы в виде списка.

Раздел восстановления

Содержит среду восстановления, которая может потребоваться в случае возникновения различного рода проблем. Вызывается по клавише F8 при старте Windows. Имеет размер ~300Мб. Раздел закрыт от простого пользователя с целью защиты от этого самого пользователя.

Содержимое раздела восстановления:

Непосредственно сама среда восстановления размещается в стандартном образе формата wim - winre.wim. Два других файла являются сопутствующими и предназначены для подготовки запуска среды.
Давайте рассмотрим каждый из файлов подробнее:

Файл Описание
boot.sdi Microsoft System Deployment Image (SDI) - специализированный миниобраз загрузки среды. Загрузчик (bootmgr/bootmgfw) смотрит BCD, видит запись о boot.sdi, загружает boot.sdi в память, создавая из него импровизированный виртуальный диск (RAMDISK). Boot.sdi - это фактически образ диска NTFS (состоит из заголовка SDI и самого NTFS раздела). Загрузчик монтирует данный NTFS раздел, затем код загрузчика считывает с раздела восстановления ассоциированный в BCD с файлом boot.sdi (RAMDISK) файл winre.wim и отображает его в созданный в памяти на виртуальном диске NTFS раздел.
ReAgent.xml Файл параметров утилиты reagentc.exe, которая предназначается для "регистрации" расположения среды восстановления и задания различных опций, а так же копирования winre.wim из системы на раздел восстановления.
Winre.wim Сжатый образ раздела восстановления. Содержит набор утилит, которые вместе взятые и представляют собой среду восстановления.

Шифрованный (EFI) системный раздел

Очень странно, что в названии данного раздела присутствует определение "шифрованный", ведь с этого раздела начинается загрузка ОС после стадий UEFI. В случае, если бы раздел был действительно зашифрован, UEFI должна была знать как именно его расшифровать с целью считать файлы загрузки, а ничего подобного до сих пор в коде загрузчиков я никогда не наблюдал. На некоторое время это обстоятельство ввело меня в замешательство, ведь я свободно наблюдал содержимое "зашифрованного" раздела. Можно было бы объяснить это явление тем, что Windows расшифровывает раздел в процессе работы, а не виден он только лишь из сторонних утилит при отключенном диске. Однако все эти догадки были отбракованы после того, как я случайно увидел английский вариант именования раздела: "EFI System Partition", что более известно нам под сокращением ESP. Очевидно, что никакого упоминания о шифровании нигде в английской версии не встречается.

В русской версии Windows 8 в названии "Шифрованный (EFI) системный раздел" имеется ошибка перевода. Оригинальное английское название - "EFI System Partition".

Данный раздел уже известен нам по Windows 7 и предназначается для размещения файлов начального этапа загрузки операционной системы (Bootmgr/BCD) и файлов, обеспечивающих функционирование технологии BitLocker Drive Encryption.
Содержимое ESP (большое дерево):

Размер ESP динамический и варьируется от минимума в 1% ёмкости накопителя (или 100 Мбайт) до максимума в 1000 Мбайт. Используется файловая система FAT, хотя по спецификации стандарт UEFI позволяет использовать и файловые системы FAT12, FAT16, FAT32.
Теперь давайте посмотрим, что представляют из себя файлы раздела:

Файл Описание
\EFI\Microsoft\Boot\BCD Хранилище данных конфигурации загрузки. Файл является копией куста реестра HKEY_LOCAL_MACHINE\BCD0000000x. Состоит из объектов, которые имеют идентификаторы GUID. Каждый из объектов представляет из себя структуру, которая описывает элемент меню загрузки. Фактически, данные объекты представляют собой отображаемые и не отображаемые элементы меню загрузки и параметры этих элементов: разделы, на которых они находятся, файлы, которые будут загружаться. Диспетчер загрузки bootmgfw/bootx64 обрабатывает данную структуру и выполняет в соответствии с её пунктами дальнейшую загрузку.
\EFI\Microsoft\Boot\boot.stl Список доверия сертификатов. Certificate trust list (CTL). Утвержденный список элементов, подписанных удостоверяющим центром, то есть доверенным источником. Все элементы в списке проверяются и утверждаются удостоверяющим центром. Список элементом может быть чем угодно, например, списком хешей сертификатов или списком имен файлов, или же списком доверенных центров сертификации для определенного сайта.
\EFI\Microsoft\Boot\bootmgfw.efi Firmware Boot Manager. Менеджер загрузки Windows (Windows Boot Manager) в формате EFI для большинства реализаций UEFI. Файл получает управление только тогда, когда в коде UEFI-прошивки реализован алгоритм поиска данного файла, а начиная с UEFI 2.3.1+ подобное поведение описано в спецификации. Спецификация подразумевает использование поддиректории вендора (в нашем случае \EFI\Microsoft\), в которой располагаются модули загрузки ОС (bootmgfw.efi). Поэтому файл bootmgfw.efi может использоваться как загрузчик по-умолчанию вместо bootx64.efi или совместно с ним. Соответственно, идентичен до байта файлу \EFI\Boot\bootx64.efi. При получении управления, bootmgfw.efi считывает конфигурацию загрузки BCD и загружает \Windows\System32\winload.efi с раздела, который с ним сопоставлен.
\EFI\Microsoft\Boot\bootmgr.efi Еще один Менеджер загрузки Windows (Windows Boot Manager) в формате EFI. Этот файл не получает управления из загрузчиков bootmgfw.efi / bootx64.efi при загрузке с жесткого диска. Вообще остается загадкой, при каких обстоятельствах данный файл используется. Могу предположить, что он использовался в прошлом в "кривых" реализациях UEFI получал управления прямо из прошивки, либо прекратил применяться с определенной ревизии ОС (но зачем его оставили?), получает управление при загрузке с CD/DVD (?). Теряюсь в догадках, однако могу предположить, что код выполняется при каких-либо нестандартных сценариях загрузки. Необходимо исследование!
\EFI\Microsoft\Boot\xx-XX\*.mui Файлы ресурсов одноименных программ, содержащие текст локализации интерфейса основной программы на соответствующем языке.
\EFI\Microsoft\Boot\Fonts\*.ttf Шрифты формата TTF. Применяются в меню загрузки.
\EFI\Microsoft\Boot\Resources\bootres.dll Ресурсная DLL для кода стадии загрузки. Содержит код (функции) и данные (секции ресурсов) с графическими логотипами загрузки.
\EFI\Boot\bootx64.efi Является "default boot loader" или "fallback boot loader", то есть загрузчиком по-умолчанию для архитектуры x64 в формате EFI. Получает управление, если EFI NVRAM переменная "BootOrder" не задана, выполняется загрузка с переносного устройства, либо по какой-то причине были стерты (сбились) установки в NVRAM, определяющие порядок загрузки. Подобное поведение прошивки UEFI описано в спецификации, то есть код UEFI ищет стандартную директорию на носителе в партиции EFI System Partition (ESP): \EFI\Boot и стандартное имя файла загрузчика: boot<имя_архитектуры>.efi. Идентичен до байта файлу \EFI\Microsoft\Boot\bootmgfw.efi.

Приложение или драйвер в формате EFI - это обычный файл формата Windows PE DLL, у которого в заголовке задано специфическое значение поля "Subsystem". Введены три новых значения (в десятичной системе счисления): EFI приложение = 10, EFI драйвер этапа загрузки = 11, EFI драйвер режима выполнения = 12. Формат EFI PE DLL не имеет привычных нам секций таблиц символов, таблиц экспорта, таблиц импорта и прч. В остальном структура исполнимого файла идентична.

Microsoft размещает копии менеджеров загрузки в обеих местоположениях, где они могут загружаться: в дереве вендора (\EFI\Microsoft\Boot\) и в дереве загрузки по-умолчанию (\EFI\Boot\). Сделано это для того, что бы быть уверенным, что загрузка ОС пройдет в любой случае, и в случае слетевших установок NVRAM и в случае нормального процесса.

Зарезервированный раздел

Зарезервированный раздел Microsoft. Microsoft Reserved Partition (MSR). Одно из назначений раздела - использование в случае преобразования типа диска (простой-динамический).

Поскольку спецификация UEFI в структуре GPT не позволяет резервировать пространство между разделами для нужд ОС, Microsoft использует для этих целей специализированный раздел MSR.

Представляет из себя невидимый в обычной оснастке "управление дисками" раздел, который используется для нужд операционной системы. Не сопоставлен с какой-либо файловой системой. Одно из назначений раздела - использование в случае преобразования типа диска (простой-динамический). В случае конвертирования диска базового (простого) в динамический, система уменьшит размер MSR и на освободившемся пространстве создаст новый раздел, на котором разместит базу динамического диска. Как вычисляется размер MSR?

Основной раздел

Basic data partition (PatititonTypeGUID раздела равен EBD0A0A2-B9E5-4433-87C0-68B6B72699C7). Основной раздел данных. Раздел, на который была произведена инсталляция ОС Windows (у нас в системе он виден как диск C:). Содержит полную структуру каталогов ОС: Program Files, Program Files (x86), ProgramData, System Volume Information, Windows, Users(Пользователи), то есть все данные ОС. Поскольку раздел основной и системный, то и отформатирован он исключительно в файловой системе NTFS. Однако, разделы типа "Basic data partition" (основные разделы) могут содержать не только файлы ОС, этим типом маркируются все вновь созданные через оснастку "Управление дисками" разделы. Разделы этого типа могут содержать файловые системы FAT32/NTFS.

Раздел Push Button Reset

Необязательный скрытый раздел, предназначенный для восстановления системы в исходное "заводское" состояние через алгоритм под названием «Push Button Reset» (вольный перевод: сброс состояния одной кнопкой). Технология позволяет удалить текущую установленную Windows 8 и восстановить чистую, заводскую копию всего за несколько минут. Обычно создается на ноутбуках/моноблоках. В нашем случае отсутствует. Хранит данные для восстановления. Размер достаточно большой, 15-20Гб.

Выводы

Ну вот, мы подошли уже к концу нашего небольшого эксперимента, бегло изучив структуру разделов GPT в Windows 8. Удалось выяснить, что инсталлятор Windows 8, работающий в системе с UEFI, в ходе процесса установки, в случае типовой разметки, создает несколько GPT разделов (перечислены в порядке физического размещения на носителе):

  1. Раздел восстановления. Размер 300Мб. Содержит среду восстановления.
  2. Шифрованный EFI системный раздел. Раздел EFI System Partition (ESP). Содержит загрузчик и другие необходимые для загрузки системы данные, такие как хранилище конфигурации загрузки (BCD), bootx64.efi и прочее. Может содержать файлы, используемые технологией BitLocker. ESP занимает примерно 1% от ёмкости жёсткого диска или минимум 100 Мбайт и максимум 1000 Мбайт. Файловая система FAT.
  3. "Невидимый" раздел восстановления. MSR. Имеет обозначение Microsoft Reserved. Этот раздел используется для нужд операционной системы. К примеру, раздел используется в случае преобразования типа диска (простой-динамический).
  4. Основной раздел. Используется для размещения файлов операционной системы.
  5. Раздел Push Button Reset. Содержит данные для восстановления операционной системы в заводское состояние.
  • Поделиться:

15 комментариев:

  1. Виталий

    Спасибо Вам! Очень интересная статья! Мне ещё не доводилось встречать такую подробную информацию.
    В связи с этим хотелось бы спросить у Вас: как Вы получили доступ к ESP-разделу? Я пытался сделать следующее: назначил букву разделу утилитой DiskPart, а дальше, при попытке открыть, мне было отказано в доступе. Хотел изменить владельца с предоставлением полного доступа, но вкладки "Безопасность" в свойствах тома нет. Для чего это мне нужно? Ну, во-первых, интересно сравнить дерево ESP из Win8 со своим, из десятки. А во-вторых, у меня проблема с созданием полной резервной копии, не проходит теневое копирование ESP - пишет то же самое: "Отказано в доступе". Вот и ищу различные варианты решения этой проблемы. На трёх форумах никто пока не смог помочь, "ковыряюсь" сам.

    • einaare

      Приветствую!
      Помню, что-то такое под Win8 видел, кажется, проблема была в правах explorer.exe
      А Вы всё это на Windows 10 пытаетесь проделать? Признаюсь, что до Windows 10 я еще не добрался. Общие рекомендации:
      1. Проверьте учетку, из-под которой выполняете все действия. Права локального администратора есть?
      2. Включен ли UAC?
      3. На совсем уж крайний случай можно загрузиться с liveCD и попробовать аккуратно поработать с диском из-под неё.
      4. Попробуйте запустить проводник принудительно через runas (или с шифтом) от имени локального администратора. А уже с этим проводником зайти на диск.
      Вполне возможно, в Windows 10 имеется дополнительная защита системных разделов. Надо смотреть! Вполне возможно, что там "простая" защита на уровне GPT параметров доступа к разделу.

      • Виталий

        Добрый вечер!
        Да, на 10-ке.
        1. Полный администратор
        2. Отключён
        3. Из-под WinRE или WinPE? Или без разницы? С LiveCD ни разу не работал - не довелось :-)
        С помощью DISM (или DiskPart) возможно получить доступ? Я, если честно, слабо это себе представляю, не
        такой уж продвинутый пользователь.
        4. По поводу защиты на уровне GPT параметров доступа к разделу - сталкивался при обнулении диска: DMDE "спотыкалась" об системные разделы, приходилось DiskPart > sel dis # >clean и только потом забивать нулями (весь SSD отдан под Win10, работал из Win8.1, установленной на HDD).
        Пробовал запустить проводник с Shift - результат тот же самый
        [URL=http://radikal.ru/fp/4c088580c463468f895d726dccbb7e65][IMG]http://s017.radikal.ru/i434/1509/c2/758564ce1304t.jpg[/IMG][/URL]
        Сейчас пришла в голову мысль: а не попробовать ли попасть в этот раздел из-под Win8.1? Сейчас попытаюсь

        • einaare

          Как вариант. Скорее всего ограничения на уровне прав. Отпишите, если не сложно, получилось ли под Win8.1?

    • Владимир

      Задачу просмотра скрытых разделов в Win10 удаётся решить без проблем доступа если на компе установлена кроме Win и Win7 (установлена на другом физическом диске). Вот используя её мне удалось открыть все эти разделы в Win10. К сожалению, в самой Win10 эту задачу пока не решил - проблема с доступом.

      • einaare

        Странно ведь. У меня создалось устойчивое ощущение, что я подобную ошибку видел и в Win8, и точно помню, что мне удалось каким-то образом её решить именно без сторонней винды. Вот только не помню каким :)

        • Виталий

          Можно и из самой Win10 (единственной установленной на компе) просмотреть содержимое EFI-раздела при наличии полного бэкапа системного диска: подключив из папки архива системы виртуальный EFI-диск в диспетчере дисков. У меня это получилось в 10-ке. А открыть непосредственно EFI-раздел не помогли никакие "танцы с бубном": ни запуск проводника с правами админа, ни смена владельца раздела с получением полного доступа, ни из-под Win8.1

  2. Виталий

    Попробовал, не получилось
    http://s017.radikal.ru/i434/1509/c2/758564ce1304.png
    Если Вам будет интересно, то моя проблема по архивации описана здесь:
    http://forum.oszone.net/showthread.php?p=2543585#post2543585
    А чтобы не было офтопа, скажу, что для Win 8.1 я создавал при установке раздел восстановления partition1 Recovery размером 350 МБ (при 300 МБ создание резервного образа системы завершалось ошибкой - не хватало свободного места (<50МБ)), а после установки проверял состояние среды восстановления командой reagentc /info

    • einaare

      А, так проблема шире, чем просто недоступность ESP раздела? Все с архивации началось, и с отказа с ошибкой? Почитал топик. А какие диски у Вас в живой системе установлены? Я так понимаю, если бэкап прошел на Hyper-V на виртуальной винде, но не прошел на живой, надо смотреть разницу в дисках, может быть какое-то свойство мешает разделу пробекапиться? Вполне возможно, диск маркируется как "съемное устройство" или что-то вроде этого и не хочет, по этой причине, бекапиться из-за каких-либо параметров в системе?

    • einaare

      Опишите подробнее Вашу конфигурацию, пожалуйста!! Какие диски стоят в системе и откуда куда делается бэкап? Вы делали апгрейд до Win10? тест

      • Виталий

        einaare,
        Решил и у Вас в блоге оставить результаты наших экспериментов. Всё-таки проблема касается разметки GPT, a не 10-ки либо 8-ки. Да и недосказанность в обсуждении здесь оставлять не хочется.
        Всё дело в том, что две ОСи были установлены на физические диски в разметке GPT, и, соответственно, два EFI-раздела мешали друг другу при первичном создании полной резервной копии. Отсюда и успешное резервное копирование OS, установленной на диске в разметке MBR, так же как и OS, установленной на виртуальной машине.
        Решение: физическое отключение диска со второй ОСью от мат.платы (я просто отключал питание от диска), и первичная полная резервная копия создалась без проблем. В дальнейшем отключения дисков не требуется – повторное (инкрементное) копирование идёт без ошибок.
        Огромнейшее СПАСИБО за направление на верный путь!

  3. Bogdan

    Здравствуйте! Планирую Windows 8.1 на ноутбуке Samsung NP300E5C-S0JRU обновить до 10, а потом сделать чистую установку. До чистой установки - удалить ненужные разделы, а нужные оставить. Нужные - раздел D (музыка, файлы), раздел REC - 1024 МБ (где программа Samsung Recovery-для создания образов системы). Ненужные - раздел С, Windows RE, еще один раздел REC (где заводской образ Windows 8). А что делать с этими разделами: EFI и MSR? Дело в том, что мне нужно сохранить заводскую утилиту Samsung Recovery-для создания образов. Да, я сохранил раздел, где именно она хранится. Но если я удалю EFI и MSR будет ли она работать при нажатии F4, нет ли у нее какого-то связанного запуска с этими 2 разделами. Или Samsung привязал запуск программы Recovery к F4 каким-то другим способом (интересно каким) и эти разделы можно удалить?

    • einaare

      Здравствуйте!! Вы знаете, конкретно с этой моделью я дела не имел, не знаю специфики, так сказать.. однако, могу порекомендовать Вам не трогать EFI раздел при переустановке ОС. Я так понимаю, по F4 вызывается обыкновенный UEFI модуль, который ищет в разделе EFI директорию вендора (Samsung) и передает управление загрузчику на ней. Поэтому, MSR можно удалить, поскольку новая инсталляция его может создать заново, а вот EFI не трогайте. Мои слова можете подтвердить просто посмотрев структуру EFI и убедившись в наличии директории производителя ноутбука (Samsung), ну либо опровергнуть, если её там нет :)

      • Bogdan

        Спасибо! Да скорее всего в EFI есть папка Samsung. Убедится в этом не удалось так как система информирует что нет доступа. Думаю можно организовать обходной путь загрузки. Судя по содержимому раздела с утилитой - там находятся файлы Windows PE и программы Recovery. То есть можно попробовать добавить Windows PE в загрузочное меню Windows - прописав путь к файлу install.wim, а далее - при загрузке в Windows PE запустить программу Recovery. Или скопировать все на флэшку - и запускать с нее. Но это теория... Если все будет работать остается вопрос: привязав вот так напрямую загрузку к файлу install.wim - не сработает какой-то запрограмированный сценарий восстановления?...

        • einaare

          Мне показалось, что Вы пытаетесь перестраховаться, изобретая столь сложные способы загрузки :) Я вот думаю, что файл install.wim просто так напрямую не загрузишь, он же вроде как обрабатывается с помощью sdi-загрузчика, то есть придется еще править дополнительные конфигурационные файлы в корне. Но а так идея интересная, можно попробовать подсунуть install.wim вместо .wim, который примаплен по-умолчанию. В такой ситуации никаких проблем быть не должно.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *