Установка Windows 7 поверх PXE из Linux без использования WAIK

1. Обзор

1.1. Введение

В статье приводится описание, как из Linux по сети (PXE) развернуть для работы систему Windows 7. Не нужно пользоваться «рабочим компьютером» с установленным пакетом WAIK (Windows Automated Installation Kit — пакет автоматической установки Windows), нужна лишь система Linux. Я использую 32-битный инсталлятор Centos 5.3, но если вы разбираетесь в том, что делаете, то я уверен, что вы сможете выполнить эту работу на том варианте Linux, который вы лично предпочитаете использовать. Для этого вам нужно следующее:

• сервер tftp
• сервер dhcp
• сервер samba
• пакет ris для linux
• PXELinux
• hivex
• мой скрипт (wimlib/bcdedit.pl/getbcdlocation.sh)

Последние четыре пакета, объединенные вместе в один пакет, вы можете скачать с сайта www.ultimatedeployment.org. Скачайте пакет отсюда .

Все остальное либо есть в вашем дистрибутиве Linux, либо может быть достаточно просто установлено с помощью менеджера пакетов вашего дистрибутива Linux (um, apt-get и т.д.).

Загрузите пакет и распакуйте его корневой каталог системы. Будет создан каталог /work, в котором все будет происходить. В остальной части этого документа я предполагаю, что вы это уже сделали и что там же находятся скрипты и конфигурационные файлы. Конечно, вы всегда можете распаковать его в другое место, куда захотите .

Отказ от ответственности: Настоящий подход все еще находится в стадии разработки, и в нем могут быть (очевидные) ошибки. В действительности здесь описывается, как я развернул систему Windows 7 для работы в UDA. Это моя рабочая среда, поэтому дайте мне знать, если у вас есть исправления или другие советы и подсказки.

1.2. Что должны получить

Как только вы закончите подготавливать вашу файловую систему, она должна выглядеть следующим образом. Большинство файлов уже заранее подготовлены в архиве, но, конечно, не те, которые я не должен был самостоятельно распространять, например, двоичные файлы загрузки windows. В данном руководстве будет рассказано, откуда их получить или как их найти на вашем носителе с инсталлятором windows 7.

1.3. Ссылки

Я нашел в сети интересную информацию, объединил ее и при помощи некоторых проб и ошибок придумал этот метод. Вот некоторые ссылки для получения дополнительной информации.

Дайте мне знать, если вы найдете более интересные статьи! (пожалуйста, сделайте это в форуме на www.ultimatedeployment.org ).

2. Конфигурирование и запуск сервисов

2.1 dhcp

Запустите сервер dhcp следующим образом

Файл dhcpd.conf должен выглядеть приблизительно следующим образом. Если захотите, вы можете внести изменения в ip-адреса, выделенные красным цветом:

Файл pxelinux.0 является загрузочным файлом, который запускает весь процесс pxe. Когда клиент загружается, этот файл загружается первым и, в свою очередь, загружает конфигурационный файл pxelinux.cfg/default. Этот файл выглядит следующим образом:

2.2 tftpd

Запустите демон tftp следующим образом

Эта команда запускает tftpd со следующими параметрами:

Конфигурационный файл /work/conf/tftpd.conf лишь заменяется обратный слэш на прямой слэш:

2.3 samba

Запустите сервер samba следующим образом

Убедитесь, что каталог /work/sambashare экспортируется как sambashare REMINST. Это важная часть файла smb.conf:

2.4 binl

Запустите сервер binl следующим образом

Эта команда запустит сервис binl со следующими параметрами:

Здесь журнальный файл важен, поскольку в дальнейшем он должен быть прочитан. Сервис binl определяет, какой загрузочный файл клиент скачал последним, для этого выполняется следующий скрипт. Скрипт ищет журнальный файл tftpd и возвращает место, где расположен файл bcd, который находится в том же самом каталоге, что и найденный файл wdsnbp.com. Это необходимо, т.к. мы хотим знать, какой вариант был выбран в меню загрузки PXE.

3. Подготовка загрузочных файлов Windows

3.1. Импорт загрузочного файла, используемого по умолчанию

Прежде всего нам нужно смонтировать установочный DVD. Я смею предположить, что он находится в плейере DVD, известным как /dev/cdrom. Вы должны смонтировать его следующим образом:

Если у вас есть файл iso, то вы должны сделать что-то вроде следующего:

Как только вы это сделаете, файлы, расположенные на DVD (внутри образа), можно будет опубликовать с помощью samabashare. Затем нам нужно извлечь отдельные файлы из файла boot.wim, который находится на DVD в каталоге /sources. Они должны быть в самом конце каталога /work/tftproot, поэтому мы сначала выполняем следующее:

Обратите внимание, что мы извлекли файл pxeboot.n12, а затем переименовали его в pxeboot.com!

3.2. Подготовка файла WIM

Что ж, теперь нам нужно создать файл winpe.wim. Мы делаем следующее:

3.2.1. Создаем файл winpehl.ini

В нем должно быть что-то вроде следующего:

Убедитесь, что он имеет формат dos (а не формат unix)

3.2.2. Создаем скрипт install.cmd

Создайте скрипт install.cmd, который позаботится о установке сразу, как будет запущен Winpe:

3.2.3. Добавляем сетевые драйверы

Идем дальше. Сетевые драйверы являются трудной темой. Вам нужны будут сетевые драйверы, которые поставляются для вашей сетевой карты, их можно скачать с сайта поставщика сетевой карты, а некоторые из них могут быть уже в дистрибутиве Windows 7 WINPE на инсталляционном носителе. Я предполагаю, что вы будете с помощью PXE (загрузка по сети) загружать виртуальную машину vmware с сетевой картой AMD (которая во многих случаях, является сетевой картой, используемой по умолчанию для новой виртуальной машины).

Если вы загрузили виртуальную машину и, когда загрузка идет из сети, то сообщается о сетевой карте Intel E1000, вам придется остановить виртуальную машину, удалить следующие строки из файла .vmx и перезапустить виртуальную машину.

Если вы теперь запустите виртуальную машину, то вам будет сообщено, что есть сетевая карта AMD . Так что теперь нам нужно драйвера windows PE для этой сетевой карты AMD. Есть станица , на которой вы можете узнать откуда их можно скачать:

Для windows PE вы можете использовать драйвера windows XP. В общем, вам нужен файл .inf и файл .sys. Файл inf обычно содержит список файлов идентификаторов сетевое устройств и соответствующих им драйверов .sys). Если вы не знаете, сетевая с каким идентификатором используется в вашей системе, то просто скопируйте в каталог /work/wim несколько драйверов (файлы inf и sys).

3.2.4. Создаем файл actionfile

Ниже указаны действия, которые нам нужно выполнить, когда из файла boot.wim создается файл winpe.wim. Вы можете захотеть отредактировать список драйверов, которые указываются в файле /work/wim/actionfile.txt. Этот файл может выглядеть следующим образом:

3.2.5. Создаем файл WIM

Теперь мы можем создать файл winpe.wim

cd /work/wim /work/bin/updatewim /work/sambashare/win7/sources/boot.wim /work/tftproot/winpe.wim /work/wim/actionfile.txt

3.3. Создание загрузочных файлов для конкретных систем

Сначала нам нужно инструментальное средство hivex. Архивы RPM, которые я использую, находятся в этом пакете .

Возможно, что для вашего любимого дистрибутива Linux вам потребуются другие пакеты с дистрибутивами. Нам нужны эти инструментальные средства для того, чтобы иметь возможность отредактировать файлы windows BCD (Boot Cofiguration Data — конфигурационные данные для загрузки). Теперь мы выполняем три операции для обеих систем, которые мы хотим установить дистанционно:

• Копируем данные Boot Cofiguration Data с установочного DVD в загрузочный каталог систем pxe
• Изменяем их для того, чтобы получить PXE BCD
• Копирует в этот каталог программу сетевой загрузки сервиса развертывания Windows (wdsnbp.com) и также и переименовываем ее в wdsnbp.0

Вы можете легко выполнить эти операции для более, чем двух систем .

4. Подготовка файлов автоматической установки

4.1. Поддерживаемый язык

Сначала узнаем, какие языки поддерживаются на данном установочном носителе.

Вы должны найти что-то вроде следующего

По-видимому, на этом DVD есть язык en-US (и еще en-us).

4.2. Определение версии ОС

Теперь нам нужно проверить, какая версия поддерживается установочным DVD

Вы должны получить нечто вроде следующего:

Так что это Windows 7 Ultimate OEM DVD с лицензией (non Volume). Нам нужна эта информация для того, чтобы иметь возможность выбрать образ в следующем разделе:

4.3. Выбор образа подходящего инсталлятора

Сначала мы сделаем дамп информации XML файла install.wim:

Вы должны получить приблизительно следующее:

Поскольку мы знаем с каким языком и какой версией windows 7 мы имеем дело, мы можем отредактировать файлы автоматической установки. Я выделил третий образ, поскольку это версия Ultimate Edition, которую мы нашли в предыдущем разделе. Это Architecture 0, что означает — x86.

4.4. Создаем/редактируем файлы автоматической установки

Файл автоматической установки может выглядеть, например, следующим образом (вероятно, вы захотите изменить значения, выделенные красным цветом):

Итак, как только вы это сделаете, вы должны быть в состоянии загрузить (загрузка pxe) новую систему, и вы должны иметь возможность выбирать из двух систем, которые вы настроили для автоматического развертывания. Если этого сделать не удастся, то, пожалуйста, перейдите к следующему разделу «Решение возникших проблем» и поделитесь своим опытом на форуме на сайте ultimatedeployment.org .

5. Решение возникших проблем

Ниже приведен упрощенный обзор процесса загрузки, через который проходят клиенты PXE, когда используется этот метод.

• C обозначает клиентскую систему (система, которая должна быть развернута)
• S обозначает сервер (систему, на которой находятся конфигурационные файлы и на которой запущены сервисы, позволяющие установить клиентскую систему)

Сервер ищет в файле находит в tftpd.log, откуда клиент загрузил свой файл wdsnbp и предполагает, что файл BCD находится в том же самом каталоге.

Клиент читает файл BCD и определяет, откуда нужно скачивать файлы boot.sdi и winpe.wim

Затем клиент загружается в Windows PE. Когда это будет сделано, то от нас потребуется подготовить следующее:

1. Найти в реестре адрес IP сервера загрузки
2. Найти в реестре конкретные данные о загрузке
3. Загрузить сетевые драйверы и запустить сервис сети
4. Переместить файлы setup.exe и sources\setup.exe на прежнее место
5. Подключиться через Samba к серверу загрузки
6. Разбить диск на разделы с помощью файла diskpart, который можно найти через samba на сервере загрузки
7. Переместить файлы setup.exe и sources\setup.exe на прежнее место
8. Удалить из реестра ответ PXE binl для того, чтобы предотвратить установку WDS вместо обычной установки
9. Запустить setup.exe с файлом автоматической установки, который можно найти на сервере загрузки

Когда возникают проблемы, то, очевидно, что нужно заглянуть в следующие журнальные файлы:

• журнальный файл tftpd (/work/log/tftpd.log)
• журнальный файл dhcpd (/var/log/messages)
• журнальный файл binl (/work/log/binl.log)

Если я найду дополнительную информацию, то я ее добавлю.

Dual boot with Windows

This is an article detailing different methods of Arch/Windows coexistence.

Contents

Important information

Windows UEFI vs BIOS limitations

Microsoft imposes limitations on which firmware boot mode and partitioning style can be supported based on the version of Windows used:

This article or section needs expansion.

• Windows XP both x86 32-bit and x86_64 (also called x64) (RTM and all Service Packs) versions do not support booting in UEFI mode (IA32 or x86_64) from any disk (MBR or GPT) OR in BIOS mode from GPT disk. They support only BIOS boot and only from MBR disk.
• Windows Vista or 7x86 32-bit (RTM and all Service Packs) versions support booting in BIOS mode from MBR disks only, not from GPT disks. They do not support x86_64 UEFI or IA32 (x86 32-bit) UEFI boot. They support only BIOS boot and only from MBR disk.
• Windows Vista RTM x86_64 (only RTM) version support booting in BIOS mode from MBR disks only, not from GPT disks. It does not support x86_64 UEFI or IA32 (x86 32-bit) UEFI boot. It supports only BIOS boot and only from MBR disk.
• Windows Vista (SP1 and above, not RTM) and Windows 7x86_64 versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR disk only. They do not support IA32 (x86 32-bit) UEFI boot from GPT/MBR disk, x86_64 UEFI boot from MBR disk, or BIOS boot from GPT disk.
• Windows 8/8.1 x86 32-bit support booting in IA32 UEFI mode from GPT disk only, OR in BIOS mode from MBR disk only. They do not support x86_64 UEFI boot from GPT/MBR disk, x86_64 UEFI boot from MBR disk, or BIOS boot from GPT disk. On market, the only systems known to ship with IA32 (U)EFI are some old Intel Macs (pre-2010 models?) and Intel Atom System-on-Chip (Clover trail and Bay Trail) Windows Tablets. in which it boots ONLY in IA32 UEFI mode and ONLY from GPT disk.
• Windows 8/8.1x86_64 versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR disk only. They do not support IA32 UEFI boot, x86_64 UEFI boot from MBR disk, or BIOS boot from GPT disk.

In case of pre-installed Systems:

• All systems pre-installed with Windows XP, Vista or 7 32-bit, irrespective of Service Pack level, bitness, edition (SKU) or presence of UEFI support in firmware, boot in BIOS/MBR mode by default.
• MOST of the systems pre-installed with Windows 7 x86_64, irrespective of Service Pack level, bitness or edition (SKU), boot in BIOS/MBR mode by default. Very few recent systems pre-installed with Windows 7 are known to boot in x86_64 UEFI/GPT mode by default.
• ALL systems pre-installed with Windows 8/8.1 boot in UEFI/GPT mode. The firmware bitness matches the bitness of Windows, ie. x86_64 Windows 8/8.1 boot in x86_64 UEFI mode and 32-bit Windows 8/8.1 boot in IA32 UEFI mode.

The best way to detect the boot mode of Windows is to do the following[1]:

• Boot into Windows
• Press Win+R keys to start the Run dialog
• In the Run dialog type msinfo32.exe and press Enter
• In the System Information windows, select System Summary on the left and check the value of BIOS mode item on the right
• If the value is UEFI , Windows boots in UEFI/GPT mode. If the value is Legacy , Windows boots in BIOS/MBR mode.

In general, Windows forces type of partitioning depending on the firmware mode used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If Windows is booted in Legacy BIOS mode, it can be installed only to an MBR disk. This is a limitation enforced by Windows installer, and as of April 2014 there is no officially (Microsoft) supported way of installing Windows in UEFI/MBR or BIOS/GPT configuration. Thus Windows only supports either UEFI/GPT boot or BIOS/MBR configuration.

Such a limitation is not enforced by the Linux kernel, but can depend on which boot loader is used and/or how the boot loader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since installation procedure of boot loader depends on the firmware type and disk partitioning configuration. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, ie. either go for UEFI/GPT boot or BIOS/MBR boot. See https://support.microsoft.com/kb/2581408 for more information.

Install media limitations

Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) provide only IA32 UEFI firmware without Legacy BIOS (CSM) support (unlike most of the x86_64 UEFI systems), due to Microsoft Connected Standby Guidelines for OEMs. Due to lack of Legacy BIOS support in these systems, and the lack of 32-bit UEFI boot in Arch Official Install ISO (FS#53182), the official install media cannot boot on these systems. See Unified Extensible Firmware Interface#UEFI firmware bitness for more information and available workarounds.

Bootloader UEFI vs BIOS limitations

Most of the linux bootloaders installed for one firmware type cannot launch or chainload bootloaders of the other firmware type. That is, if Arch is installed in UEFI/GPT or UEFI/MBR mode in one disk and Windows is installed in BIOS/MBR mode in another disk, the UEFI bootloader used by Arch cannot chainload the BIOS installed Windows in the other disk. Similarly if Arch is installed in BIOS/MBR or BIOS/GPT mode in one disk and Windows is installed in UEFI/GPT in another disk , the BIOS bootloader used by Arch cannot chainload UEFI installed Windows in the other disk.

The only exceptions to this are GRUB in Apple Macs in which GRUB in UEFI mode can boot BIOS installed OS via appleloader command (does not work in non-Apple systems), and rEFInd which technically supports booting legacy BIOS OS from UEFI systems, but does not always work in non-Apple UEFI systems as per its author Rod Smith.

However if Arch is installed in BIOS/GPT in one disk and Windows is installed in BIOS/MBR mode in another disk, then the BIOS boot loader used by Arch CAN boot the Windows in the other disk, if the boot loader itself has the ability to chainload from another disk.

Windows Setup creates a 100 MiB EFI system partition (except for Advanced Format 4K native drives where it creates a 260 MiB ESP), so multiple kernel usage is limited. Workarounds include:

• Mount ESP to /efi and use a boot loader that has file system drivers and is capable of launching kernels that reside on other partitions.
• Expand the EFI system partition, typically either by decreasing the Recovery partition size or moving the Windows partition (UUIDs will change).
• Backup and delete unneeded fonts in esp/EFI/Microsoft/Boot/Fonts/ [2].
• Backup and delete unneeded language directories in esp/EFI/Microsoft/Boot/ (e.g. to only keep en-US ).

UEFI Secure Boot

All pre-installed Windows 8/8.1 systems by default boot in UEFI/GPT mode and have UEFI Secure Boot enabled by default. This is mandated by Microsoft for all OEM pre-installed systems.

Arch Linux install media does not support Secure Boot. See Secure Boot#Booting an installation medium.

It is advisable to disable UEFI Secure Boot in the firmware setup manually before attempting to boot Arch Linux. Windows 8/8.1 SHOULD continue to boot fine even if Secure boot is disabled. The only issue with regards to disabling UEFI Secure Boot support is that it requires physical access to the system to disable secure boot option in the firmware setup, as Microsoft has explicitly forbidden presence of any method to remotely or programmatically (from within OS) disable secure boot in all Windows 8/8.1 pre-installed systems

Fast Startup and hibernation

There are two OSs that can be hibernated, you can hibernate Windows and boot Linux (or another OS), or you can hibernate Linux and boot Windows, or hibernate both OSs.

For the same reason, if you share one EFI System Partition between Windows and Linux, then the EFI System Partition may be damaged if you hibernate (or shutdown with Fast Startup enabled) and then start Linux, or hibernate Linux and then start Windows.

ntfs-3g added a safe-guard to prevent read-write mounting of hibernated NTFS filesystems, but the NTFS driver within the Linux kernel has no such safeguard.

Windows cannot read filesystems such as ext4 by default that are commonly used for Linux. These filesystems do not have to be considered, unless you install a Windows driver for them.

Windows settings

Fast Startup is a feature in Windows 8 and above that hibernates the computer rather than actually shutting it down to speed up boot times.

There are multiple options regarding the Windows settings for Fast Startup and hibernation that are covered in the next sections.

• disable Fast Startup and disable hibernation
• disable Fast Startup and enable hibernation
• enable Fast Startup and enable hibernation

The procedure of disabling Fast Startup is described here for Windows 8 and here for Windows 10. In any case if you disable a setting, make sure to disable the setting and then shut down Windows, before installing Linux; note that rebooting is not sufficient.

Disable Fast Startup and disable hibernation

This is the safest option, and recommended if you are unsure about the issue, as it requires the least amount of user awareness when rebooting from one OS into the other. You may share the same EFI System Partition between Windows and Linux.

Disable Fast Startup and enable hibernation

This option requires user awareness when rebooting from one OS into the other. If you want to start Linux while Windows is hibernated, which is a common use case, then

• you must use a separate EFI System Partition (ESP) for Windows and Linux, and ensure that Windows does not mount the ESP used for Linux. As there can only be one ESP per drive, the ESP used for Linux must be located on a separate drive than the ESP used for Windows. In this case Windows and Linux can still be installed on the same drive in different partitions, if you place the ESP used by linux on another drive than the Linux root partition.
• you can not read-write mount any filesystem in Linux, that is mounted by Windows while Windows is hibernated. You should be extremely careful about this, and also consider Automount behaviour.
• If you shut down Windows fully, rather than hibernating, then you can read-write mount the filesystem.

Enable Fast Startup and enable hibernation

The same considerations apply as in case «Disable Fast Startup and enable hibernation», but since Windows can not be shut down fully, only hibernated, you can never read-write mount any filesystem that was mounted by Windows while Windows is hibernated.

Windows filenames limitations

Windows is limited to filepaths being shorter than 260 characters.

Windows also puts certain characters off limits in filenames for reasons that run all the way back to DOS:

• (less than)
• > (greater than)
• : (colon)
• » (double quote)
• / (forward slash)
• \ (backslash)
• | (vertical bar or pipe)
• ? (question mark)
• * (asterisk)

These are limitations of Windows and not NTFS: any other OS using the NTFS partition will be fine. Windows will fail to detect these files and running chkdsk will most likely cause them to be deleted. This can lead to potential data-loss.

NTFS-3G applies Windows restrictions to new file names through the windows_names option: ntfs-3g(8) § Windows_Filename_Compatibility (see fstab).

Installation

The recommended way to setup a Linux/Windows dual booting system is to first install Windows, only using part of the disk for its partitions. When you have finished the Windows setup, boot into the Linux install environment where you can create and resize partitions for Linux while leaving the existing Windows partitions untouched. The Windows installation will create the EFI system partition which can be used by your Linux boot loader.

Windows before Linux

BIOS systems

Using a Linux boot loader

You may use any multi-boot supporting BIOS boot loader.

Using Windows boot loader

With this setup the Windows bootloader loads GRUB which then boots Arch.

Windows Vista/7/8/8.1 boot loader

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

The factual accuracy of this article or section is disputed.

In order to have the Windows boot loader see the Linux partition, one of the Linux partitions created needs to be FAT32 (in this case, /dev/sda3 ). The remainder of the setup is similar to a typical installation. Some documents state that the partition being loaded by the Windows boot loader must be a primary partition but I have used this without problem on an extended partition.

When installing the GRUB boot loader, install it on your /boot partition rather than the MBR.

Reboot and enjoy. In my case I’m using the Windows boot loader so that I can map my Dell Precision M4500’s second power button to boot Linux instead of Windows.

UEFI systems

If you already have Windows installed, it will already have created some partitions on a GPT-formatted disk:

• a Windows Recovery Environment partition, generally of size 499 MiB, containing the files required to boot Windows (i.e. the equivalent of Linux’s /boot ),
• an EFI system partition with a FAT32 filesystem,
• a Microsoft Reserved Partition, generally of size 128 MiB,
• a Microsoft basic data partition with a NTFS filesystem, which corresponds to C: ,
• potentially system recovery and backup partitions and/or secondary data partitions (corresponding often to D: and above).

Using the Disk Management utility in Windows, check how the partitions are labelled and which type gets reported. This will help you understand which partitions are essential to Windows, and which others you might repurpose. The Windows Disk Management utility can also be used to shrink Windows (NTFS) partitions to free up disk space for additional partitions for Linux.

You can then proceed with partitioning, depending on your needs.

Mind that an additional EFI system partition should not be created, as it may prevent Windows from booting. Simply mount the existing partition.

The boot loader needs to support chainloading other EFI applications to do dual boot Windows / Linux.

Computers that come with newer versions of Windows often have Secure Boot enabled. You will need to take extra steps to either disable Secure Boot or to make your installation media compatible with secure boot (see above and in the linked page).

Linux before Windows

Even though the recommended way to setup a Linux/Windows dual booting system is to first install Windows, it can be done the other way around. In contrast to installing Windows before Linux, you will have to set aside a partition for Windows, say 40GB or larger, in advance. Or have some unpartitioned disk space, or create and resize partitions for Windows from within the Linux installation, before launching the Windows installation.

UEFI firmware

Windows will use the already existing EFI system partition. In contrast to what was stated earlier, it is unclear if a single partition for Windows, without the Windows Recovery Environment and without Microsoft Reserved Partition, will not do.

Follows an outline, assuming Secure Boot is disabled in the firmware.

1. Boot into windows installation. Watch to let it use only the intend partition, but otherwise let it do its work as if there is no Linux installation.
2. Follow the #Fast Startup and hibernation section.
3. Fix the ability to load Linux at start up, perhaps by following #Cannot boot Linux after installing Windows. It was already mentioned in #UEFI systems that some Linux boot managers will autodetect Windows Boot Manager. Even though newer Windows installations have an advanced restart option, from which you can boot into Linux, it is advised to have other means to boot into Linux, such as an arch installation media or a live CD.

Troubleshooting

Couldn’t create a new partition or locate an existing one

Cannot boot Linux after installing Windows

Restoring a Windows boot record

By convention (and for ease of installation), Windows is usually installed on the first partition and installs its partition table and reference to its bootloader to the first sector of that partition. If you accidentally install a bootloader like GRUB to the Windows partition or damage the boot record in some other way, you will need to use a utility to repair it. Microsoft includes a boot sector fix utility FIXBOOT and an MBR fix utility called FIXMBR on their recovery discs, or sometimes on their install discs. Using this method, you can fix the reference on the boot sector of the first partition to the bootloader file and fix the reference on the MBR to the first partition, respectively. After doing this you will have to reinstall GRUB to the MBR as was originally intended (that is, the GRUB bootloader can be assigned to chainload the Windows bootloader).

If you wish to revert back to using Windows, you can use the FIXBOOT command which chains from the MBR to the boot sector of the first partition to restore normal, automatic loading of the Windows operating system.

Of note, there is a Linux utility called ms-sys (package ms-sys AUR in AUR) that can install MBR’s. However, this utility is only currently capable of writing new MBRs (all OS’s and file systems supported) and boot sectors (a.k.a. boot record; equivalent to using FIXBOOT ) for FAT file systems. Most LiveCDs do not have this utility by default, so it will need to be installed first, or you can look at a rescue CD that does have it, such as Parted Magic.

First, write the partition info (table) again by:

Next, write a Windows 2000/XP/2003 MBR:

Then, write the new boot sector (boot record):

ms-sys can also write Windows 98, ME, Vista, and 7 MBRs as well, see ms-sys -h .

The EFI system partition created by Windows Setup is too small

Windows Setup creates a 100 MiB EFI system partition (except for Advanced Format 4K native drives where it creates a 260 MiB ESP). This is generally too small to fit everything you need. You can try different tools to resize this partition, but there are usually other partitions in the way, making it, at the very least, difficult. One option is to use the Arch install media to create a single EFI system partition of your preferred size before you install Windows on the drive. Windows Setup will use the EFI system partition you made instead of creating its own.