[Tutorial] Multiboot Windows and Linux on Separate Disks

Contributions Tutorials
1

Multiboot Windows and Linux
…on Separate Disks

Firstly, this guide is intended for multibooting with each OS on a separate disk.

If you have a laptop with only one disk, or If you wish to install an OS on it’s own partition on the same disk, this guide is not for you (but read on regardless, if interested).

Secondly, this guide assumes each OS will be installed using UEFI and not UEFI’s CSM or Legacy mode. This guide does not support the traditional BIOS boot method. Additionally, all disks must use the GPT partitioning scheme.

Knowledge and some understanding of these terminologies is assumed. Without that, you will have additional reading to undertake before setting up a multiboot system. To that end, an Internet search can be your friend; and, this will get you started:

When creating a multiboot scenario, each OS needs to be protected from the affects of installing another OS (no matter which is already installed). It is therefore recommended to first disconnect the disk containing an existing OS before installing a second; or a third.

The General Guide

First, disconnect any previous OS disk(s). Install the new OS (in UEFI mode) to a new disk, and when fully functional, reconnect the original OS disk. Set the Linux OS first in boot order, solve any temporary Grub issues; and install rEFInd (optional) for good measure.

STEP BY STEP

Note:- This procedure makes no assumption of which OS (Linux/Windows) is installed first.

  1. Shutdown, turn off, and unplug your computer.
  2. Disconnect any existing OS disk(s).
  3. Plug in the power again.
  4. Boot with the respective OS Installer (DVD/USB).
  5. Install the new OS to the new disk and configure the OS.
  6. Shutdown, turn off, and unplug your computer.
  7. Reconnect the previous OS disk.
  8. Plug in the power again.
  9. Boot to your BIOS and select Manjaro as the first boot option.
  10. Reboot, and enjoy.

Important Caveats

SECURE BOOT

Manjaro does not support a Secure Boot configuration. As every BIOS is different, the procedure to disable Secure Boot may also be different; consult your BIOS documentation for any required information.

If Secure Boot is enabled due to a Microsoft requirement (Windows 11), a workaround may need to be employed to allow Windows to boot without Secure Boot.

Secure Boot should be disabled before installing Manjaro.

SET MANJARO FIRST IN BOOT ORDER

Boot straight to BIOS settings and make sure the drive with Linux/Grub/rEFInd (your main EFI) is selected to boot first. Then reboot into Grub (or rEFInd).

WINDOWS FAST STARTUP

By default, Windows 10/11 use a hibernation variant that Microsoft calls Fast Startup – Windows doesn’t actually shut down, but instead wakes from hibernation, giving the illusion of a faster startup; this frequently causes havoc with boot and NTFS mounting functionality within Linux.

Fast Startup must be disabled in a multiboot scenario. Disable Fast Startup using the following command from an administrative command prompt in Windows:

powercfg /h off

FAST BOOT

Fast Boot is a BIOS option which, if present, allows to skip certain self-tests during pre-boot (before handoff to a bootloader). As every BIOS is different, Fast Boot settings may exist in varying locations, or may not exist at all.

If Fast Boot is enabled, it is generally recommended (but not compulsory) to disable it in your BIOS when using Linux.

UTC VS. LOCAL TIME

Linux defaults to using UTC time rather than Local time; Windows uses Local time.

This causes particular annoyance when multibooting, as each OS defaults to a different time standard and sets the BIOS clock accordingly on each boot. No matter how many times you might manually set the correct time (in either OS), it always resets after a reboot.

Methods exist to resolve this in Linux, however this author has found those to be unreliable. This issue only exists due to a Windows design flaw, or oversight; so, let Windows in turn assume the burden of repair. Linux already handles UTC with superior grace.

The most elegant solution is to create a Windows registry file with the following content:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001

After merging this registry modification, Windows will be ready to set the BIOS time to UTC after the next reboot. Windows time will need to be manually set once after the reboot, but from that point forward, both Windows and Linux will use the UTC time standard.

Note that this modification will not affect your date/time display in Windows. Configure it as you would normally.

WINDOWS MISSING FROM GRUB MENU

Windows may not (yet) appear in the GRUB menu;- this is often expected with a new multiboot configuration. :eyes:

Some background: The package os-prober is responsible for detecting other Operating Systems during boot. Due to a security recommendation (since GRUB v2.06) os-prober is disabled by default on Arch based systems; or, in some cases, removed completely.

Is this something for you to be concerned about? This author thinks not; especially if you trust those around you who might sit in your chair.

While there is/was a valid security reason for this decision, it is incredibly inconvenient if you’re multibooting; but there is a solution; Here’s how:

Verify that os-prober is installed; install it, if it isn’t:

# Verify os-prober is installed
pacman -Qi os-prober
# Install os-prober (if needed)
sudo pacman -S os-prober

In order for os-prober to detect another available OS during boot, it needs to be enabled in /etc/default/grub, which right now, it probably isn’t.

Check os-prober status;

# Check the status of os-prober:
cat /etc/default/grub | grep -i 'OS_PROBER'
# The output will include this line:
GRUB_DISABLE_OS_PROBER=false

