Предыстория
Несколько недель назад я стал обладателем ноутбука HP Pavilion p170nr c предустановленной Windows 8.1. Поскольку я заядлый линуксоид — было решено устанавливать основной, рабочей системой Ubuntu, но и оставить Windows для игрушек и чего-нибудь капризного, вроде обновления биос. Жадность тоже сыграла свою роль — за 8-ку то, по сути, деньги заплачены.
Первым делом необходимо было освободить место на диске, т.к. система, по заветам Microsoft, занимала всё доступное место одним диском C. Гугл подсказал, что Windows, наконец-то, научилась переразбивать свои диски штатными средствами. Но, как выяснилось, уменьшить диск C можно только наполовину. Дальше шли некие «неперемещаемые файлы», которые винда двигать категорически отказывалась. “Неперемещаемыми файлами” оказались точки отката и файлы подкачки. После их удаления и отключения подкачки удалось запустить процесс обрезки диска до 100Гб, но, после нескольких секунд работы, появилось диалоговое окно о том, что “недостаточно памяти”. Какой памяти, где и для чего — не сообщалось. Сильно фрагментироваться диск не успел, а для чего там еще нужна память — для меня загадка.
Пришлось воспользоваться каким-то partition manager-ом (точное название не помню и уже не узнаю), который обещал, что может работать с Windows 8, но, в результате, убил мне системный раздел. Причем полностью и его и раздел с образом для восстановления, хотя с ним я никаких манипуляций не производил.
Ничего для восстановления системы с ноутбуком, естественно, не было. Как я выяснил позже HP их продаёт отдельно. А созданием чего-то подобного самостоятельно я не озаботился.
На помощь пришел SystemRescueCD. Не буду описывать часовые перипетии с манипуляциями с fdisk и testdisk-ом. Но на выходе удалось получить структуру, идентичную этой
Все файлы, похоже, были на месте. testdisk исправно показывал содержимое всех разделов, кроме Windows и MSR. Проблема с Windows была, по-видимому, в очень большом размере раздела (он просто вываливался с segmentation fault), а что такое MSR я так и не понял. Кажется, просто хранилище для чего-нибудь даже без файловой системы.
Тем не менее, система загружаться отказывалась. Выдавала номерную ошибку (что-то вроде 0x00000025), после попыток запустить средство восстановления сообщение менялось на «файл windowssystem32winload.efi поврежден либо отсутствует».
Пришлось скачивать PE образ Windows 8.1 (нашел готовый на rutracker.ru) и погружаться в изучение загрузчиков, образов и других низкоуровневых деталей. Всё нижеизложенное является плодом моих изысканий, так что в чем-то я, наверняка, ошибся.
Термины и детали
UEFI и .efi-файлы. UEFI, как все знают, замена БИОС с расширенными возможностями, а .efi, по сути, исполняемые файлы для него. Как правило, в них содержатся загрузчики, единственная цель которых — инициализировать окружение и запустить загрузку ОС. Но не обязательно. Например, в виде efi-файла реализован тест памяти.
wim образы. В новых версиях Windows широко используются файлы с расширением .wim. По сути, это просто архив, который используется для развертывания системы. Может быть разбит на тома с расширением .swm. Для работы с этими образами используется утилита dism.
Порядок загрузки
После старта, UEFI анализирует список начальных загрузчиков. Это что-то вроде стартового меню, которое редактируется специальными утилитами, например efibootmgr в linux. Сами загрузчики располагаются в разделе “Система”. Файловая система этого раздела должна быть FAT32 (иначе UEFI его просто не увидит). Вроде-бы, поддерживается еще формат UDF для загрузки с компакт дисков.
Загрузчики — это просто .efi файлах, которые располагаются, как правило, в каталоге EFINAMEBoot. NAME — просто название, часто по имени производителя оборудования. В частности, у меня в каталоге EFI 2 подкаталога — HP и Microsoft, а загрузчик настроена на EFIMicrosoftBootbootmgfw.efi.
У стандартного загрузчика Windows есть и собственное загрузочное меню. Содержится оно в файле EFIMicrosoftBootBCD. По сути, это просто список .efi файлов, которые можно запустить и их параметров запуска. Например, отсюда стартует тест памяти, окружение восстановления системы и обычная загрузка Windows. Редактируется этот файл с помощью утилиты bcdedit. Кстати, именно здесь у меня была проблема после восстановления дисков. Один из параметров загрузочной записи определяет рабочий диск для неё «device partition=». И с него же будет грузиться соответствующий .efi-файл. Но после пересоздания раздела Windows его UUID изменился, поэтому файл WindowsSystem32winboot.efi и не был найден. Но это я понял гораздо позже, после того, как переформатировал весь раздел.
Порядок загрузки в случае сбоя
В случае сбоя загрузки Windows, у записи загрузчика в BCD есть параметр recoverysequence, который указывает, какой “пункт” запускать в этом случае. Эта запись описывает подготовку RAM диска из образа RecoveryWindowsREwinre.wim с раздела “Средства восстановления” и запуск соответствующего загрузчика Windows.
Из окружения восстановления, в свою очередь, можно развернуть образ для восстановления, который хранится на соответствующем разделе в файле install.wim (около 17Гб). Кроме него на этом разделе хранятся .wim файлы с драйверами, утилитами производителя, а также скрипты для установки всего этого. У меня install.wim был разбит на множество .swm файлов, размером где-то по 350Гб.
На этом же разделе я нашел файл winUCRD.wim, по объему и структуре очень похожий на winre.wim, но отличающийся от него по размеру на пару сотен килобайт и содержащий несколько лишних файлов. Возможно, какая-то заготовка для winre, которая в процессе установки дорабатывается.
Восстановление работы
Выглядит всё довольно просто — в случае сбоя системы, запускается средство восстановления, которое пытается исправить ситуацию, а если это невозможно — полностью восстанавливается заводское состояние системы. Только, по-видимому, из-за полного пересоздания нескольких дисков у меня при запуска восстановления появлялся только черный экран.
Оставалось несколько нагугленых вариантов
- Загрузиться с раздела с образом для восстановления. В некоторых статьях рекомендуют пометить этот раздел как активный, после чего установка системы запустится с него. Естественно, не получилось. При GPT разметке диска нет никакого активного раздела, да и файловая система на нём NTFS. Теоретически, способ, наверное, рабочий. Но не всегда и не у всех.
- Просто распаковать образ install.wim на диск WIndows, а дальше установка пойдет сама. Уже более правдоподобный вариант. install.wim там действительно был, и распаковать его получилось, правда, установка не стартовала, но система попыталась загрузиться, но упала на этапе загрузки драйверов directx. По видимому, нужно было доустанавливать драйвера для ноутбука. Но здесь возникла проблема в виде нескольких десятков .cmd и .vbs скриптов, предназначенных для развертывания системы и увязать их в какую-то осмысленную последовательность у меня не получилось. Попытки просто распаковать после install.wim различные .wim файлы на тот же диск, естественно, ни к чему не привели.
- Записать образ на диск или флешку и загрузиться с неё. Думаю, это рабочий вариант. Единственная проблема — образ занимает порядка 20Гб и найти такой носитель может быть проблемой.
На этом я решил закончить свои изыскания. Рабочий ноутбук был нужен к понедельнику, установка и настройка Ubuntu и всего необходимого заняла около 5-ти часов.
P.S. Собирая материал для этой статьи, наткнулся на интересный пост, объясняющий, почему может не запускаться средство восстановления. Для него в BCD нужно указать параметры RAM диска и диск, на котором находится(-лась) установленная WIndows, что у меня тоже вполне могло сломаться.
Автор: n0dwis
