← All projects

IT Support · Troubleshooting

Windows & Linux Dual-Boot Troubleshooting

Investigating GRUB, Windows Recovery, and UEFI/Legacy boot configuration to restore a functional dual-boot environment.

Technical context

Windows · Linux · GRUB · UEFI · Legacy BIOS / CSM · WinRE · Disk partitioning · Troubleshooting

Project Overview

I was asked to troubleshoot a computer after someone else installed Linux alongside Windows. Windows had worked normally before the installation. When I investigated, the computer could reach GRUB and Linux remained accessible in Legacy/CSM mode, but Windows would no longer start successfully. My task was to restore access to both operating systems.

I investigated storage, bootloader settings, Windows recovery, and firmware configuration. The key finding was that Windows used UEFI while Linux had been installed in Legacy mode. I removed that Linux installation and reinstalled it after explicitly selecting the installation USB's UEFI entry. Both operating systems then booted successfully.

The Problem: GRUB Loads, but Windows Does Not

Reaching GRUB gave me a useful starting point: part of the startup path was working, and Linux remained accessible. The failure appeared when trying to start Windows after adding Linux.

I considered several possible points of failure: GRUB configuration, Windows Boot Manager, disk partitions, firmware boot mode, and the Windows startup configuration. The symptoms gave me reasons to check each of these, but did not identify a damaged component on their own.

Investigating the Boot Failure

Linux-side diagnostics

I used the accessible Linux environment to inspect the storage and boot setup. With lsblk, I examined block devices and their partition relationships. I also used fdisk to examine disk partition information. Together, these tools helped me understand how storage was organized before focusing on the startup configuration.

lsblk
Lists block devices and their relationships. Depending on the requested columns, it can also show mount points and filesystem information.
fdisk
Examines partition-table information, including boundaries and partition types. A partition type offers a clue about its purpose; checking its boot files requires further investigation.

These are the tools I used during the incident. Their output describes storage; checking how an operating system starts also requires examining the boot configuration and firmware. The original terminal output is no longer available.

I investigated GRUB configuration, attempted GRUB-related repair commands, and examined the Windows Boot Manager configuration. The exact repair commands and individual outputs are no longer recorded. Windows remained unable to start, so I continued investigating beyond the Linux boot menu.

Windows Recovery Environment

I also accessed the Windows Recovery Environment, or WinRE, to investigate startup from the Windows side. This was the Windows recovery interface, where I could investigate while normal Windows startup was unavailable.

The Windows-side investigation did not restore normal boot functionality. That left the relationship between the installations and the firmware configuration as an important area to examine.

Firmware boot configuration

Checking the BIOS/UEFI settings revealed the mismatch: Windows used UEFI, while Linux had been installed in Legacy/CSM mode. I made aligning those modes the focus of the corrective action.

A firmware boot menu can offer both UEFI and Legacy entries for installation media. Choosing an entry determines how the installer itself starts and can influence the bootloader setup it creates. For the reinstall, I explicitly selected the USB's UEFI entry.

Troubleshooting workflow

From boot failure to a working dual boot

Called in after someone else installed LinuxWindows previously worked. GRUB is now accessible; Windows fails to start; Linux remains accessible in Legacy/CSM.

Diagnostic branches · order not recorded

Linux diagnosticslsblk / fdisk · GRUB configuration and repair attempts · Windows Boot Manager checks
Windows recoveryAccess WinRE · investigate startup · Windows still unable to boot
Firmware investigation → mismatch foundWindows: UEFI · Linux: Legacy/CSM
Remove Linux → boot USB in UEFI → reinstallCheck Windows startup and Linux startup.
Both operating systems boot successfully
Linux and Windows recovery are parallel investigation categories; their exact order and the outcomes of individual repair commands were not recorded.

Understanding UEFI and Legacy BIOS

