Почему в VirtualBox нет выбора x64?
Всем привет
Поговорим сегодня о не совсем приятном косяке, который может быть у вас, если вы решили воспользоваться виртуальной машиной VirtualBox. Косяк заключается в том, что вы не можете установить 64-битную винду. То есть при создании виртуальной машины, у вас нет выбора 64-битной винды, только 32-битная.
У меня такой косяк тоже был, однако это было давно, года четыре назад, тогда у меня был еще древний проц Pentium 4. Любил я своего Пенька и дооолго с него не слазил..
Напомню, что речь идет о том, что вот в этом меню VurtualBox нет пункта для установки Windows 64-bit:
Ну так вот, почему в VirtualBox нет выбора x64? Первый вариант самый банальный, это то, что ваш процессор не поддерживает технологию виртуализации. У почти всех современных процессоров она есть, что у Intel, что у AMD. Есть даже и у старых процессоров, но не у всех, вот например в семействе Pentium 4 ее нет (есть только в моделях 662/672). А вот у Pentium D и выше, то там уже почти во всех процах виртуализация есть. По поводу AMD ничего сказать не могу, но думаю что картина примерно такая же.
В любом случае, в новых процах есть виртуализация. Если у вас нет, то у вас или старый процессор или же какой-то редкий или особенный зверь.
Но как понять, поддерживает ваш процессор виртуализацию или нет? Конечно лучше всего это просто посмотреть модель процессора, и потом поискать в интернете инфу о проце. Можно также скачать утилиту CPU-Z и она покажет вам инфу, вот например у меня процессор Pentium G3220, вот какую инфу показывает о нем прога CPU-Z:
Вот видите, там есть такое как Instructions, вот там идет перечень инструкций, которые поддерживает процессор. Правда тут есть один моментик, у каждой фирмы процессора технологии виртуализации называются по разному. Вот у Intel это VT-x (если есть VT-d, то это еще круче), а вот у AMD технология называется AMD-V. Вот например инфа о процессоре AMD FX-8350, и вот тут тоже указано, что проц поддерживает технологию AMD-V:
Кстати этот процессор AMD FX-8350 мне вот очень нравится, стоит он не так уж и дорого, вроде бы где-то в два раза меньше чем Core i7. Но по мощности то понятно что он проигрывает i7, хотя у FX-8350 8 ядер, а у i7 только 4. Но как по мне, то преимущество AMD FX-8350 в том, что в нем 8 ядер, то есть там, где нужна многопоточность, то FX-8350 может быть более эффективен, а может и нет, точно не знаю..
Ну, вроде бы разобрались. То есть чтобы проверить процессор, есть ли в нем виртуализация или нет, то быстрее всего будет вам скачать утилиту CPU-Z (она очень простая и комп не грузит) и быстренько в ней посмотреть. И потом если нужна инфа о проце, то вы запускаете CPU-Z и там вся главнейшая инфа есть!
Кстати, не все знают, но VirtualBox работает и без виртуализации. Я не уверен, но знаю точно что в VirtualBox раньше была встроенная программная виртуализация, есть ли она сейчас, я не знаю. Однако, эффекта от нее лично я не заметил: без технологии виртуализации, виртуальная машина работает с тормозами и это совсем некомфортно.
Есть еще такой прикол, что VirtualBox будто не видит то, что что процессор поддерживает виртуализацию. Чтобы исправить эту проблему, то можно сделать вот что. Скажу сразу, я не уверен что вам это поможет, но некоторым юзерам помогло. Нужно отключить один компонент, который относится к виртуализации, но немного к другой так бы сказать. Вот как это сделать, нажимаете правой кнопкой по Пуску и там в меню выбираете пункт Программы и компоненты (самый верхний):
Дальше нажимаем вот на Включение или отключение компонентов:
Теперь смотрите, у вас будет список компонентов, некоторые из них включены, а некоторые нет. Вот тут что нужно сделать? Тут нужно просто снять галочку с такого компонента как Hyper-V, вот он:
После этого делаете перезагрузку и смотрите, появилась ли возможность ставить 64-битную винду. Если все получилось, то у вас появится вот такой вот список, ну то есть можно будет поставить и 64-битку:
Кстати, в интернете есть мнение, что VirtualBox лучше чем VMware, но так ли это на самом деле? Ну вообще споров на эту тему не то чтобы много, но достаточно, но многие как я понял не спорят вообще, ибо уверены в своей правоте. Ну есть такое, я вот тоже не спорю, потому что уверен в своей правоте.. Но я уверен, потому что я проводил тесты и не один раз, и у меня во всех случаях VMware (а если быть точнее, то бесплатная версия VMware Player) работала всегда быстрее, чем VirtualBox. В плане удобства, то мне чем-то VirtualBox нравится больше. Но если нужно часто работать с виртуальной машиной, то тут я выбираю только VMware. Ну это так, просто вам на заметку, мое мнение так бы сказать..
Но я вот еще кое что не написал, вот забыл, это мой косяк, уж извините. Может быть такое, что ваш процессор виртуализацию поддерживает (если он современный, то 95% что поддерживает), но вот выбора 64-битной винды все равно нет. В чем дело? А дело все в том, что технология виртуализации это опция, которая включается или отключается в БИОСЕ. И не на всех материнках эта опция по умолчанию идет включена! В общем вам нужно зайти в БИОС (включили комп > нажимаете секунд десять на кнопки F1, F2, Del, ждете БИОСа, способ работает на многом железе) и там включить эту виртуализацию. Там что-то будет написано типа Virtualization Technology и будет Enabled (включено) или Desabled (отключено). Что-то в этом стиле, вот пример, но у вас может быт оформление другое:
Вот забыл еще кое что сказать, в Windows 10 в диспетчере вы тоже можете посмотреть, включена виртуализация или нет. На вкладке Производительность есть там такой пунктик Виртуализация, вот там все указано:
Еще скажу в двух словах, что такое виртуализация. Это когда виртуальная машина может посылать команды процессору напрямую. Ну как-то так. У Intel базовая виртуализация, это VT-x, а продвинутая, это VT-d. VT-x позволяет просто посылать команды процессору напрямую, а вот VT-d позволяет перебрасывать в виртуальную машину целые устройства на шине PCI, например видеокарту. Но как правило, VT-d идет в более дорогих процессорах. У AMD я не уверен, но скорее всего есть что-то аналогичное
Ну все ребята, на этом уже все. Надеюсь что вы все таки сможете выяснить причину, почему в VirtualBox нет выбора x64. Думаю что вы решите эту проблему, ибо скорее всего у вас современный процессор, который аппаратно поддерживает эту виртуализацию. Удачи вам в жизни, хорошего настроения
Запуск x64 систем в VirtualBox 6.1.12 на Windows 10 2004
Написать подобный пост меня сподвигло потраченное время на решение проблемы.
Суть проблемы — запускаете виртуальную машину в VirtualBox, а она грузится как черепаха, бывает просто зависает и спустя некоторое время перезагружается и в окне виртуальной машины внизу справа высвечивается значок
Прежде чем найти решение я искал проблему в обновлении видео-драйверов, в ssd, в самой виртуалке, но никак не в том, что явилось причиной — обновление до версии 2004.
Долго разбирал лог vbox.log на предмет ошибок, пока не наткнулся на это:
Всему виной является сама Windows 10. В версии 2004 по умолчанию включен Hyper-V, если у вас установлен компонент WSL2 или Песочница и если этого не знать, то много времени пропадёт впустую.
Вы думаете, что сможете решить проблему отключением комнонентов, использующих Hyper-V вроде WSL2, Песочница? — это не так.
Решается вопрос одной командой. Нужно просто в cmd из-под администратора выполнить:
bcdedit /set hypervisorlaunchtype off
При этом выполнить перезагрузку и полностью отключить питание от ПК на секунд 30.
А после чего полёт нормальный и при старте виртуальной машины вы снова увидите значок , означающий что всё хорошо…
Собираем VirtualBox под Windows
Введение
Как известно большинству пользователей Windows-версии VirtualBox (далее — VB, не путать с Visual Basic), в релизе 4.3.14 разработчики этой программы добавили дополнительный механизм защиты, называемый «hardening» (что можно перевести как «упрочнение»), который привёл к многочисленным проблемам совместимости VB с антивирусами, драйверами крипто-модулей и даже отдельными обновлениями самой Windows, в результате чего виртуальные машины попросту отказываются запускаться. В лучшем случае пользователю приходится ждать около месяца, пока проблемная программа, о которой он сообщит разработчикам, окажется учтена в следующем релизе VB. В худшем случае придётся либо удалять конфликтующую программу (или системное обновление), либо откатывать VB до версии 4.3.12 — последней, в которой не было этой защиты. Многочисленные предложения к разработчикам о добавлении пользовательского списка исключений или опции, отключающей защиту целиком, остаются без внимания. Единственный внятный ответ с их стороны звучит так: «не хотите защиту — компилируйте из исходников сами». Что ж, придётся этим заняться.
Несмотря на то, что процедура сборки описана на официальной вики, она неполна и кое в чём устарела, а сама сборка так и норовит выдать странные ошибки. Поэтому когда я всё-таки пробился до конца сей процедуры, я решил, что её описание заслуживает отдельной статьи. Инструкция время от времени обновляется и на текущий момент адаптирована для VB версии 6.1.18, но если кого-то заинтересует сборка более ранних версий VB или библиотек, информацию можно выцарапать из истории правок.
Содержание
Постановка задачи
Изначально я планировал упростить себе задачу и обойтись минимальной пересборкой, чтобы устанавливать официальный дистрибутив и просто подменять в нём бинарные файлы. Однако оказалось, что такой подход не сработает, поскольку не учитывает использование системных механизмов установки и регистрации драйверов и COM-компонентов. Можно было бы попытаться разобраться в деталях и написать автоматизирующий скрипт, но я решил замахнуться на более крупную дичь: самостоятельно собрать полноценный дистрибутив, максимально близкий к официальному и отличающийся от него только отсутствием hardening’а.
Сразу скажу, что на 100% задачу решить не удалось. Слабым звеном оказались гостевые дополнения, которые в официальном пакете собраны под Windows (32- и 64-битную), OS/2, Linux и некоторые другие *NIX-системы. В комментариях соответствующего Makefile указано, что сборка осуществляется удалённо на разных машинах, а настраивать такой комплект виртуалок мне не улыбалось. В итоге я решил собирать из исходных кодов всё, кроме дополнений, ISO-образ которых буду просто скачивать с сервера Oracle. Я пока не исследовал вопрос наличия hardening’а в дополнениях, но даже если он там есть, сообщений о вызванных им проблемах мне до сих пор не попадалось.
Пара предупреждений
• Проблемы безопасности
Про hardening известно, что добавили его не просто так, а для закрытия некой уязвимости VB. Подробно рассказать о сути уязвимости Oracle категорически отказывается, несмотря на то, что в официальных дистрибутивах проблема исправлена много лет назад. В общих чертах речь идёт о том, что системный механизм внедрения библиотек в чужие процессы в случае VB может приводить к неавторизованному повышению привилегий на хостовой машине, и что для этой уязвимости VB есть реально использующиеся эксплойты. Если это вас не пугает, можете продолжать чтение, но я вас предупредил.
• Подписывание драйверов
Как известно, начиная с Vista, 64-битная Windows в обычном режиме запрещает загрузку драйверов, не подписанных сертификатом с цепочкой доверия, ведущей до корневого сертификата Microsoft (а в Windows 10 при загрузке с включённым Secure Boot драйверы и вовсе должны быть подписаны непосредственно самой Microsoft). Поэтому прежде чем компилировать VB даже для личного использования, необходимо продумать решение этой проблемы: либо купить сертификат, либо попробовать найти сервисы, предоставляющие услугу подписывания драйверов для разработчиков open source (если они, конечно, согласятся подписать заведомо уязвимый драйвер), либо перевести свою Windows в тестовый режим и использовать самоподписанный тестовый сертификат.
Далее я буду ориентироваться на этот последний вариант, но в нужных местах укажу, как поменяется процедура при наличии полноценного сертификата.
• Прекращение поддержки 32-битных хостовых систем
Начиная с версии 6.0 в VirtualBox была официально прекращена поддержка 32-битных хостов (к гостевым системам это не относится), однако сама возможность работы в этих системах ещё оставалась. В версии 6.1 сделан следующий шаг, и 32-битная версия пакета окончательно удалена из инсталлятора (за исключением библиотеки программного интерфейса). Я в своей сборке применил аналогичные модификации, а из статьи удалил все ставшие неактуальными инструкции. Если вам нужна поддержка таких систем, вы можете попробовать самостоятельно собрать 32-битный вариант, воспользовавшись предыдущими версиями статьи из репозитория. Но нужно понимать, что чем дальше, тем больше проблем будет возникать, и не все из них можно будет решить самостоятельно. Разумным выходом будет либо оставаться на предыдущих версиях VirtualBox, либо перейти на 64-битную систему.
Готовим окружение
Официально в качестве сборочной системы рекомендуется Windows версии 8.1 или 10. Моя сборочная система построена на базе Windows 7 SP1 x64 ещё с тех времён, когда это была рекомендуемая версия, и проблем пока что не возникало. Если вы выделяете для сборки отдельную машину (реальную или виртуальную), имейте в виду, что ей необходим доступ в Интернет.
Для создания сборочного окружения потребуется немаленький набор программ. Если для программы присутствует портабельная версия, я использую её, а не инсталлятор.
Следующий набор программ поставляется только в виде инсталляторов (по крайней мере, официально). Для Visual Studio и SDK/WDK важно соблюдать порядок установки, как указано ниже. После установки крайне желательно установить обновления через Windows Update с включённой опцией поддержки всех продуктов Microsoft.
- Visual Studio 2010 Professional
Для полноценной сборки требуется именно 2010, причём не ниже Professional. В версии 2010 Express нет библиотеки ATL, необходимой для сборки COM API, через который работают фронт-энды. Я сделал несколько попыток перенести проект на VS 2013 или 2015 Community Edition, чтобы избавиться от необходимости платной лицензии (которую к тому же сейчас крайне проблематично купить), но, увы, безуспешно. - Windows SDK v7.1
- Visual Studio 2010 SP1
- Visual C++ 2010 SP1 Compiler Update for SDK 7.1
- Windows Driver Development Kit (WDK) v7.1
- Windows SDK v8.1
- ActivePerl
- ActivePython 2.7
- Cygwin
Остальные программы скачиваются в виде архивов или исходных кодов:
- Qt 5.6.3 (исходные коды)
- MinGW-w64 4.5.4 x86_64
- SDL v1.2.x (development-пакет для Visual C++)
- cURL (исходные коды)
- OpenSSL 1.1.1 (исходные коды)
- gSOAP 2.8.x (рекомендуется 2.8.41 или выше)
- libvpx 1.7.0 (исходные коды; более новые версии не поддерживают VS 2010)
- libopus 1.3.1 (исходные коды)
- MiKTeX Portable
- NASM
Рекомендую 64-битную портативную версию. - WiX
Рекомендую портативный набор (архив с именем вида wix311-binaries.zip ).
Также потребуются два архива:
- DocBook XML DTD 4.5
- DocBook XSL Stylesheets 1.69.1
Если вы не планируете собирать такой же пакет, как я, то некоторые из перечисленных инструментов могут вам не потребоваться. Здесь я вкратце перечислю, какую роль они выполняют.
- SDK 8.1
Для сборки будет использоваться SDK версии 7.1, версия 8.1 требуется только для утилиты SignTool: в 7.1 отсутствует поддержка двойного подписывания SHA-1/SHA-256. Если у вас есть компьютер с установленным SDK версии 8.1 или более поздней, можно просто скопировать утилиту signtool.exe оттуда (со всеми зависимостями) и указать соответствующий путь в файле LocalConfig.kmk (см. ниже). - WiX
Это инструмент для создания MSI-инсталляторов. Хоть финальный вариант инсталлятора и является EXE-файлом, внутри он содержит MSI, так что WiX тут необходим. Если вам достаточно простой компиляции бинарников, то этот пакет не понадобится. - SDL
На этой библиотеке основан фронт-энд VBoxSDL.exe — минималистичная альтернатива стандартной оболочке VirtualBoxVM.exe . Если вам не требуется VBoxSDL, то, может быть, удастся обойтись без библиотеки SDL, но я это не проверял. - gSOAP
Этот компонент необходим для сборки сервиса удалённого управления VB: VBoxWebSrv.exe . Отсутствие gSOAP не является критической ошибкой, VB успешно соберётся без этого сервиса. - libvpx, libopus
Видео- и аудиокодек, использующиеся для записи видео с экрана виртуальной машины. При их отсутствии VirtualBox собирается и работает корректно, а функция записи просто игнорируется (хотя и показывает анимацию, будто запись выполняется). - Cygwin
Требуется для сборки libvpx. - MiKTeX
При помощи MiKTeX компилируется справочник в формате PDF ( doc\UserManual.pdf ). Отсутствие MiKTeX не является критической ошибкой, VB успешно соберётся без PDF-документации. - NASM
Этот ассемблер будет использоваться для сборки OpenSSL. Поддерживается и сборка без внешнего ассемблера, но с ним будет создан более оптимальный код.
Программа | Версия | Путь установки |
---|---|---|
Visual Studio | 2010 Professional | C:\Program Files (x86)\Microsoft Visual Studio 10.0\ |
SDK | 7.1 | C:\Program Files\Microsoft SDKs\Windows\v7.1\ |
SDK | 8.1 | C:\Programs\DevKits\8.1\ |
WDK | 7.1.0 | C:\WinDDK\7600.16385.1\ |
ActivePerl | 5.26.1 Build 2601 x64 | C:\Programs\Perl\ |
ActivePython | 2.7.14.2717 x64 | C:\Programs\Python\ |
WiX | 3.11.1.2318 | C:\Programs\WiX\ |
Qt | 5.6.3 | C:\Programs\Qt\5.6.3-x64\ |
MinGW-64 | 4.5.4 | C:\Programs\mingw64\ |
Cygwin | — | C:\Programs\cygwin64\ |
SDL | 1.2.15 | C:\Programs\SDL\x64\ |
cURL | 7.74.0 | C:\Programs\curl\ |
OpenSSL | 1.1.1i | C:\Programs\OpenSSL\ |
gSOAP | 2.8.110 | C:\Programs\gSOAP\ |
libvpx | 1.7.0 | C:\Programs\libvpx\ |
libopus | 1.3.1 | C:\Programs\libopus\ |
MiKTeX Portable | 2.9.6942 | C:\Programs\MiKTeX\ |
NASM | 2.14.02 x64 | C:\Programs\nasm\ |
DocBook XML DTD | 4.5 | C:\Programs\DocBook\xml\ |
DocBook XSL Stylesheets | 1.69.1 | C:\Programs\DocBook\xsl\ |
Особенности установки программ
В этом разделе я привожу указания или инструкции для отдельных пакетов, где процедура неочевидна или требует дополнительных шагов.
• Windows SDK v7.1
При установке могут возникнуть проблемы из-за устаревших версий компиляторов и рантайма: они не могут установиться поверх более новых версий, установленных с VS 2010, и инсталлятор считает это критической ошибкой. Необходимо либо отключить соответствующие галочки, либо предварительно удалить из системы пакеты с именами вида «Microsoft Visual C++ 2010 Redistributable», «Microsoft Visual C++ 2010 Runtime», «Microsoft Visual C++ Compilers…» (SDK установит старые версии пакетов, а Windows Update потом обновит их до актуальных).
Также обратите внимание, что для финальной сборки MSI-пакетов потребуется установить примеры программ (Windows Native Code Development -> Samples): в их составе идут скрипты, использующиеся сборочными правилами.
• Windows SDK v8.1
Достаточно установить только средства разработки (Windows Software Development Kit).
• WDK v7.1
Достаточно установить только сборочные окружения (Build Environments).
• Qt 5.6.3
Начиная с версии Qt 5.7.0 прекращена поддержка сборки в MSVC версий ниже 2012, поэтому используем 5.6.x.
Для Visual Studio 2010 официальные сборки отсутствуют, поэтому необходимо сначала собрать библиотеку из исходных кодов.
- Распаковываем архив с исходным кодом Qt в каталог C:\Programs\Qt\ и переименовываем полученный подкаталог qt-everywhere-opensource-src-5.6.3 в 5.6.3-src .
- Рядом создаём каталог build-x64 , в котором будет происходить сборка.
- Открываем консоль, выполняем следующие команды для подготовки окружения:Команда color отключает зелёный цвет шрифта, устанавливаемый скриптом SetEnv.Cmd .
- Теперь запускаем configure.bat из каталога 5.6.3-src . Поскольку бо́льшая часть Qt в VB не используется, можно сильно ускорить сборку, отключив ненужные компоненты, но необходимо учитывать, что к некоторым опциям VB относится очень щепетильно. В частности, я наткнулся на следующее:
- OpenGL ES 2 не поддерживается (компиляция VB не может увидеть некоторые заголовочные файлы).
- Поддержка FreeType должна быть включена (без неё не соберётся плагин qoffscreen , использующийся в VB).
Вот итоговая команда, которую я использовал у себя:
- Указанный каталог установки (опция -prefix ) Qt записывает внутрь генерируемых промежуточных файлов исходного кода при конфигурировании, так что собранная библиотека будет помнить этот путь. Это приводит к тому, что при запуске Qt-приложение по умолчанию будет искать плагины по этому пути, и только если ничего не нашлось, обратится к собственному каталогу. В большинстве ситуаций это работает корректно, но если вдруг на целевой машине в каталоге c:\Programs\Qt\5.6.3-x64 окажется отличающаяся сборка Qt (с другими флагами), то VB при запуске свалится с ошибкой.
Избежать этого можно двумя путями: либо добавить в каталог VB файл qt.conf с содержимым:либо подправить сохранённый в Qt путь установки, чтобы он по умолчанию указывал на каталог программы. Я пошёл по второму пути, чтобы итоговая установка VB выглядела более аккуратной. Для этого нужно открыть файл C:\Programs\Qt\build-x64\qtbase\src\corelib\global\qconfig.cpp , который создался конфигуратором, найти там строчку вида:и заменить там весь путь на точку, чтобы получилось следующее:Установка Qt при этом по-прежнему будет выполнена в указанный ранее каталог, потому что он уже сохранён в Makefile-ах. Это изменение затронет только поведение Qt-программ при их запуске. - Далее запускаем сборку командой nmake
- Устанавливаем скомпилированную библиотеку командой nmake install
После завершения установки каталоги build-x64 и 5.6.3-src можно удалять.
• MinGW
Архив просто распаковывается в выбранный каталог установки.
• Cygwin
При установке необходимо отметить пакеты make и yasm .
- Распаковываем SDL в каталог C:\Programs\SDL\x64\ .
- Перемещаем всё содержимое C:\Programs\SDL\x64\lib\x64\ на уровень выше (в C:\Programs\SDL\x64\lib\ ), каталоги C:\Programs\SDL\x64\lib\x86 и x64 удаляем.
Распаковываем архив nasm-2.14.02-win64.zip в C:\Programs\ , переименовываем полученный каталог nasm-2.14.02 в nasm .
• OpenSSL
- Для этой библиотеки нам по-прежнему нужны сборки под 32- и 64-битную архитектуру. Распаковываем архив OpenSSL два раза в каталог C:\Programs\OpenSSL\ , переименовывая полученный подкаталог из openssl-1.1.1i , соответственно, в openssl-1.1.1i-x32 и openssl-1.1.1i-x64 .
- Открываем консоль, собираем и устанавливаем 32-битную версию:Конфигуратор может выдать страшное сообщение, что, дескать, не может найти компилятор. Не обращайте внимания, это он слегка не в себе.
Если вы не хотите использовать NASM, исключите отсюда модификацию переменной PATH и добавьте к вызову Configure параметр no-asm . - Открываем новую консоль, собираем и устанавливаем 64-битную версию:Отказ от NASM делается аналогично 32-битной версии.
- Каталоги C:\Programs\OpenSSL\openssl-1.1.1i-x32 и openssl-1.1.1i-x64 можно удалять.
- Как и с OpenSSL, здесь нам потребуется не только 64-битный, но и 32-битный вариант. Распаковываем архив cURL в каталог C:\Programs\curl\ , переименовываем получившийся подкаталог из curl-7.74.0 в curl-7.74.0-x32 .
- Открываем в редакторе файл C:\Programs\curl\curl-7.74.0-x32\winbuild\MakefileBuild.vc , находим там в районе строк 61–69 условный блок вида:и добавляем после него строчку:Если этого не сделать, то при сборке VB полезут ошибки линковки.
- Открываем файл C:\Programs\curl\curl-7.74.0-x32\winbuild\gen_resp_file.bat , после первой строчки в нём ( @echo OFF ) вставляем команду:Это фиктивная команда, которая ничего не делает, и задача её лишь в том, чтобы сбросить код ERRORLEVEL . В противном случае может возникнуть ситуация, когда этот код оказывается ненулевым ещё до запуска батника, а сам батник не выполняет ни одной команды, меняющей код возврата. В результате nmake считает, что батник вернул ошибку, и прерывает сборку.
- Делаем копию каталога curl-7.74.0-x32 под именем curl-7.74.0-x64 .
- Открываем консоль, собираем 32-битную версию и копируем необходимые файлы в целевой каталог:
- Собираем 64-битную версию, открыв новую консоль и выполнив команды:Обратите внимание, что, в отличие от 32-битной версии, здесь мы копируем ещё и curl.exe , он нам потом понадобится для скачивания образа гостевых дополнений.
- Каталоги C:\Programs\curl\curl-7.74.0-x32 и curl-7.74.0-x64 можно удалять.
• libvpx
- Распаковываем архив libvpx в каталог C:\Programs\libvpx-build\ .
- Запускаем Cygwin, в нём будем выполнять конфигурирование, сборку и установку библиотеки. В качестве целевой платформы будет указана Visual Studio 2010. При этом сборочная система попытается автоматически запустить сборку, но будет делать это с использованием msbuild.exe , который мне не удалось заставить работать корректно в имеющемся окружении. Вместо этого оказалось проще запустить отдельным шагом сборку самой Студией, благо она позволяет работать из командной строки. Впрочем, можно этот шаг выполнить и при помощи графической среды, если кому-то она привычнее, но в этом случае вам придётся к переменной PATH добавить путь C:\Programs\cygwin64\bin (или как-то иначе задать его в проекте), потому что там располагается ассемблер yasm.exe , необходимый для сборки. Итак, в терминале Cygwin выполняем следующие команды:
- Закрываем терминал Cygwin, больше он нам не понадобится. Каталог C:\Programs\libvpx-build можно удалять.
• libopus
- Распаковываем архив opus в каталог C:\Programs\libopus-build\ , переходим в подкаталог opus-1.3.1\win32\VS2015 .
- Проект рассчитан на более новую версию Visual Studio, и в 2010-й просто так не соберётся, надо внести немножко правок. Можно это сделать как через IDE, так в обычном текстовом редакторе. Я предпочёл второй путь. Итак, открываем в редакторе файл opus.vcxproj (остальные проекты нам не нужны) и проделываем следующие манипуляции:
- Находим все строки с текстоми меняем версию с v140 на v100 . Если вы работаете в IDE, то эта опция в настройках проекта располагается на странице Configuration Properties -> General и называется «Platrofm Toolset». Не забудьте выбрать конфигурации и архитектуры в выпадающих списках в верхней части диалога.
- Далее находим блок:и добавляем туда тег:В настройках проекта Visual Studio это делается на странице Configuration Properties -> C/C++ -> General выставлением опции «Debug Information Format» в «ProgramDatabase (/Zi)». Собственно говоря, подойдёт и любое другое валидное значение из списка, база отладочной информации нас не интересует, просто при невалидном значении проект отказывается собираться.
- Теперь собираем Release-конфигурацию для обеих архитектур (из оболочки VS или из командной строки) и копируем собранную библиотеку opus.lib и подкаталог include\ в целевой каталог установки:
- Каталог C:\Programs\libopus-build можно удалять.
• gSOAP
Открываем архив, заходим в подкаталог gsoap-2.8\gsoap и распаковываем содержимое этого подкаталога в C:\Programs\gSOAP\ . Для корректной сборки с OpenSSL 1.1.x требуется версия 2.8.41 или выше. Для более ранних версий потребуется наложить специальный патч (автор: Mattias Ellert). Можно это сделать вручную (формат достаточно очевидный: открываем поочерёдно указанные файлы, удаляем строчки, отмеченные минусами, и добавляем отмеченные плюсами; остальные строки помогают определить контекст), а можно взять стандартную утилиту patch , портированную для Windows, и натравить её.
• MiKTeX
- Распаковываем архив в C:\Programs\MiKTeX\ .
- Открываем консоль и запускаем установку дополнительных модулей:
• DocBook
Для распаковки архива XML DTD нужно создать отдельный каталог и поместить туда все файлы. Архив с XSL Stylesheets уже содержит нужный подкаталог, поэтому достаточно его просто распаковать и переименовать полученный подкаталог.
Последние штрихи
Подготовка к сборке почти завершена, остались несколько шагов. Если вы этого ещё не сделали, нужно скачать архив с исходными кодами VirtualBox нужной версии и распаковать его в удобное место. В качестве рабочего каталога я выбрал C:\Devel\ ; в него я распаковал архив исходных кодов и переименовал полученный каталог в VirtualBox-src .
• Добавление сертификатов
Если у вас нет полноценного сертификата, то рекомендуется создать хотя бы персональный (с ним проще загружать драйверы, чем совсем без подписи). Для этого нужно открыть консоль с повышенными привилегиями и выполнить в ней следующие команды, которые создадут и добавят в личное хранилище два сертификата (SHA-1 и SHA-256):Имя для сертификатов («Roga and Kopyta Ltd») и путь к файлам можно выбирать по своему усмотрению. Также нам потребуются цифровые отпечатки сгенерированных сертификатов. Откройте консоль управления сертификатами (запустите certmgr.msc ), откройте там список персональных сертификатов. Дважды щёлкните на первом из сертификатов «Roga and Kopyta Ltd», в открывшемся диалоге перейдите на вкладку Состав. В поле «Алгоритм подписи» будет указано sha256RSA или sha1RSA. Далее, в самом конце списка будет поле «Отпечаток» со значением в виде последовательности шестнадцатеричных чисел. Скопируйте это значение куда-нибудь. То же самое повторите для второго из сертификатов. Не забудьте отметить, какой из них был SHA-256, а какой — SHA-1.
• Сборка xmllint
• Различные правки VB
Прежде чем приступать к сборке, нам ещё потребуется внести кое-какие правки в исходные коды самого VirtualBox. Полный набор всех изменений выложен мной в виде отдельного патча, который можно просто наложить целиком на дерево VB (вручную или используя утилиту patch , которую потребуется скачать отдельно):
Если всё наложилось корректно, то можно переходить к следующему пункту. Если же что-то не состыковалось и требуется разобраться с конкретным изменением, или просто вас интересуют подробности, какие именно правки были внесены и зачем, читайте далее. Имейте в виду, что описания здесь могут идти в не в том порядке, как в патче. Пути к файлам указаны относительно каталога с исходниками VB, C:\Devel\VirtualBox-src .
- Файл configure.vbs :
- Строка кода:заменяется на:Этот код отвечает за поиск и проверку компилятора, но не учитывает, что вызов cl.exe без аргументов возвращает ошибку (что трактуется как неподходящий компилятор). Добавление параметра « /? » запрашивает вывод справки, и код возврата перестаёт быть ошибочным.
- Теперь переходим к функции CheckForCurlSub и находим в ней следующий код:Этот код выполняет поиск и проверку пути к libcurl, но он рассчитан только на использование динамически линкуемой версии библиотеки и, если не находит соответствующий DLL-файл, ругается некультурными словами. Поскольку мы собираем со статической версией, эту проверку надо поправить, удалив строчку с libcurl.dll , чтобы получилось:
- Следующая функция — CheckForPython , там есть генерация переменной VBOX_BLD_PYTHON :Здесь нужно обратный слэш перед python.exe заменить на прямой: «/python.exe» (иначе некоторые проверки падают; вроде бы, для сборки это некритично, но выглядит неаккуратно).
- В Windows-версии конфигуратор не поддерживает libvpx и libopus, я добавляю их поддержку самостоятельно. Можно было, конечно, просто прохардкодить пути установки библиотек, но я предпочёл, чтобы конфигуратор проверял корректность установки и принимал путь через аргументы командной строки, как уже сделано для остальных компонентов. Поэтому я реализовал две проверочные функции, выглядящие следующим образом:Далее в функции usage , где печатается справка по аргументам, приписывается вывод двух свежедобавленных:В начале функции Main находятся переменные, хранящие всевозможные пути к программам и библиотекам — там создаются две новых переменных:Ниже идёт блок select-case с обработкой параметров командной строки, здесь добавляется код для двух новых аргументов:И наконец, практически в конце файла идёт цепочка вызовов всех проверочных функций, отвечающих за разные компоненты, и туда вписываются вызовы наших новых обработчиков:
- Следующий файл — src\VBox\Runtime\Makefile.kmk . Находим там определения переменных VBoxRT_LIBS.win и VBoxRT-x86_LIBS.win и добавляем к ним crypt32.lib и bcrypt.lib . А именно, код:заменяется на:(не пропустите обратный слэш после delayimp.lib !); и аналогично:заменяется на:Это требуется для успешной линковки библиотеки VBoxRT.dll . Я не до конца разобрался в этой особенности: в дистрибутиве Oracle нет зависимости от библиотеки crypt32.dll , она там загружается динамически во время выполнения, поэтому, теоретически, LIB-файл добавлять не нужно. Однако если этого не сделать, линковщик не может найти некоторые функции и отказывается собирать библиотеку. Предполагаю, что это как-то связано с опциями сборки OpenSSL, но детально не разбирался, проще было добавить эту библиотеку в список. А зависимость от bcrypt.dll появилась при переходе на OpenSSL 1.1.1.
- Если вы используете gSOAP версии 2.8.79 или выше, то требуется подправить файл src\VBox\Runtime\r3\win\VBoxRT-openssl-1.1plus.def , добавив куда-нибудь в общий список следующий набор строк:Этот список определяет набор функций, экспортируемых библиотекой VBoxRT.dll , включающей в себя OpenSSL. При линковке утилиты VBoxWebSrv.exe , в зависимости от используемой версии gSOAP, имеющихся экспортов может оказаться недостаточно, и тогда линковщик дополнительно подключает OpenSSL и тут же начинает материться из-за того, что эта внешняя OpenSSL начинает драться со своей копией, внедрённой внутрь VBoxRT . Добавление отсутствующих экспортов устраняет эту проблему.
- Как я упомянул в начале статьи, сборку гостевых дополнений я пропускаю, но их ISO-образ в составе дистрибутива должен присутствовать. Сборочные файлы VB на такую конструкцию в целом рассчитаны, но они ожидают, что сам ISO-файл магическим образом появится в нужном месте в нужное время. У меня эта магия реализована в файле src\VBox\Makefile.kmk . Находим там блок кода вида:и после него добавляем определение сборочного правила для загрузки образа:Если вы правите файлы самостоятельно, а не готовым патчем, учтите, что строки-команды должны начинаться с символа табуляции.
- Сборка документации — одно из больных мест этого проекта. До версий 6.0 с ней не было никаких проблем, а потом вдруг полезли сплошные несостыковки. Я не знаю, в каких условиях документация собирается в Oracle (возможно, они используют *NIX-подобную систему), но у меня различные компоненты то и дело теряли слэши в путях или, наоборот, получали лишние, и в итоге не могли найти нужные файлы из-за сбившихся соответствий в каталожных файлах. Методом научного тыка мне удалось в итоге подобрать комбинацию, с которой документация собралась без ошибок. В первую очередь была исправлена ошибка отсутствия одного из промежуточных целевых каталогов, из-за чего некоторые файлы не могли быть созданы. Это делается в файле doc\manual\Makefile.kmk в блоке кода:Здесь после строчки с $$(RM) я добавил команду создания целевого каталога:
Битва со слэшами происходит в файле doc\manual\Config.kmk . Нормального решения проблемы мне найти не удалось, поэтому в качестве обходного пути я просто добавил инструкции для обработки «кривых» путей. Сначала после строки:я создаю две новых переменных, которые дублируют существующие переменные, но превращают одиночный слэш после имени диска в тройной:Чуть ниже находится правило для создания каталожного файла:Для каждой строки, использующей переменные VBOX_PATH_MANUAL_SRC и VBOX_PATH_MANUAL_OUTBASE , я добавил такую же, но с заменой этих переменных на определённые выше (строки с префиксом file:// можно пропустить). В итоге получилось:Ещё ниже присутствует правило для генерации вспомогательного каталожного файла, начинающееся со строки:В нём выполняется аналогичная операция (одно из вхождений находится внутри for-макроса, там нужно быть внимательным со скобками). Кроме этого, в начале файла идут несколько строчек, ссылающихся на файлы в подкаталоге common/ :С ними наблюдается обратная проблема — исчезновение слэшей после протокола. Это я смог обойти, поменяв целевой адрес (атрибут uri ) на обычный путь вместо file-протокола, так что, с учётом предыдущей правки, эти строки превратились в следующий набор соответствий: - Если VB собирается с подписыванием, то для большинства исполняемых файлов выставляется флаг принудительной проверки подписи (опция компоновщика /IntegrityCheck ). При наличии полноценного сертификата это не проблема. Однако если у вас самоподписанный сертификат, VB просто откажется запускаться после установки (даже в тестовом режиме). Я модифицировал файл Config.kmk таким образом, чтобы флаг добавлялся только при использовании полноценного сертификата (в качестве критерия «полноценности» я выбрал наличие кросс-сертификата в файле LocalConfig.kmk ; см. ниже). Набор исправлений заключается в следующем.
- Вставлен блок определения переменной VBOX_INTEGRITY_CHECK , которая будет использоваться вместо фиксированной опции:
- Чуть ниже идёт вызов утилиты editbin :В нём безусловный /IntegrityCheck заменяется на новую переменную $(VBOX_INTEGRITY_CHECK) .
- Далее ищутся все вхождения следующего вида:илигде вместо « XXXXXX » могут быть различные имена компонентов. Всего таких вхождений — 6 штук, по три каждого вида. Здесь добавляется условие, что переменная кросс-сертификата определена. В итоге первая строчка превращается, соответственно, в одну из нижеследующих:или
- Ещё один файл, который я поправил, не имеет прямого отношения к сборке VB. Это вспомогательный скрипт src\VBox\Installer\win\Scripts\UnpackBlessedDrivers.cmd , предназначенный для распаковки ZIP-архива с драйверами, полученного из Microsoft после получения подписей под Windows 10. Я там добавил возможность задания пути к утилите signtool , а также избавился от утилиты unzip.exe , реализовав распаковку архива Perl-скриптом. О самой процедуре подписывания я расскажу чуть ниже. Если же вы не планируете получать подпись от Microsoft, то можете просто игнорировать эти правки.
• Файл конфигурации сборки VB
Осталось только создать в корне каталога с исходниками VB файл с именем LocalConfig.kmk , куда прописываются различные пути и параметры сборки. В качестве шаблона можно взять следующий код:В этом шаблоне необходимо кое-что подправить:
- В переменных VBOX_CERTIFICATE_SUBJECT_NAME и VBOX_CERTIFICATE_SHA2_SUBJECT_NAME потребуется указать имена используемых вами сертификатов для подписи SHA-1 и SHA-256, соответственно.
- В переменных VBOX_CERTIFICATE_FINGERPRINT и VBOX_CERTIFICATE_SHA2_FINGERPRINT пропишите цифровые отпечатки, которые были скопированы ранее из консоли управления сертификатами.
- Если у вас не самоподписанный сертификат, а покупной, то удалите строчки с переменными VBOX_CROSS_CERTIFICATE_FILE_ARGS и VBOX_CROSS_CERTIFICATE_SHA2_FILE_ARGS , а в переменных VBOX_CROSS_CERTIFICATE_FILE и VBOX_CROSS_CERTIFICATE_SHA2_FILE (без « _ARGS ») задайте полный путь к файлу кросс-сертификата (без него драйверы не будут считаться подписанными). Его можно найти на сайте компании, выпустившей сертификат, или у Microsoft.
- Для более тонкой настройки подписывания имеется множество других переменных, с помощью которых можно задать хранилище, адрес сервера для наложения временно́й метки или вообще задать произвольный дополнительный набор аргументов для утилиты signtool . В файле Config.kmk под комментарием «Code Signing» можно посмотреть, какие там переменные определяются и как они используются.
- Если вы устанавливали какие-то из программ в каталоги, отличающиеся от моих, нужно поправить пути в соответствующих переменных. Крайне желательно использовать тот же стиль слэшей (прямые/обратные), что приведён в шаблоне для каждой переменной: для некоторых из них это критично.
- Для WiX необходимо указывать путь к исполняемым файлам. В портативной версии это каталог, куда был распакован архив; в установленной версии это подкаталог bin . Обратите внимание, что если путь содержит пробелы, то необходимо преобразовать его в формат 8.3. Для этого можно воспользоваться командой dir /x . Трюк со взятием в кавычки здесь, увы, не работает.
- Переменная VBOX_BUILD_PUBLISHER задаёт брэндированный суффикс в номере версии. По умолчанию это «_OSE» (т. е. продукт имеет версию «6.1.18_OSE»). Здесь вы можете поменять его на что-то другое или даже на пустую строку, чтобы убрать суффикс совсем (если переменная отсутствует, применится суффикс «_OSE»).
Остальные переменные используются в основном для выбора собираемых компонентов. Ну и главная строка, ради которой всё и затевалось, идёт самой первой: отключаем hardening.
Собираем VirtualBox
Ну вот, теперь, наконец, можно и приступать к сборке собственно VirtualBox. Поскольку подписывание драйверов под Windows 10 доступно немногим, я сначала расскажу, как выполняется сборка в «простом» режиме, а дополнительные промежуточные шаги для получения подписи от Microsoft вынесу в отдельный пункт.
- Открываем консоль, выполняем следующие команды:Скрипт configure.vbs проверяет окружение и создаёт файлы конфигурации ( AutoConfig.kmk и env.bat ). Первый запуск kmk выполняет сборку бинарных компонентов и помещает их в каталог out\win.amd64\bin\ . Последняя команда собирает из этих компонентов промежуточный MSI-пакет и итоговый инсталлятор. Важные моменты:
- Слэши в последней команде должны быть обязательно прямыми. С обратными kmk не найдёт сборочные правила.
- Если вы меняли суффикс версии, то «_OSE» в имени файла инсталлятора необходимо поправить на то, что вы задали в переменной VBOX_BUILD_PUBLISHER .
- Ревизию в имени MSI-файла (142142) можно найти в файле Version.kmk в определении переменной VBOX_SVN_REV_VERSION_FALLBACK .
- Даже при наличии полноценного сертификата полученный таким образом дистрибутив не установится в Windows 10, если она загружена с включённым Secure Boot. Для этого драйверы должны быть подписаны непосредственно компанией Microsoft. Сама процедура описана на многих ресурсах и прямого отношения к теме моей статьи не имеет, поэтому здесь я только обозначу ключевые моменты и шаги, необходимые для интеграции процедуры в процесс сборки VB.
- Необходимое условие: у вас должен иметься сертификат категории EV (Extended Validation), обычный здесь уже не подойдёт. Кроме того, вам нужно зарегистрироваться на портале Hardware Dev Center и привязать этот сертификат к аккаунту.
- После завершения сборки бинарных компонентов (первый запуск kmk , без параметров) необходимо создать CAB-архив с драйверами. Для этого в VB имеется шаблон скрипта, который сборочная система к этому моменту подредактировала в соответствии с текущей задачей и положила в подкаталог out\win.amd64\release\repack\ . Нужно перейти туда и запустить следующую команду:По завершении работы скрипта в этом же каталоге появится файл с именем вида VBoxDrivers-6.1.18r142142-amd64.cab .
- Полученный CAB-архив нужно подписать EV-сертификатом. Затем на портале Microsoft Hardware Dev Center создаётся новая заявка, загружается этот подписанный архив, выбирается желаемая целевая система (обязательно 64-битная), и заявка отправляется на выполнение.
- Через несколько минут система должна выдать ZIP-архив, в котором драйверы в дополнение к имеющейся подписи имеют подпись Microsoft, а CAT-файлы сгенерированы заново. Этот архив скачивается и помещается куда-нибудь, где у сборочной системы будет к нему доступ.
- Драйверы в этом архиве разложены по подкаталогам. Требуется все эти файлы извлечь, избавиться от всех этих подкаталогов и полученный набор скопировать в out\win.amd64\release\bin\ , перезаписывая существующие файлы. Для этого удобно воспользоваться другим скриптом в том же каталоге out\win.amd64\release\repack\ , его использование выглядит так:Пути к signtool.exe и ZIP-архиву, разумеется, нужно подставить свои.
- Теперь можно запускать вторую команду kmk , пакующую бинарные компоненты в инсталлятор. Если вы выполняли все действия в той же консоли, что и сборку, не забудьте вернуться в исходный каталог проекта.
Если ни я, ни вы ничего не перепутали, то после всех этих перипетий у вас должен получиться инсталлятор VirtualBox, отличающийся от Oracle-версии только значком исполняемого файла, картинкой в диалоге «О программе» и, конечно же, отключённым hardening’ом. При желании значок и картинку тоже можно поменять, но это тема отдельного разговора.
Для удобства я написал батник, выполняющий все эти шаги автоматически. Если вам регулярно нужно пересобирать пакет, удобнее пользоваться им.
Добавлю ещё лишь пару слов об установке полученного дистрибутива с самоподписанным сертификатом. В современных системах (Windows 8/10) одного лишь включения тестового режима, как оказалось, недостаточно, при установке выводится сообщение о невалидной подписи. Чтобы обойти эту проблему, необходимо добавить использовавшиеся сертификаты в корневое хранилище:
- Откройте свойства скачанного файла дистрибутива: правый щелчок → Свойства, перейдите на вкладку Цифровые подписи. Там будут две подписи от «Roga and Kopyta Ltd»: sha1 и sha256. Выделяем первую, жмём Сведения.
- В открывшемся диалоге жмём кнопку Просмотр сертификата.
- В новом диалоге жмём Установить сертификат.
- Выбираем для установки «Локальный компьютер», нажимаем Далее. Подтверждаем UAC-запрос. Отмечаем пункт «Поместить все сертификаты в следующее хранилище», нажимаем Обзор и выбираем хранилище «Доверенные корневые центры сертификации». Далее, Готово. Сертификат установлен.
- Закрываем все диалоги, кроме самого первого, выделяем подпись sha256, повторяем для неё шаги 2–4.
- Закрываем все диалоги, запускаем установку. Теперь она должна пройти успешно.
Послесловие
Размер статьи оказался неожиданностью для меня самого. Когда я начинал её писать, то намеревался подробно рассказывать, почему на каждом этапе было выбрано то или иное решение, какие конкретно ошибки выскакивают, если не применить очередную правку, и какие могут быть альтернативные подходы к решению этих ошибок. Но постепенно понял, что если бы я всё это описывал, статья получилась бы и вовсе неприподъёмной. Поэтому прошу прощения за встречающийся кое-где стиль «делай так, а почему — не скажу». Сам недолюбливаю такие инструкции, но тут не видел иного выхода. Впрочем, в отдельных местах я всё-таки постарался хотя бы вкратце пояснить суть происходящего.
Огромное количество аспектов сборочной системы VB осталось за кадром: как из-за нежелания раздувать текст, так и по причине моей лени, когда, найдя какой-то обходной путь для очередной проблемы, я не лез в глубины системы сборки, а поскорее переходил к следующему этапу. В конце концов, моей главной задачей было не найти оптимальный путь, а собрать, наконец, свой вариант актуального VirtualBox’а: сидеть на 4.3.12 уже поднадоело, но я не мог обновлять один из своих основных рабочих инструментов на нечто, что в любой момент может просто отказаться работать на неопределённый срок. Правда, по мере выхода новых версий я иногда узнаю о каких-нибудь новых возможностях сборочной системы и, опробовав их, добавляю соответствующую информацию в статью.
Надеюсь всё же, что, несмотря на недостатки, эта статья окажется кому-нибудь полезной. Для тех, кому лень поднимать всё вышеописанное нагромождение программ, но интересно расковырять получающийся в итоге дистрибутив, я выложил инсталлятор на Яндекс-диск: 6.1.18. Все драйверы в них (да и остальные файлы) подписаны недоверенным сертификатом, так что в 64-битной Windows этот вариант VB заработает только в тестовом режиме. Если имеются вопросы, пожелания, предложения — велкам в комментарии или в личку. И да пребудет с вами Open Source!