Поддерживает ли acronis true image функцию uefi gpt

Обновлено: 04.07.2024

Нет конечно, это же акронис - там все автоматом и без настроек, в том числе и глюки.

Посмотри лучше на продукты TeraByte Unlimited, а именно Image for Linux, там больше возможностей и гибче в настройках + совместим с UEFI. Вся его установку на флешку для UEFI сводится к распаковке образа в корень флешки (она должна быть FAT32).
IFL-GUI.7z
ifl_en_manual.pdf

Сделал так как вы сказали - зависает на

Loading initrmfs.gz .

а вообще по возможности избегай UEFI, потому что кроме неудобств и ограничений он реально ничего полезного не дает.

а вообще довольно странная рекомендация. в силу 1) превращения его в стандарт де-факто; 2) того, что таки он дает много полезного, хотя и не для "ковыряния на коленке".
===
А с акронисом и уефи - стуация довольно странная.
В UEFI загрузка с носителя возможна только:
1) с носителя версии 2013, скачанного с оф.сайта (при этом носитель, создаваемый(!) средствами программы в такой ситуации абсолютно неработоспособен)
2) с носителя версии 2014 по варианту "и так далее".
Причем из недр акрониса получена информация о том, что исправление ошибок в 2013-м не будет больше выполняться - только в 2014-м. немного странная позиция при том, что 2014-й не предоставляется для владельцев 2013-го в качестве апгрейда, но приобретается отдельно за отдельные деньги.
3) ну и с носителей B&R. но мы же не об этом, да. )))

Что там реально полезного для конечного пользователя ?
Возможность установки в раздел более 2тб, кому это реально может понадобится ?

На счет акрониса тут все просто - в 2013 не успели/не смогли реализовать поддержку UEFI для линукс версии и отложили ее до 2014. А что каждая новая версия стоит денег + разделение на серверные/домашние версии, так это политика компании чтоб стричь бабло. Если так нравится акронис 2013 то создавай загрузочный образ на основе WinPE 3.0 x64 или старше. После содержимое образа скопировать в корень FAT32 флешки и можно пользоваться.

Или переходи на TeraByte Unlimited, где весь набор программ стоит 50$, нет деления на домашние/серверные версии, один раз купил и все последующие версии доступны бесплатно. Там есть Image for Linux который используется как загрузочная утилита - поддержка UEFI, Ethernet, USB 3.0, True Crypt, работы с бекапами, разбивка винчестеров, скрипты функционалом аналогичным UR акрониса + свои фишки, файловый менеджер.

Всем привет. В рамках проекта от компании Acronis со студентами Университета Иннополис (подробнее о проекте мы уже описали это тут и тут) мы изучали последовательность загрузки операционной системы Windows. Появилась идея исполнять логику даже до загрузки самой ОС. Следовательно, мы попробовали написать что-нибудь для общего развития, для плавного погружения в UEFI. В этой статье мы пройдем по теории и попрактикуемся с чтением и записью на диск в pre-OS среде.

В компании Acronis команд, которые занимаются UEFI, не так много, поэтому я решил разобраться в вопросе самостоятельно. К тому же есть проверенный способ получить огромное количество точных советов совершенно бесплатно и свободно — просто начать делать что-либо и выложить это в интернет. Поэтому комментарии и рекомендации под этим постом очень приветствуются! Вторая цель данного поста собрать небольшой дайджест статей о UEFI и помочь двигаться в этом направлении.

Полезные ссылки

Для начала хочу перечислить список источников, которые мне очень помогли. Возможно вам они тоже помогут и ответят на ваши вопросы.

