Dual-Booting Linux and Windows

GRUB & Multibooting

Chapter 6 · Dual-Booting Linux and Windows

The first of two genuinely different dual-boot scenarios this course covers. grub1-5's own BIOS/UEFI/MBR/GPT material — and its Secure Boot preview — both become directly relevant here, since Windows and Linux frequently disagree on defaults.

Windows's Own Bootloader — bootmgfw.efi

Windows uses its own bootloader — Windows Boot Manager, bootmgfw.efi on a UEFI system, or the older NTLDR/BOOTMGR pairing on legacy BIOS — Microsoft's direct parallel to GRUB. On a UEFI system, it lives inside the same EFI System Partition GRUB itself wants to use, exactly grub1-5's own material made concrete. The key insight: on UEFI, both bootloaders can coexist as separate .efi files in that same partition, each registered as its own entry in UEFI's persistent NVRAM boot list. On a legacy BIOS/MBR system, this isn't possible the same way — only one thing can ever occupy the MBR's own tiny boot-code region at a time.

The Recommended Installation Order — Windows First, Then Linux

Install Windows first, then Linux. Windows's own installer is not cooperative about detecting other operating systems, and will happily overwrite the boot sector or EFI boot entries without asking. Linux's installer — and GRUB's own os-prober, previewed in grub1-2 — is specifically built to detect an existing Windows installation and add a menu entry pointing at it. Installing in the reverse order means Windows clobbers GRUB outright, requiring a real repair (grub1-9).

Partitioning for Dual-Boot

Windows needs its own NTFS partition; Linux needs its own (an ext4 root, optionally a separate /home, and swap). Both operating systems share the same EFI System Partition on a UEFI system, rather than each getting its own — a genuinely important, sometimes-surprising point. Practical advice: shrink the Windows partition first, from Windows's own Disk Management tool, then let the Linux installer use the freed space — not the reverse.

os-prober — How GRUB Actually Finds Windows

os-prober scans other partitions on the system for other bootable operating systems it recognizes — including checking for Windows's own hidden system files. When found, it generates a menu entry pointing back at Windows's own bootloader:

menuentry 'Windows Boot Manager (on /dev/sda1)' {
    insmod part_gpt
    insmod fat
    search --no-floppy --fs-uuid --set=root XXXX-XXXX
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

GRUB doesn't understand Windows internals at all — it simply chainloads, handing control directly to Windows's own bootloader, which then takes it from there. This entry is generated automatically by 30_os-prober — never hand-write it, exactly grub1-2/grub1-3's own "generated, never hand-edited" rule, now seen concretely in the one case most likely to tempt someone into hand-editing.

The Classic Gotcha — Windows Update Breaks GRUB

A genuinely common real-world event: after a major Windows Update, Windows sometimes silently resets itself to the top of the UEFI boot order, or — on a legacy BIOS system — directly overwrites the MBR's own boot code. GRUB effectively vanishes from the boot process; the system boots straight into Windows with no menu at all.

The fix: from a live USB or rescue environment, reinstall GRUB (grub-install, previewed here, covered fully in grub1-9) and/or use efibootmgr to reset the UEFI boot order so GRUB's own entry is first again — grub1-5's own NVRAM boot-list material, put to practical use.

	Can both bootloaders coexist?	What Windows tends to overwrite
BIOS + MBR	No — only one occupies the MBR's own boot code	The MBR's own boot sector directly
UEFI + GPT	Yes — separate .efi files, separate NVRAM entries	The boot order (which entry runs first), not the files themselves

efibootmgr -v is the fastest way to confirm what happened

Lists every registered UEFI boot entry and their current order — a direct, immediate way to confirm whether Windows silently reset itself to the top after an update, rather than guessing.

Secure Boot can cause a second, genuinely different failure

If a Windows update re-enables Secure Boot (grub1-5's own preview) and the installed GRUB isn't properly signed/shimmed for it, GRUB's own entry can be rejected outright by firmware even while still correctly listed in the boot order — a different problem from a reordered boot list, needing a different fix (re-enrolling a shim/key), not just running efibootmgr again.

Hands-On Exercises

Exercise 1

Explain why installing Linux before Windows on the same disk is more likely to require a repair afterward than installing Windows first.

📄 View solution

Exercise 2

Explain what "chainloading" actually means in the context of the os-prober-generated Windows menu entry shown in this chapter, and why GRUB doesn't need to understand Windows internals to make it work.

📄 View solution

Exercise 3

After a Windows Update, a dual-boot system boots straight into Windows with no GRUB menu. Running efibootmgr -v shows GRUB's own entry still present, just no longer first. Explain the correct fix, and how this scenario would differ if GRUB's entry were being outright rejected instead.

📄 View solution

Chapter 6 Quick Reference

Windows uses its own bootloader (bootmgfw.efi); on UEFI it coexists with GRUB as separate .efi files and separate NVRAM entries
Install Windows first, then Linux — Linux's own installer/os-prober cooperatively detects Windows; Windows's installer does not detect Linux
Windows and Linux each need their own partitions, but share one EFI System Partition on UEFI systems
os-prober auto-generates a chainloading menu entry pointing at Windows's own bootloader — never hand-written
Chainloading means handing off control entirely — GRUB never needs to understand Windows internals
The classic gotcha: a Windows Update resets the UEFI boot order or overwrites the MBR, hiding GRUB — fixed via efibootmgr and/or grub-install
Secure Boot re-enabling is a genuinely different failure (rejection, not reordering) needing a different fix