Pull to refresh

Неудачный опыт восстановления предустановленной Windows 8.1 на ноутбуке HP Pavilion

Reading time 6 min
Views 41K

Предыстория


Несколько недель назад я стал обладателем ноутбука HP Pavilion p170nr c предустановленной Windows 8.1. Поскольку я заядлый линуксоид — было решено устанавливать основной, рабочей системой Ubuntu, но и оставить Windows для игрушек и чего-нибудь капризного, вроде обновления биос. Жадность тоже сыграла свою роль — за 8-ку то, по сути, деньги заплачены.

Первым делом необходимо было освободить место на диске, т.к. система, по заветам Microsoft, занимала всё доступное место одним диском C. Гугл подсказал, что Windows, наконец-то, научилась переразбивать свои диски штатными средствами. Но, как выяснилось, уменьшить диск C можно только наполовину. Дальше шли некие «неперемещаемые файлы», которые винда двигать категорически отказывалась. “Неперемещаемыми файлами” оказались точки отката и файлы подкачки. После их удаления и отключения подкачки удалось запустить процесс обрезки диска до 100Гб, но, после нескольких секунд работы, появилось диалоговое окно о том, что “недостаточно памяти”. Какой памяти, где и для чего — не сообщалось. Сильно фрагментироваться диск не успел, а для чего там еще нужна память — для меня загадка.

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

Ничего для восстановления системы с ноутбуком, естественно, не было. Как я выяснил позже HP их продаёт отдельно. А созданием чего-то подобного самостоятельно я не озаботился.

На помощь пришел SystemRescueCD. Не буду описывать часовые перипетии с манипуляциями с fdisk и testdisk-ом. Но на выходе удалось получить структуру, идентичную этой

image

Все файлы, похоже, были на месте. testdisk исправно показывал содержимое всех разделов, кроме Windows и MSR. Проблема с Windows была, по-видимому, в очень большом размере раздела (он просто вываливался с segmentation fault), а что такое MSR я так и не понял. Кажется, просто хранилище для чего-нибудь даже без файловой системы.

Тем не менее, система загружаться отказывалась. Выдавала номерную ошибку (что-то вроде 0x00000025), после попыток запустить средство восстановления сообщение менялось на «файл \windows\system32\winload.efi поврежден либо отсутствует».

Пришлось скачивать PE образ Windows 8.1 (нашел готовый на rutracker.ru) и погружаться в изучение загрузчиков, образов и других низкоуровневых деталей. Всё нижеизложенное является плодом моих изысканий, так что в чем-то я, наверняка, ошибся.

Термины и детали


UEFI и .efi-файлы. UEFI, как все знают, замена БИОС с расширенными возможностями, а .efi, по сути, исполняемые файлы для него. Как правило, в них содержатся загрузчики, единственная цель которых — инициализировать окружение и запустить загрузку ОС. Но не обязательно. Например, в виде efi-файла реализован тест памяти.

wim образы. В новых версиях Windows широко используются файлы с расширением .wim. По сути, это просто архив, который используется для развертывания системы. Может быть разбит на тома с расширением .swm. Для работы с этими образами используется утилита dism.

Порядок загрузки


После старта, UEFI анализирует список начальных загрузчиков. Это что-то вроде стартового меню, которое редактируется специальными утилитами, например efibootmgr в linux. Сами загрузчики располагаются в разделе “Система”. Файловая система этого раздела должна быть FAT32 (иначе UEFI его просто не увидит). Вроде-бы, поддерживается еще формат UDF для загрузки с компакт дисков.

Загрузчики — это просто .efi файлах, которые располагаются, как правило, в каталоге \EFI\NAME\Boot. NAME — просто название, часто по имени производителя оборудования. В частности, у меня в каталоге \EFI 2 подкаталога — HP и Microsoft, а загрузчик настроена на \EFI\Microsoft\Boot\bootmgfw.efi.

У стандартного загрузчика Windows есть и собственное загрузочное меню. Содержится оно в файле \EFI\Microsoft\Boot\BCD. По сути, это просто список .efi файлов, которые можно запустить и их параметров запуска. Например, отсюда стартует тест памяти, окружение восстановления системы и обычная загрузка Windows. Редактируется этот файл с помощью утилиты bcdedit. Кстати, именно здесь у меня была проблема после восстановления дисков. Один из параметров загрузочной записи определяет рабочий диск для неё «device partition=». И с него же будет грузиться соответствующий .efi-файл. Но после пересоздания раздела Windows его UUID изменился, поэтому файл \Windows\System32\winboot.efi и не был найден. Но это я понял гораздо позже, после того, как переформатировал весь раздел.

Порядок загрузки в случае сбоя


В случае сбоя загрузки Windows, у записи загрузчика в BCD есть параметр recoverysequence, который указывает, какой “пункт” запускать в этом случае. Эта запись описывает подготовку RAM диска из образа \Recovery\WindowsRE\winre.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, что у меня тоже вполне могло сломаться.

P.P.S. Да, действительно, дело было в том, что параметр device/osdevice записи BCD с загрузкой средств восстановления указывал не на запись с параметрами RAM диска а непонятно куда. Восстановить можно с помощью следующих команд ()

bcdedit /create {ramdiskoptions} /d "Ramdisk options"
bcdedit /set {ramdiskoptions} ramdisksdidevice partition=Drive
bcdedit /set {ramdiskoptions} ramdisksdipath \Recovery\WindowsRE\boot.sdi

Здесь:Drive — диск, на котором хранится образ восстановления. Это не UUID, а просто ‘c:’
  • Drive — диск, на котором хранится образ восстановления. Это не UUID, а просто строка с буквой диска ‘c:’ (без кавычек)
  • {ramdiskoptions} — указывается именно так (предзаданное имя), но можно подставить сюда GUID записи


Теперь редактируем параметры записи запуска среды восстановления (можно её создать заново):
bcdedit /create /d "Boot from WIM" /application OSLOADER
bcdedit /set {GUID} device ramdisk=[c:]\Recovery\WindowsRE\winre.wim,{ramdiskoptions}
bcdedit /set {GUID} path \windows\system32\winload.efi
bcdedit /set {GUID} osdevice ramdisk=[c:]\Recovery\WindowsRE\winre.wim,{ramdiskoptions}
bcdedit /set {GUID} systemroot \windows


Здесь:
  • GUID — id записи запуска среды восстановления, если нужно — можно создать
  • [c:] — текущая буква диска, на котром находится winre.wim. Диск может быть скрыт, в таком случае путь указывается через его id — {UUID}\Recovery\WindowsRE\winre.wim
Tags:
Hubs:
-8
Comments 12
Comments Comments 12

Articles