В первую очередь это UEFI and EDK II Learning and Development от tianocore. Прекрасно структурированный и иллюстрированный курс, который поможет понять что же происходит в момент загрузки и что такое UEFI. Если вы ищите точную теоретическую информацию по теме, вам туда. Если хочется поскорее перейти к написанию UEFI драйверов, то сразу в Lesson 3.
Статьи на хабре раз, два и три. Автору низкий поклон. Это отличное практическое руководство без лишних сложностей для начинающих. Частично в данной статье я буду цитировать эти шедевры, хоть и с небольшими изменениями. Без этих публикаций, было бы значительно тяжелее начать.
Для продолжающих рекомендую эту статью и другие этого же автора.
Так как мы планируем писать драйвер, очень поможет официальный гайдлайн по написанию драйвера. Наиболее правильные советы будут именно там.
Ну и на крайний случай спецификация UEFI.

Немного теории

Хочу напомнить требования и цели проекта Active Restore. Мы планируем приоритизировать файлы в системе для более эффективного восстановления. Для этого нужно запуститься на максимально раннем этапе загрузки ОС. Для понимания наших возможностей в мире UEFI стоит немного углубиться в теорию о том как проходит цикл загрузки. Информация для этой части полностью взята из этого источника, который я постараюсь популярно пересказать.

UEFI или Unified Extensible Firmware Interface стал эволюцией Legacy BIOS. В модели UEFI тоже есть базовая система ввода-вывода для взаимодействия с железом, хотя процесс загрузки системы и стал отличаться. UEFI использует GPT (Guid partition table). GPT тесно связана со спецификацией и является более продвинутой моделью для хранения информации о разделах диска. Изменился процесс, но задачи остались прежними: инициализация устройств ввода-вывода и передача управления в код операционной системы. UEFI не только заменяет бóльшую часть функций BIOS, но также предоставляет широкий спектр возможности для разработки в pre-OS среде. Хорошее сравнение Legacy BIOS и UEFI есть тут.

В данном представлении BIOS это компонент, обеспечивающий непосредственное общение с железом и является firmware. UEFI это унификация интерфейса железа для операционной системы, что существенно облегчает жизнь разработчикам.

В мире UEFI мы можем разрабатывать драйвера или приложения. Есть специальный подтип приложений — загрузчики. Разница лишь в том, что эти приложения не завершаются привычным нам образом. Завершаются они вызовом функции ExitBootServices() и передают управление в операционную систему. Чтобы принять решение какой же драйвер нужен вам, рекомендую заглянуть сюда, чтобы расширить понимание о протоколах и рекомендациях по их использованию.

Dev kits

Небольшой список того, что мы будем использовать в нашей практике:

(Extensible Firmware Interface Development Kit) — является свободно распространяемым проектом для разработки UEFI приложений и драйверов, которую и мы будем использовать, по началу не сильно в неё углубляясь. — проект облегчающий разработку в Visual Studio. Больше не нужно заморачиваться с .inf файлами и ковыряться в 100500 скриптах на Python. Все это уже сделано за вас. Внутри можно найти QEMU для запуска нашего кода. В проекте представлены примеры приложения и драйверов. — комплексный проект для firmware. Его задача — помочь разработать решение для старта железа и передачи управления в payload (например UEFI или GRUB), который в свою очередь загрузит операционную систему. В данной статье мы не будем затрагивать coreboot. Оставим его для будущих экспериментов, когда набью руку с EDKII. Возможно правильным вектором развития будет Coreboot + Tianocore UEFI + Windows 7 x64.

Последовательность загрузки

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

Ссылка

Процесс с момента нажатия на кнопку питания на корпусе и до полной готовности UEFI интерфейса называется Platform Initialization и делится он на несколько фаз:

