Коллега по проекту обратилась с проблемой — на VHDX рабочей ВМ закончилось место. Следуя нашему внутреннему руководству, она должна была создать динамический диск размером не менее 127GB, но почему-то ограничилась 44GB.
Я подсказал, как увеличить размер VHDX в диспетчере дисков Hyper-V, получил спасибо в ответ, и на этом чат закончился.
Это было несколько странно, потому что для достижения цели требовались еще кое-какие действия. Но я решил, что подготовленная технически девушка сама справилась, тем более где-то в нашей базе знаний что-то подобное было описано.
Однако через месяц коллега снова пришла с той же проблемой. Я попросил скриншот diskmgmt.msc из ВМ и усмехнулся — недавняя статья блога покрывала этот кейс, а классика помогала решить проблему. На картинке разметка MBR (как было у коллеги), но и в GPT аналогично выглядит всё, что справа от первого раздела.
Само по себе расширение VHDX не устраняет проблему с недостатком места на разделе с ОС. Новые гигабайты добавляются в конец диска в качестве неразмеченного пространства. За его счет нужно расширить том с Windows. Это делается в diskpart или двумя щелчками мыши в оснастке. Но мешает раздел Windows RE, который с недавних пор размещается справа от ОС!
Задача решается с помощью diskpart в командной строке от имени администратора.
REM перенос среды восстановления на раздел с ОС, проверка, включение reagentc /disable dir /ah %windir%\system32\recovery reagentc /enable REM операции с разделами diskpart lis dis REM выбор диска и раздела с Windows RE sel dis R sel par P del par REM выбор тома с ОС и расширение за счет неразмеченного пространства lis vol sel vol W extend exit
Адаптируйте команды под вашу разметку диска (см. Get-Disk в PowerShell), а также подставьте свои значения:
- R — номер диска со средой восстановления и Windows
- P – номер раздела со средой восстановления
- W – номер тома с Windows
В итоге остается два раздела, включая один большой с ОС.
Больше ничего не требуется. Но перфекционист все-таки должен отжать место у раздела с ОС, создать там раздел Windows RE и настроить среду восстановления. Например, я рекомендую это тем, кто шифрует диск с BitLocker. Иначе в RE не попасть кроме как с загрузочной флэшки.
Статья довольно долго лежала в черновиках, но в конце марта ко мне пришел Вадимс Поданс с точно таким же вопросом. Это был сигнал, что пора публиковать! ✌
artem
Задача имеет право на жизнь, но у меня есть много вопросов к твоему решению :)
вот это зачем вообще в начале? Чтобы убедиться, что у тебя есть раздел с RE? Ну, для этого есть и проще способы.
тут тебе приходится делать сложное объяснение словами про то, что читателю надо самому указать правильные буквы и цифры. Но это же можно автоматически определить в PowerShell — буквально в одну строку, как ты любишь :)
Ну и всё остальное дальше в PowerShell делается либо проще, либо ненамного сложнее, чем в DiskPart. Но в любом случае — намного более читаемо. Если только ты не помнишь синтаксис DiskPart наизусть и не смотришь про него сны по ночам :)
artem
Собственно говоря, дальше всё тоже довольно просто.
вообще говоря, PowerShell позволяет задать атрибут «GPT_BASIC_DATA_ATTRIBUTE_NO_DRIVE_LETTER». (Set-Partition -InputObject $partition -NoDefaultDriveLetter $true). Но это работает только для тех разделов, у которых тип «Basic Data». Можно, конечно, сначала создать раздел такого типа, задать ему атрибут, а потом поменять тип. (Плюс две строчки в скрипте). Но на практике это особого смысла не имеет, потому что ОС и так не станет назначать букву разделу, у которого тип «Recovery».
Атрибут «GPT_ATTRIBUTE_PLATFORM_REQUIRED» задать через PowerShell напрямую нельзя. Можно, конечно, добавить строчку с вызовом DiskPart — но, опять же, на практике это довольно бессмысленно. Поэтому я решил всё это пропустить.
artem
Кстати, к нашему старому разговору — почему раздел WinRE создаётся после перезагрузки? (https://www.outsidethebox.ms/21522/#comment-368750)
Вот эта статья даёт возможный ответ. Сделано это для оптимизации сценария, когда ОС предустанавливается производителем ПК или администратором.
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-recovery-environment—windows-re—technical-reference?view=windows-11#hard-drive-partitions
(кажется, в цитате не работает перенос строк — но, думаю, ты разберёшься в написанном.)
Т.е. если ты предустанавливаешь ОС для своих заказчиков или сотрудников, то такое разделение по фазам даёт тебе возможность дополнительно настроить WinRE под свои требования. (Можно, наверное, делать это скриптом во время Offline Servicing). Почему считается, что это проще сделать до копирования образа на выделенный раздел, а не после, я не очень понимаю. Но некоторая логика в этом есть.
При этом если в твоём случае нет отдельного этапа предустановки, т.е. ты просто грузишься с флешки и устанавливаешь ОС мастером как конечный пользователь (next → next → finish), то фазы установки не разнесены по времени, и с этой точки зрения уже неважно, в какую именно фазу копируется образ WinRE.
Vadim Sterkin
Не вижу в доке объяснения, почему раздел сразу не создается :) Тут написано, что WinRE.wim сначала кладут на раздел с ОС. Но это издавна так делается. Вот например док времен 8/8.1 https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/hh825173(v=win.10)
Vadim Sterkin
Спасибо за комментарии, Артем.
Нет. Чтобы обеспечить наличие рабочей RE в принципе. Ведь мы будем удалять выделенный для нее раздел. Выключение автоматически переносит на диск с ОС. Дальше проверка успешного переноса и включение.
Да, это годно.
Вот именно, что не все делается в PowerShell, а у того что делается, хуже наглядность. Я специально сравнивал же в Как предотвратить назначение буквы диска или получить доступ к служебному разделу.
За скрипты спасибо, возьму на вооружение :)
artem
да, это годно. Но не помешал бы комментарий, потому что совершенно неочевидно :) Особенно учитывая, что команды могут выдавать ошибки. (Например, если она таки была уже выключена).
я помню, что ты сравнивал :) И действительно, бывают ситуации, когда DiskPart уместнее. Например, когда тебе действительно надо выставлять этот злосчастный атрибут «platform required». (А при удалении это 100% не требуется). Или если ты работаешь в стоковой WinPE. Или когда ты передаёшь команды по телеграфу (или грузишь скрипт по GPRS), и каждая буква на счету :)
но я как раз хотел показать, что конкретно тут (в ситуации с WinRE) — не тот случай. Во-первых, PowerShell позволяет избежать сложных инструкций в стиле «посмотрите на вывод предыдущей команды и подставьте параметры в следующей». Во-вторых, если просто читать код, PowerShell нагляднее, особенно когда ты сокращаешь названия команд в Diskpart (sel par вместо select partition).
из моих примеров можно понять, что они делают, строчка за строчкой, даже если ты никогда не пользовался модулем Storage раньше, а про PowerShell только что-то слышал пару раз. Из твоих примеров понять ничего нельзя, если только ты сам не пользуешься Diskpart минимум раз в пару месяцев и не помнишь его синтаксис наизусть.
Vadim Sterkin
Сорри, мне казалось, что очевидно :) Точнее я думал, что в связанной статье про создание RE это разжевано. Но нет. Возможно, где-то еще писал про это.
Гм… пытаюсь вспомнить, почему же я вписал смену ИД в статью. Я же сам это не тестировал на сей раз, только моя коллега и Поданс позднее :) Либо я просто скопировал это на всякий случай из уже опубликованной статьи, либо в MBR атрибут таки надо удалять. Первое вероятнее.
Ок, я согласен. И опять же благодарен, что ты поделился альтернативным решением на PowerShell. Это же классика — автор не должен раскрывать тему до конца или сделать [намеренную] ошибку, чтобы читатели ему доставили как следует :)
Наконец, я в данном случае не ставил перед собой целью узнать что-то новое или разложить [для себя] по полочкам старое или хотя бы попрактиковаться в PowerShell. Заметка — просто компиляция уже опубликованных материалов для решения практической задачи. Я даже особо не стремился публиковать, пока Вадимс не пришел с вопросом.
artem
может быть, diskpart отказывался удалять раздел, пока ты не сменил тип и не убрал атрибуты? Я тоже не проверял, но вообще звучит как правдоподобное объяснение :)
Vadim Sterkin
У коллеги таки была MBR — в статье написано, и скриншоты там MBR :) Я просто давно опубликовал в ранний доступ, забыл уже…
Посмотрел в MBR. Там тип раздела восстановления там Unknown.
То есть в скрипт PowerShell надо для начала добавлять условие по PartitionStyle.
Однако раздел удалился без смены атрибутов. Чат с коллегой уже недоступен, поэтому будем считать, что смена не нужна, поправил статью.
artem
ну, наверное, потому, что заранее сложно понять, какого размера он нужен. Там же речь, что ты можешь разгуляться и добавить в свой образ кучу языков и дополнительных компонентов.
Vadim Sterkin
Да, но раньше размер RE был фиксированный и создавался он сразу, а в доке то же самое было написано.
artem
ну, короче, прозреваю, что связанно именно с этим. Старая модель плохо работала в ситуациях с кастомизацией образа, а теперь стало более гибко.
(по логу ReAgentC, кстати, видно, что он пытается — или делает вид, что пытается — сам создать раздел, если подходящего не найдено. На моей машине, правда, у него ни разу этого не получилось — и я не очень понимаю, почему. Но если бы он действительно делал это сам, и не нужно было бы руками отрезать, это было бы дополнительным аргументом в пользу того, почему этот шаг убрали из установщика.)