The two modes use different startup mechanisms. In a typical UEFI installation, firmware loads an EFI boot application from an EFI System Partition (ESP). Windows Boot Manager participates in Windows startup; GRUB can provide a Linux boot menu and load Linux or hand control to another bootloader.

Legacy BIOS starts through boot-sector code. CSM, the Compatibility Support Module available in some UEFI firmware, provides a legacy-compatible startup path. GRUB has platform-specific versions for BIOS and UEFI, so the same menu name can appear within different boot mechanisms.

Implementation diagram

UEFI and Legacy startup paths

UEFI

  1. UEFI firmwareSelects an EFI boot application.
  2. EFI System Partition (ESP)Stores EFI boot files on the system disk.
  3. EFI boot applicationFor example, Windows Boot Manager or a UEFI GRUB installation.
  4. Operating-system startupThe boot application proceeds through the relevant OS loading path.

Legacy BIOS / CSM

  1. BIOS / compatibility modeStarts through the legacy boot mechanism.
  2. Boot sector / boot codeBegins the disk-based bootstrap process.
  3. BootloaderFor example, a BIOS-compatible GRUB installation.
  4. Operating-system startupThe bootloader transfers control through the relevant OS loading path.
Simplified typical startup paths; implementations vary. The ESP stores EFI applications. Each OS can have its own boot files and bootloader.

A mixed-mode setup can complicate boot selection and handoff because the installations expect different firmware services. Some firmware can select each mode independently; the practical options depend on the firmware and bootloaders. Aligning the installations gave this machine a consistent UEFI setup.

The diagram explains typical mechanisms behind the investigation. The original partition identifiers and exact boot entries were not retained, so it illustrates the architecture rather than the machine's specific disk layout.

Technical references: Microsoft: UEFI and Legacy boot modes and the GNU GRUB boot-method documentation.

Resolution: Reinstalling Linux in UEFI Mode

I removed the previous Linux installation and restarted the installation process. The important change was selecting the UEFI entry for the Linux installation USB from the firmware boot menu, aligning the new installation with Windows.

  1. Removed the previous Linux installation.
  2. Prepared to reinstall Linux.
  3. Entered the firmware boot menu.
  4. Explicitly selected the UEFI entry for the installation USB.
  5. Reinstalled Linux in UEFI mode.
  6. Checked that Windows booted successfully.
  7. Checked that Linux booted successfully.

Implementation diagram

The configuration change and verified result

Before · identified mismatch

  1. Windows: UEFI / Linux: Legacy-CSMDifferent boot modes in the two installations.
  2. Observed startup behaviorGRUB accessible; Linux accessible; Windows fails to boot.

Corrective action

  1. Remove previous Linux installationRestart the installation process.
  2. Select UEFI USB entry → reinstall LinuxAlign the Linux installation with the existing Windows boot mode.

After · verified dual boot

  1. Windows: UEFI / Linux: UEFIBoth installations use UEFI mode.
  2. Windows boots / Linux bootsBoth operating systems start successfully.
Before and after describe the recorded incident. Both operating systems were checked after reinstalling Linux in UEFI mode.

Results and Lessons Learned

After the reinstall, both Windows and Linux started successfully, restoring a functional dual-boot environment. The boot-mode mismatch guided the correction. Reinstallation can change several parts of a startup setup, so the result supports the resolution while leaving the exact contribution of each change open.

The investigation taught me to connect disk information, bootloader configuration, and firmware mode. Linux terminal tools helped me inspect the environment, WinRE provided a Windows-side investigation path, and the firmware settings exposed how the installations differed.

I now pay closer attention to how installation media is booted and validate each operating system after a configuration change. For IT support and systems work, this experience reinforced a practical approach: narrow the possibilities, compare the relevant settings, and check the user-facing result after the corrective action.

Related technologies

  • Windows
  • Linux
  • GRUB
  • UEFI
  • Legacy BIOS
  • WinRE
  • Troubleshooting