Security (SEC) — зависит от платформы и процессора, обычно реализована ассемблерными командами, проводит первоначальную инициализацию временной памяти, проверку остальной части платформы на безопасность различными способами.
Pre EFI Initialization (PEI) — в данной фазе уже начинается работа EFI кода, главная задача — загрузка DXE Foundation который будет стартовать DXE драйверов на следующей фазе. На самом деле, тут происходит еще очень много всего, но то, что мы планируем разрабатывать, сюда не пролезет, так что двигаемся дальше.
Driver Execution Environment (DXE) — на данном этапе начинают стартовать драйвера. Наиболее важная для нас фаза, потому, что наш драйвер тоже будет запущен тут. Данная среда исполнения драйверов и является основным преимуществом над Legacy BIOS. Тут код начинает исполняться параллельно. DXE ведет себя на манер операционной системы. Это позволяет различным компаниям имплементировать свои драйвера. DXE Foundation, развернутый на предыдущей фазе, поочередно находит драйвера, библиотеки и приложения, разворачивает их памяти и исполняет.
После этой фазы эстафету принимает Boot Device Selection (BDS). Вы наверняка лично видели данную фазу. Тут происходит выбор на каком устройстве искать приложение — загрузчик операционной системы. После выбора начинается переход к операционной системе. DXE boot драйвера начинают выгружаться из памяти. Загрузчик операционной системы наоборот загружается в память с помощью блочного протокола ввода — вывода BLOCK_IO. Здесь не все DXE драйвера завершают свою работу. Существуют так называемые runtime драйвера. Им придется на понятной для загруженной операционной системе нотации разметить память, которую они занимают. Иными словами виртуализировать свои адреса в адресное пространство Windows, когда произойдет вызов функции SetVirtualAddressMap(). Как только среда будет готова, “Main” функция ядра ОС начнет исполнение, а фаза EFI завершится вызовом ExitBootServices(). Контроль полностью передан в операционную систему. Дальше Windows будет решать какие и откуда загрузить дайвера, как читать и писать на диск и что за файловую систему использовать. Картинка обобщающая вышеуказанную последовательность:

Ссылка

Классный рассказ о этапах загрузки есть тут.

Подготовка проекта

Пришло время поставить перед собой простую задачу. Мы можем загрузить наш драйвер в DXE фазе, открыть файл на диске и записать в него какие — нибудь данные. Задача достаточно простая, чтобы потренироваться.

Как я уже упоминал мы воспользуемся проектом VisualUEFI, однако рекомендую также попробовать способы описанные тут, хотя бы потому, что использовать дебагер легче в описанном по ссылке способе.

Допускаю, что у вас уже есть Visual Studio. В моем случае у меня Visual Studio 2019. Для начала клонируем себе проект VisualUEFI:

Соберем EDKII. Для этого открываем EDK-II.sln из \VisualUefi\EDK-II, и просто жмем build на решении. Все проекты в решении должны успешно собраться, и можно переходить к уже готовым примерам. Открываем samples.sln из \VisualUefi\samples. Жмем build на приложении и драйвере, после чего можно запускать QEMU простым нажатием F5.

Проверяем наш UefiDriver и UefiApplication, именно так называются примеры в решении samples.sln.

Отлично, драйвер не только собрался, но и успешно загрузился. Выполнив команду drivers, мы даже увидим его в списке.

Если бы в коде мы не возвращали EFI_ACCESS_DENIED в функции UefiUnload, мы бы даже смогли выгрузить наш драйвер, выполнив команду:

Теперь вызовем наше приложение:

Написание кода

Рассмотрим код предоставленного нам драйвера. Все начинается с функции UefiMain, которая находится в файле drvmain.c. Мы бы могли назвать точку входа и другим именем, если бы писали драйвер “с нуля”, указать это можно было бы в .inf файле.

В нашем примере, в функции UefiMain, происходит вызов функции EfiLibInstallDriverBindingComponentName2, которая регистрирует имя нашего драйвера и Driver Binding Protocol. Согласно модели драйверов UEFI, все драйвера устройств должны регистрировать этот протокол для предоставления контроллеру функций Support, Start, Stop. Функция Support отвечает, может ли наш драйвер работать с данным контроллером. Если да, то вызывается функция Start. Подробнее об этом хорошо описано в спецификации (раздел Protocols — UEFI Driver Model). В нашем примере функции Support, Start и Stop устанавливают наш кастомный протокол. Его реализация в файле drvpnp.c:

