Jump to content

Dual boot with Windows

From ArchWiki


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

Background

UEFI vs BIOS limitations

Windows

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

Note The following points only list configurations supported by the Windows Setup even though Windows itself may still work on these unsupported configurations. A good example of this is Windows 11 which still works on a BIOS/MBR configuration once the Windows Setup check is bypassed.
  • Windows 8/8.1 and 10 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, which boot ONLY in IA32 UEFI mode and ONLY from GPT disk.
  • Windows 8/8.1 and 10 x86_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.
  • Windows 11 only supports x86_64 and a boot in UEFI mode from GPT disk.

In case of pre-installed systems, all systems pre-installed with Windows 8/8.1, 10 and 11 boot in UEFI/GPT mode. Up to Windows 10, the firmware bitness matches the bitness of Windows, ie. x86_64 Windows boot in x86_64 UEFI mode and 32-bit Windows boot in IA32 UEFI mode.

An easy 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 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 Setup, 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.

Tip Windows 10 version 1703 and newer supports converting from BIOS/MBR to UEFI/GPT using MBR2GPT.EXE.

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 when dual-booting Windows and Linux from the same disk, since the boot loader installation procedure 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, i.e. either go for UEFI/GPT boot or BIOS/MBR boot. See https://support.microsoft.com/kb/2581408 for more information.

Boot loader

Most of the Linux boot loaders installed for one firmware type cannot launch or chainload boot loaders 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 boot loader 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 boot loader 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.

Note To dual-boot with Windows on same disk, Arch should follow the same firmware boot mode and partitioning combination used by the Windows installation.

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

COMPRESSION="xz"
COMPRESSION_OPTIONS=(-9e)
MODULES_DECOMPRESS="yes"

Secure Boot

All pre-installed Windows 8/8.1, 10 and 11 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 yet, as explained in Secure Boot#Booting an installation medium.

While it is possible to make the installation medium compatible with Secure Boot either by repacking the ISO or editing the installation medium, it remains advisable to disable UEFI Secure Boot in the firmware setup manually before attempting the installation, to prevent issues (dependent on manufacturer and computer model) booting the installation medium. If Secure Boot is disabled during installation and later re-enabled, the system may then refuse to boot the installed system unless it was configured for Secure Boot beforehand.

Windows 8/8.1, 10 and 11 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 and above pre-installed systems.

Note
  • If Windows used BitLocker and stored the key in the TPM for automatic unlock on boot, it fails to boot when Secure Boot is disabled, instead showing a BitLocker recovery screen. This is not permanent however, and you can easily boot Windows again by simply re-enabling Secure Boot.
  • On Windows 11, disabling Secure Boot after install will not cause problems as long as TPM is working normally.
  • However, disabling Secure Boot may also cause Windows to disable all Windows authentication methods based on Windows Hello, which are not Windows passwords, such as PIN, face recognition, fingerprint, image password, and security key, which can be used to sign into and grant administrator permissions in Windows. If Secure Boot is disabled, you will need to know the Windows passwords used to sign in to Windows to avoid being locked out, and then you can disable and re-enable each of these methods individually. Re-enabling Secure Boot will not automatically re-enable these authentication methods. Enabling Secure Boot after re-enabling these authentication methods will also cause Windows to disable them.

This article or section is a candidate for merging with Secure Boot.

Notes: The following list item is more related to Secure Boot implementation than dual-booting. (Discuss in Talk:Dual boot with Windows)

The factual accuracy of this article or section is disputed.

Reason: Needs wording improvement, e.g. "If the option is not present, it is often enabled" is confusing. No sources on 3rd Party CA disabling Windows Hello. (Discuss in Talk:Dual boot with Windows)
  • Some UEFI implementations, in addition to letting secure boot be disabled, also have an option to enable Microsoft 3rd Party UEFI CA. If this option is not present, it is often enabled by default, allowing you to use Linux secure boot-enabled installation media with secure boot on. If this option is present, it is disabled by default and Linux can not be booted unless this option is enabled, even if Linux supports secure boot. Windows hello authentication will start erroring out if this option is enabled, at which point Windows hello will need to be disabled and enabled again. Some laptops will always have this option disabled even if not present, so if booting with secure boot on is not possible, Linux will only boot with secure boot disabled due to the manufacturer's firmware.
Warning

If you intend to use Secure Boot for Linux as well, you may need to perform changes to the Secure Boot settings. Those changes prevent unlocking the BitLocker disk without the recovery key, leading to permanent data loss. BitLocker uses a Trusted Platform Module for its full disk encryption; specifically by binding to PCR 7. Since PCR 7 hashes all the certificates enrolled with Secure Boot, in addition to hashing the specific certificates used, changing the Secure Boot database will change the observed PCR 7 values and thus prevent BitLocker from unlocking the disk.

Before proceeding, check if this is the case and save your BitLocker recovery key if not already done. This is especially important if Windows was preinstalled by the vendor.

Additionally, it is advisable to suspend BitLocker before changing anything about Secure Boot. For instance, this may be performed with the `Suspend-BitLocker` cmdlet in PowerShell.

Furthermore, please note that Windows refuses to use PCR 7 binding if any non-Microsoft certificates were used in the boot chain. That is to say, you can't launch Windows through an entry in a Linux boot manager like systemd-boot or GRUB. Instead, you will have to use the UEFI boot menu of your BIOS. However, not having PCR 7 binding available only breaks BitLocker and S0ix (modern standby) for Windows.

Fast Startup and hibernation

There are two operating systems 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.

Warning Data loss or filesystem corruption can occur when dual-booting between Windows and another operating system, like Linux, if either OS hibernates instead of fully shutting down. When a system hibernates, it saves the current session to disk and assumes no other system will modify the files or filesystem. If you then boot into another OS and access or change files on a shared filesystem (such as NTFS, which both Windows and Linux can read/write), the original system may restore outdated or inconsistent data upon resuming from hibernation.[3] This can lead to corrupted files or lost work. Be especially cautious, as Windows may enter a hybrid shutdown mode (a form of hibernation) even when "Shut Down" is selected. See the section on #Windows settings for how to ensure a full shutdown

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) Windows and then start Linux, or hibernate Linux and then start Windows. Check the respective section in EFI system partition for mitigation strategies.

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 in the tutorials for Windows 8, Windows 10 and Windows 11. 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.

In a Windows command-line shell with administrator privileges: 

> powercfg /H off
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.
Note You can avoid this issue for a drive by mounting a drive as an external drive in Windows and ejecting the drive in Windows before hibernating.
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.

Note Windows updates may re-enable Fast Startup, as reported in [4].

Windows filename 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 set up 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. If you are installing Windows from scratch, do note that the EFI System partition created by Windows Setup will be too small for most use cases and may need to be expanded to as much as 4 GB or even more. See #The EFI system partition created by Windows Setup is too small.

Windows before Linux

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

Using the Disk Management utility in Windows, check how the partitions are labelled and which type gets reported. The Reserved Partition may not be visible in the Disk Management utility in which case it can be identified using diskpart in windows cmd. 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.

Warning The first 4 partitions in the above list are essential, do not delete them.

Windows 11 systems, and Windows 10 systems that have received updates since 2020, generally have BitLocker enabled by default on the C: drive even if it appears off in Settings. This prevents the Windows partition from being resized by Linux installers or utilities. The Windows partition can still be resized by Windows with BitLocker enabled, however Windows will sometimes not allow a partition to be shrunk when Linux programs such as GParted can. Thus if resizing the Windows partition is not possible within Windows, you will need to go to Windows settings and turn off device encryption. This will turn off BitLocker, which normally encrypts the Windows C: partition. This is usually not a problem on personal PCs, but cybersecurity departments in large businesses may see this as a cybersecurity risk due to the lack of encryption for the Windows partition, when disabled on a corporate PC. If you don't see a toggle for disabling device encryption, ensure you are logged into an account with administrative privileges and try again.

The factual accuracy of this article or section is disputed.

Reason: Last sentence is after Hello methods getting disabled, but "in spite of this" doesn't clearly connect to anything: what's the "this" being contrasted, and what's "another method to authenticate" referring to? Needs rewriting for clarity or is redundant and can be removed. (Discuss in Talk:Dual boot with Windows)