If the line is commented (#), uncomment it:

# Edit `/etc/default/grub`:
sudo nano /etc/default/grub

# The line should look exactly like:
GRUB_DISABLE_OS_PROBER=false

# Update GRUB:
sudo update-grub

On next reboot, os-prober should function as expected, and Windows (or any other properly installed OS) should be automatically detected and listed in the GRUB menu.

rEFInd UEFI Bootloader

Having each OS on a separate disk; with its own ESP; is an ideal scenario for multibooting. Adding rEFInd into the mix allows Manjaro or Windows to boot directly from rEFInd without harming existing bootloaders.

rEFInd can bypass Grub completely, if desired, and boot the Linux kernel directly; handy if Grub has failed to boot, as you can still boot into Manjaro and repair it in relative comfort.

Installing rEFInd on a Manjaro/Windows multiboot system should give these boot choices by default (the naming may be different, but this gives the general idea):

  • Windows
  • Manjaro (Grub)
  • Manjaro (Kernel)

The easiest way to see rEFInd in action is to firstly install it from the official Manjaro repos;

sudo pacman -S refind

…then install rEFInd to its folder on the Manjaro ESP:

sudo refind-install

The ESP will now have a directory layout similar to this:

EFI
├─ BOOT
├─ Manjaro
└─ refind

:note: Windows boot files remain on the ESP of the Windows disk, separate from Manjaro, yet easily launched by either Manjaro’s GRUB, or rEFInd.

If rEFInd does not boot first time (it usually does), reboot into your BIOS and make sure rEFInd UEFI bootloader is first in boot priority.

See also: The rEFInd Boot Manager: Methods of Booting Linux.

BOOT PRIORITY ‘HIJACKING’

Some Linux distributions (such as Debian) cause the boot priority to be reset after every update. If you are multibooting another Linux flavour along with Manjaro/Windows, it may be beneficial to move rEFInd to the default/fallback location $esp/EFI/BOOT to ensure it isn’t affected.

The ArchWiki outlines a procedure for this under rEFInd - 3.2 Manual installation; although, it seems to lack any clear direction.

This author found it much simpler to first copy/rename the rEFInd EFI executable to the default/fallback location;

sudo cp /usr/share/refind/refind_x64.efi /boot/efi/EFI/BOOT/bootx64.efi

→ and then immediately boot from a Manjaro Live Installer DVD/USB and manually move the content of {$esp}/EFI/refind/ to {$esp}/EFI/BOOT/; and finally, delete the original (now empty) {$esp}/EFI/refind directory.

See also: The rEFInd Boot Manager: Keeping rEFInd Booting

MANJARO-REFIND-INSTALLER

A special Manjaro GUI application exists called manjaro-refind-installer which allows to specify the default kernel to use when booting from rEFInd:

sudo pacman -S manjaro-refind-installer

REFIND THEMES:

rEFInd is a graphical bootloader and allows customising with many themes available from Github sites and other locations.

A quick internet search should reveal many rEFInd themes; Minimalist rEFInd Themes, rEFInd theme Regular and more refind-theme; good hunting!

3 Likes
2

Interesting option, I don’t know this one. I’ve been installing rEFInd for years as it doesn’t take much configuration, heck even the default is too sane to change (it will list all bootables from all available drives). But I still choose to chainload to GRUB instead of letting rEFInd boot the kernel directly. This way, I can still pass options through /etc/default/grub and not adding more burden to rEFInd.

1 Like
3

The beauty of rEFInd is that both of these options are usually a part of the default configuration: Options to chainload GRUB and reference the kernel directly; both are detected if present/valid and displayed automatically for Linux.

Regarding the manjaro-refind-installer package: The reason I mentioned that was due to its ability to choose which kernel to boot directly when using that rEFInd option. The only other way to make that choice is by editing /boot/refind_linux.conf manually, which may be inconvenient for some. Otherwise, I found nothing overly useful about the manjaro-refind-installer package; at least, nothing that the commandline refind-install cannot achieve.

4

Indeed, it fulfills what I call “sane defaults”.

Yea I tried that package and indeed that’s the only functionality that it provides. Not bad, but not significant as editing the config file is easy.

5

Excellent tutorial, although there is a very similar one here

I will post a small addition that is probably not worth a separate topic.

Even if the two systems are on 2 separate disks or on a one disk with 2 ESPs, there is still a chance (significantly lower) that the manjaro boot entry is deleted. A typical scenario is a UEFI update, because the settings are reset, and thus the UEFI variables and the menu. After such event, we have to disable secure boot again and restore grub in order to be able to boot anything but windows.

But what if we do not have the installation media at hand? Well, the manjaro efi file (grubx64.efi) is actually still on the disk, the only thing that is missing is one efi variable. So i started researching, if it would be possible to write this variable from within windows (for free).
There are some projects in this regard, notably some Powershell scripts, which i tested but they were very buggy.
The only project that seems to be working was this

In theory we can make an entry if we point to the efi file, i was however unsure how the path syntax should be. So i made a backup of my existing manjaro entry and on import it was successfully duplicated. All within windows.
Note that this procedure is not really tested (i will wait till the next bios update for the real life test), so always have the manjaro flash drive at hand. This should only be a convenience if it works.

6

Manjaro officially does not support Secure Boot; so, there is no need to disable that which was not first enabled in the first place. However, there are also distributions that do support Secure Boot which could potentially fall prey to the scenario you describe.

A benefit of using rEFInd as the prime bootloader is that Grub can be bypassed (to boot the kernel directly) which allows easier maintenance when Grub fails (for whatever reason) – I recall rEFInd can support Secure Boot, however, I personally have had no use for it in a multiboot scenario; it’s somewhat limiting for my needs.

There is also a (free+paid) tool for Windows; Hasleo EasyUEFI that is ideal for modifying UEFI boot entries; I usually have this tool available (just in case).

7

On laptops sold from the factory with windows secure boot is enabled, so a reset to the default uefi settings which happens when the UEFI updates usually reenables it.
Yes, EasyUEFI was my favorite but it is $30. It has a trial so it will work 1 time but if you have another UEFI update for example 6 months later not anymore.
Using rEFInd or GRUB should not make any difference in this particular case i am afraid. The entry for refind will be deleted and has to be restored in some way, then.