Фукнция EfiLibInstallDriverBindingComponentName2 реализована в файле UefiDriverModel.c, и, на самом деле, очень простая. Она вызывает InstallMultipleProtocolInterfaces из Boot Services (см. Спецификацию стр 210). Данная функция связывает handle (в нашем случае ImageHandle, который мы получили на точке входа) и протокол.

Соответственно, можно, и нужно, в момент выгрузки драйвера, удалить установленные компоненты. Мы сделаем это в нашей функции Unload. Теперь наш драйвер можно будет выгружать по команде unload , или перед передачей управления в операционную систему.

Как вы могли заметить, в нашем коде мы взаимодействуем с UEFI через глобальное поле gBS (global Boot Services). Также, существует gRT (global Runtime Services), а вместе они являются частью структуры System Table. Источник.

Для работы с файлами нам понадобится Simple File System Protocol (см. Спецификацию стр 504). Вызвав функцию LocateProtocol, можно получить на него указатель, хотя более правильный способ перечислить все handles на устройства файловой системы с помощью функции LocateHandleBuffer, и, перебрав все протоколы Simple File System, выбрать подходящий, который позволит нам писать и читать в файл. Пример такого кода тут. А мы же воспользуемся способом проще. У протокола есть всего одна функция, которая позволит нам открыть том.

Далее, нам необходимо уметь создавать файл и закрывать его. Воспользуемся EFI_FILE_PROTOCOL, в котором есть функции для работы с файловой системой (см. Спецификацию стр 506).

Для записи в файл нам придется вручную двигать каретку. Для этого будем спрашивать размер файла с помощью функции GetInfo.

Вызываем наши функции и пишем случайные данные в наш файл:

Есть альтернативный способ выполнить нашу задачу. В проекте VisualUEFI уже реализовано то, что мы написали выше. Мы можем просто подключить заголовочный файл ShellLib.h и вызвать в самом начале функцию ShellInitialize. Все необходимые протоколы для работы с файловой системой будут открыты, а функции ShellOpenFileByName, ShellWrite и ShellRead реализованы почти так же, как и у нас.

→ Код этого примера на github

Если мы хотим перейти в VMWare, то наиболее правильным будет модификация firmware с помощью UEFITool. Например тут демонстрируется как добавляют NTFS драйвер в UEFI.

Выводы

Усложнить идею нашего драйвера и ближе подвести его под требования проекта Active Restore можно следующим образом: открыть протокол BLOCK_IO, заменить функции чтения на диск нашими функциями, которые запишут данные, читаемые с диска в лог и затем вызовут оригинальные функции. Сделать это можно следующим образом:

Нужно будет не забыть подписаться на ExitBootServices(), чтобы вернуть указатели на место. После того, как фильтр файловой системы в Windows будет готов, минифильтр продолжит логировать чтение с диска.

* Описанным способом можно переносить операционные системы Windows 7**/8/8.1/10 (x64) с диска MBR на диск GPT***, создав образ с системного раздела диска MBR при помощи Acronis True Image и затем восстановив его из образа на диск GPT для загрузки в режиме UEFI.

Перенос Windows с диска MBR на диск GPT (преобразование схемы разделов):

В данном видео показано, как перенести ОС Windows (7*/8/8.1/10 x64) с диска со схемой разделов MBR на диск со схемой разделов GPT,
сохранив данные на всех разделах и работоспособность системы, для загрузки в среде UEFI**.

Для смены схемы разделов будет использоваться Paragon Hard Disk Manager 2015,
и Acronis Disk Director 12 для изменения размера системного раздела.

Для создания загрузочного раздела ESP (EFI System partition) используется скрипт DiskPart (GPT_ESP_Disk0.dps),
(расширение .dps используется только в AdminPE!).
Для создания файлов загрузчиков и BCD для загрузки с диска GPT в режиме UEFI используется встроенная утилита BCDBoot от Microsoft.