Disabling BitLocker may also disable all authentication methods for signing into Windows that are not a Windows password, such as PIN, Picture password, fingerprint, security key and face recognition, across all Windows user accounts, including administrator accounts. In spite of this, Windows allows disabling BitLocker without a password, using another method to authenticate.

Ensure you know or have access to the password(s) used to sign into Windows before disabling BitLocker, to avoid being locked out of Windows or the Windows administrator account.

If the Windows C: drive is located in an NVMe drive, disabling BitLocker can take less than an hour for drives up to 512 GiB in size. Decryption speed is dependent on drive speed, drive size and processor decryption speed. The Windows partition will then be resizeable by Linux unless the partition is full, or fast startup is enabled. The Windows task manager on the Performance, then Disk sections, will show the type of drive such as NVMe, on Disk 0 for the Windows C: drive.

You can then proceed with partitioning, depending on your needs. The UEFI of the computer needs to support chainloading other EFI applications to dual boot Windows and Linux. Support for this is common. An additional EFI system partition should not be created, as it may prevent Windows from booting.

Note It only appears when Linux is installed on the second hard disk and a new EFI system partition is created on the second hard disk.

Simply mount the existing EFI partition.

You may have issues resizing the existing EFI partition on a Linux system, because Windows might have created a 100 MB EFI partition and utilities such as GNU Parted are not yet able to resize partitions this small. You will need to mount the partition, copy its contents to some other partition or device, then delete the EFI partition and create a new larger one and copy the contents back. Depending on your motherboard, it might have saved the path to the Windows EFI bootloader as a boot record on the motherboard's NVRAM flash memory and may no longer be able to use the one on the new EFI partition, if this happens you will need to use the Windows recovery environment on a USB drive by downloading the windows installation iso into a USB drive (have it ready just in case) and run the bcdboot command with the necessary flags such as for example bcdboot C:\Windows /s S: /f UEFI for a UEFI system in order to recreate the boot record.

Tip

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).

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

Reason: The following paragraph feels tacked-on, it has nothing to do with installation order and should be moved to either the manufacturer-specific page or a separate section if this can be replicated on different brands. (Discuss in Talk:Dual boot with Windows)

If you use a laptop, and you had enabled battery conservation or some other function to limit battery charge via a Windows app made by the laptop manufacturer or the laptop BIOS, chances are it is disabled every time you switch operating systems. To solve this, on your Linux desktop environment, enable or reenable again battery conservation or the battery charge limiting feature. Not all laptop BIOSes support toggling or configuring this feature in BIOS setup even if supported by the hardware.

Linux before Windows

Even though the recommended way to set up 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.

Windows will use the already existing EFI system partition. Follows an outline, assuming Secure Boot is disabled in the firmware.

  1. Boot into windows installation. Watch to let it use only the intended 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 #Windows before Linux 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.

Windows 10 with GRUB

The following assumes GRUB is used as a boot loader (although the process is likely similar for other boot loaders) and that Windows 10 will be installed on a GPT block device with an existing EFI system partition (see the "System partition" section in the Microsoft documentation for more information).

Create with program gdisk on the block device the following three new partitions. See [5] for more precise partition sizes.

Min size Code Name File system
16 MB 0C01 Microsoft reserved N/A
~40 GB 0700 Microsoft basic data NTFS
300 MB 2700 Windows RE NTFS

Create NTFS file systems on the new Microsoft basic data and Windows RE (recovery) partitions using the mkntfs program from package ntfs-3g.

Reboot the system into a Windows 10 installation media. When prompted to install select the custom install option and install Windows on the Microsoft basic data partition created earlier. This should also install Microsoft EFI files in the EFI system partition.

After installation (set up of and logging into Windows not required), reboot into Linux and generate a GRUB configuration for the Windows boot manager to be available in the GRUB menu on next boot.

Linux is capable of accessing Windows volumes/partitions that are encrypted when device encryption is turned on in Windows. The procedure is the same as accessing a bitlocker volume in Linux, requiring a utility to be installed such as Dislocker. To access the encrypted volume, you will need to know the administrator password you used to enable or disable device encryption, such as the one used during setup of the first Windows administrator account. Windows hello credentials such as a pin will not work to access the volume.

Troubleshooting

Could not create a new partition or locate an existing one

See #Windows.

Cannot boot Linux after installing Windows

See Unified Extensible Firmware Interface#Windows changes boot order.

Restoring an accidentally deleted EFI system partition

If you have a GPT-partitioned disk and erased (e.g. with mkfs.fat -F32 /dev/sdx) the EFI system partition, you will notice that Windows Boot Manager will either disappear from your boot options, or selecting it will send you back to the UEFI.

To remedy it, boot with a Windows installation media, press Shift+F10 to open the console (or click NEXT > Repair Computer > Troubleshoot... > Advanced > Command Prompt), then start the diskpart utility: 

X:\Sources> diskpart
DISKPART> list disk

Select the appropriate hard drive by typing: 

DISKPART> select disk number

Make sure that there is a partition of type system (the EFI system partition): 

DISKPART> list partition

Select this partition: 

DISKPART> select partition number

and assign a temporary drive letter to it: 

DISKPART> assign letter=G:
DiskPart successfully assigned the drive letter or mount point.

To make sure that drive letter is correctly assigned: 

DISKPART> list vol
 Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
 ----------  ---  -----------  -----  ----------  -------  ---------  --------
 Volume 0     E                       DVD-ROM         0 B  No Media
 Volume 1     C                NTFS   Partition    195 GB  Healthy    Boot
 Volume 2         WINRE        NTFS   Partition    400 MB  Healthy    Hidden
 Volume 3     G                FAT32  Partition    499 MB  Healthy    System

Close diskpart: 

DISKPART> exit

Navigate to C:\ (or what your system drive letter is): 

X:\Sources> cd /d C:\

Next is the "magic" command, which recreate the BCD store (with /s for the mount point, /f for firmware type, optionally add /v for verbose): 

C:\> bcdboot C:\Windows /s G: /f UEFI
Tip If it hangs up after a minute, hit Ctrl+c. This happens sometimes, but you will get a message like boot files successfully created and it will have worked just fine.

You should now have Windows Boot Manager working as a boot option, and thus have access to Windows. Just make sure to never format your EFI system partition again!

Note Remove the drive letter G assigned to the EFI system partition to keep it from showing up in My Computer.

See [6], [7] and [8].

The EFI system partition created by Windows Setup is too small

By default, Windows Setup creates a 100 MiB EFI system partition (except for Advanced Format 4K native drives where it creates a 300 MiB ESP). This is generally too small to fit everything you need. You can replace the existing EFI system partition with a new, larger one.

If you are installing Windows from scratch, you can dictate the size of the EFI system partition during installation[9]:

  1. Select your installation target and make sure it has no partitions.
  2. Click New and then the Apply buttons. The Windows installer will then generate the expected partitions (allocating nearly everything to its primary partition) and just 100MB to the EFI.
  3. Use the UI to delete the System, MSR, and Primary partitions. Leave the Recovery partition (if present) alone.
  4. Press Shift+F10 to open the Command Prompt.
  5. Type diskpart.exe and press Enter to open the disk partitioning tool.
  6. Type list disk and press Enter to list your disks. Find the one you intend to modify and note its disk number.
  7. Type select disk disk_number with the disk number to modify.
  8. Type create partition efi size=size with the desired size of the ESP in Mebibytes (MiB), and press Enter. See the note at EFI system partition#Create the partition for the recommended sizes.
  9. Type format quick fs=fat32 label=System and press Enter to format the ESP
  10. Type exit and press Enter to exit the disk partitioning tool and exit followed by Enter again.

Once Windows is installed, you can resize the primary partition down within Windows and then reboot and go about your usual Arch install, filling the space you just created.

Alternatively, you can 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.

Unable to install Windows Cumulative Update on BIOS system

On BIOS systems, Windows cumulative updates may fail with the error We couldn’t complete the updates. Undoing changes. Don’t turn off your computer. In such case, while in Windows, you need to set the Windows partition as active. 

C:\> diskpart
DISKPART> list disk
DISKPART> select disk number
DISKPART> list partition
DISKPART> select partition number
DISKPART> active
DISKPART> exit

After successfully installing the Windows update, mark back your Linux partition as active, using the commands above.

Note Setting a partition as active in the diskpart tool in Windows has the same effect as setting the boot flag in GParted.

Unable to boot Windows after removing the Linux partition

On some systems, removing the Linux partition makes Windows unable to start. The Linux bootloader, such as Grub, is shown instead. If Grub is used, the grub rescue prompt appears. If the grub EFI files are removed and the linux boot entries are removed from the BIOS, the system will act as if there is no operating system available, and might thus boot into the manufacturer's recovery and diagnostics partition. These systems do not have Windows Boot Manager as an option on the boot menu option from the factory and have Intel processors, so they come with Intel RST, which is software RAID, so the drivers for it are available to download on the manufacturer's webpage for the specific computer or motherboard model.

First, open the BIOS settings, go to the storage tab or similar, then, disable software RAID/Intel RST and pick AHCI instead.

Note If software RAID/Intel RST is not disabled, the drive with Windows will not be visible in Diskpart in the following steps. Diskpart needs AHCI to be enabled to see the Windows drive. Without disabling software RAID/Intel RST, the Windows partition and its used capacity will only be visible on a Linux live USB environment using e.g. GParted.

Save/apply changes and exit the BIOS. Then, with a Windows installation USB, boot from the USB via the computer's boot options menu to reach the Windows install screen, and when asked to install Windows or Repair PC, choose the latter. Then choose troubleshoot, then advanced options and then command prompt.

You will need to know which Drives have the Windows partition and the ESP. Normally both are on the same drive after running diskpart: 

X:\> diskpart
DISKPART> list disk
DISKPART> select disk number
DISKPART> list partition

You can then use Diskpart to identify the ESP partition and the Windows partition, and the drive letters for each. The Windows partition will be the largest allocated partition and the ESP partition will be a FAT32 partition labeled System. Mount the ESP partition with Diskpart: 

DISKPART> select partition number
DISKPART> assign letter=drive letter
DISKPART> exit

The drive letter can be any unused drive letter you choose. Then install Windows Boot Manager by running the following command: 

bcdboot C:\Windows /s K: /f all

The above assumes the Windows partition was found with the C: drive letter and the ESP partition was assigned the K: drive letter with DISKPART> assign letter=drive letter. bcdboot will create a UEFI boot entry for Windows boot manager in the system's NVRAM (UEFI flash memory) to force the BIOS to find the Windows bootloader instead of searching the ESP for it at boot.

Note
  • Alternative bcdboot commands can be used to install Windows Boot Manager without Diskpart.
  • The computer must have AHCI enabled and thus software RAID/Intel RST disabled for bcdboot to find the Windows partition regardless of the bcdboot commands used and this also applies to the entire Windows Recovery Environment.

Then reboot, and you will get a Windows Screen of Death stating INACCESSIBLE_BOOT_DEVICE. At this point, go to the BIOS settings and reenable software RAID/Intel RST, apply changes and exit, and Windows should boot normally.

Time standard

  • Recommended: Set both Arch Linux and Windows to use UTC, following System time#UTC in Microsoft Windows. Some versions of Windows revert the hardware clock back to localtime if they are set to synchronize the time online. This issue appears to be fixed since Windows 10.
  • Not recommended: Set Arch Linux to localtime and disable all time synchronization daemons. This will let Windows take care of hardware clock corrections and you will need to remember to boot into Windows at least two times a year (in Spring and Autumn) when DST kicks in. So please do not ask on the forums why the clock is one hour behind or ahead if you usually go for days or weeks without booting into Windows.

Bluetooth pairing

Both installations use the same Bluetooth MAC address, but Linux and Windows generate different link keys during pairing, so a device paired with one will fail to connect on the other. To allow a device to connect to either installation without re-pairing, follow Bluetooth#Dual boot pairing.

See also