* Перенос Windows 7 возможен, если UEFI BIOS поддерживает модуль CSM (Legacy загрузки). Убедитесь, что ваш компьютер имеет режим Legacy в BIOS.
** Для правильной работы BCDBoot ОБЯЗАТЕЛЬНО ПРАВИЛЬНО выбрать папку установленной Windows, и загрузиться в AdminPE в режиме UEFI.

Перенос Windows с диска MBR на диск GPT (+создание загрузчиков EFI):

Для смены схемы разделов будет использоваться скрипт, использующий утилиту GPTGen,
и Acronis Disk Director 12 для изменения размера системного раздела и удаления активного загрузочного раздела в 100МБ (если имеется).
Для правильного подключения букв для разделов используется Paragon Hard Disk Manager 2015.

Для создания загрузочного раздела ESP (EFI System partition) используется скрипт DiskPart (MBR2GPT_ESP_Disk0.dps),
(расширение .dps используется только в AdminPE!).
Для создания файлов загрузчиков и BCD для загрузки с диска GPT в режиме UEFI используется встроенная утилита BCDBoot от Microsoft.

Порядок действий скрипта:
1. Пауза перед началом для подтверждения преобразования
2. Преобразование указанного (№) физического диска из MBR в GPT при помощи GPTGen
3. Извлечение физического диска (программно)
4. Возврат физического диска (программно) (это требуется чтобы система обновила статус диска с MBR на GPT)
5. Создание раздела ESP (EFI System Partition) размером 100МБ в свободном пространстве перед разделом с установленной ОС Windows
6. Создание конфигурации загрузчика (BOOTMGR / BCD) на системном разделе ESP (запускается BCDBoot для выбранной автономной системы)

Не раз пользовался данной программой и вот решил поделиться с вами. В общем приняв решение скачать Acronis True Image Home с нашего проекта, вы сможете создать полную копию вашей операционной системы, а затем ее легко будет восстановить, то есть вам не нужен будет вести установление всех необходимых приложений, не надо будет переносить фотографии, просто распаковали копию и получаем рабочую версию Windows, очень удобно и быстро.

Так же Acronis True Image Home пригодится пользователям желающим хранить систему в безопасности, ведь случись какая-либо ситуация, вы всегда сможете вернуть все на круги свои, причем делайте хоть каждый день копию, никто вам этого не запрещает. Копии будут созданы совершенно всего, что есть в вашей системы, фильмы, фотографии, электронная почта, переписка в ICQ, загрузочные данные и так далее, смысла нет всего перечислять.

Acronis True Image Home очень умная программа, вам надо всего раз сохранить копию в нужное место, как она автоматически будет делать копию по расписанию в нужное время и в это место, вам больше вообще не придется беспокоится о том есть ли у вас свежая копия или нет. Помимо прочего усовершенствована система поиска, теперь можно легко искать нужные вам файлы находящиеся в архиве и вести их быстрый просмотр. Acronis True Image Home помимо своего формата архивирования теперь умеет работать и с более привычным ZIP форматов, что для многих может показаться большим плюсом. Я думаю многие заметили, что пользовательский интерфейс также полостью преобразился, работать за ним станет удобнее и приятнее.

Acronis True Image Home имеет очень удобного и надежного менеджера восстановления при загрузке системы, то есть если стандартными средствами запустить процесс восстановления не получается, вам надо просто нажать на клавишу F11 и приложение само восстановить работоспособность вашей операционной системы, что в большинстве случаев и бывает необходимо. Вы сможете создавать резервные копии только нужных вам файлов, это значительно позволит сэкономить пространство на жестком диске, да и сам процесс будет быстрее, так как копии будут создавать только новых или измененных файлов. Acronis True Image Home может полостью работать в фоновом режиме совершенно не мешая основной работе за компьютером, это тоже большой плюс, да и нагрузка на процесс не велика, поэтому мешаться разработка не будет. В общем рассказывать можно на самом деле долго, попробуйте сами и поймете, как необходима бывает данная программа, сам не раз пользовался и доволен, чего и вам желаю!

Читайте также: