Manual Entry of Windows Boot Entries in Linux
Understanding the Multi boot problem
You bought a shiny SSD, installed Linux, and suddenly your boot menu looks like a divorced couple sharing custody of your motherboard: Windows on one drive, Linux on another, and nobody talking to each other. This write‑up walks through why that happens and how to manually add Windows back into the Linux boot flow without sacrificing your sanity (or your EFI partitions).
The problem
You grabbed a Cyber Monday SSD, slapped it into the spare M.2 slot, and installed Linux on it because vacations don’t care about your PCMR lifestyle. After POST, the firmware boot menu shows two separate entries: “Windows Boot Manager” on one drive and “Linux UEFI” on the other, and while everything technically boots, it feels more like a truce than a proper dual‑boot.
The real issue: Linux boots fine, but from inside Linux you cannot select Windows for the next boot, and the Windows boot entry does not show up in the Linux boot loader even though you can see and mount the Windows drive just fine. You would like both OSes to coexist peacefully, with Linux in charge of the boot order—because obviously it’s the responsible adult here.
EFI on separate drives
You essentially have two brains in one body: each OS has its own EFI partition living on its own drive. The firmware is happy to list both, but as soon as you start formatting and reinstalling things, that happiness can vanish faster than your FPS after enabling ray tracing on a GT 710.
- Pros: If one OS drive gets corrupted or needs a full nuke‑and‑pave, the other drive’s EFI data survives untouched, so you can reinstall without accidentally deleting the other OS’s bootloader. It is a nice bit of OS integrity, like emotional boundaries but for disks.
- Cons: If your “primary” drive’s EFI is wiped or changed, the firmware might forget about the other OS entirely, and suddenly Linux or Windows just “doesn’t exist” until you manually fix the boot entries.
Why Linux should be in charge
Windows defaults to NTFS, macOS to APFS, and both are great as long as you’re doing basic CRUD on normal files and not asking too many questions. Linux rolls in with ext4 (or Btrfs/ZFS if you like living dangerously) and politely reads NTFS too, which makes it the ideal control center for multi‑boot weirdness.
Your setup: Pop!_OS 24.04 with COSMIC on the new SSD, running containers, games via Proton, Steam, Lutris, and generally being a hyperactive Swiss Army knife. But then you remember you still need Windows for 3D CAD in Fusion or SolidWorks, peripherals firmware updates, and that suspicious pile of Adobe and Microsoft apps that simply pretend Linux doesn’t exist.
Add remote management to the mix: a NanoKVM acting as budget IPMI, ZeroTier gluing everything together, and you needing to access the system before any OS has even thought about booting. Tools like TeamViewer or RustDesk are useless at that stage because they require an OS first, so firmware‑level control and reliable boot entries matter a lot here.
The Linux clutch moment
Linux happily mounts the Windows drive; you can see all the partitions, browse the files, and admire your questionable downloads. But when you list boot entries from within Linux, the Windows Boot Manager is nowhere to be found, like that one friend who never joins voice chat but somehow is always “online.”
You can’t just “tell Linux” to magically boot from another drive by vibes alone. You need to teach the bootloader (or UEFI itself) exactly where Windows keeps its sacred bootmgfw.efi file so that Linux can present “Windows Boot Manager” as a proper option in the boot menu.
Step 1: Find the Windows EFI Partition
In the Linux terminal try:
lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINTOutput:
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
└─sda1 ntfs Gamedrive 26021D5C021D31F3
sdb btrfs storage500 0cd5d1e7-b919-4354-9ad6-bb3e6e9f2ea5
zram0 [SWAP]
nvme0n1
├─nvme0n1p1 vfat FAT32 5751-832E 700.7M 31% /boot/efi
├─nvme0n1p2 vfat FAT32 5751-82C2 672.8M 84% /recovery
├─nvme0n1p3 ext4 1.0 cdb75637-6004-4586-850a-ccc116f78c1c 1.7T 1% /
└─nvme0n1p4 swap 1 6bdf4019-783e-4c78-8def-32cf3cbd1a24
└─cryptswap swap 1 cryptswap 4e36fc37-834a-4a48-b37f-0fc4d49135b1 [SWAP]
nvme1n1
├─nvme1n1p1 vfat FAT32 8AB5-A810
├─nvme1n1p2
├─nvme1n1p3 ntfs 629CB6B89CB68657
└─nvme1n1p4 ntfs E4143F95143F6A26In My case it's in nvme1n1p1
Step 2: Mount that partition
sudo mkdir -p /mnt/win-efi
sudo mount /dev/nvme1n1p1 /mnt/win-efiStep 3: Copy Microsoft boot folder into Linux
sudo cp -r /mnt/win-efi/EFI/Microsoft /boot/efi/EFI/Step 4: Reboot PC (boot back to Linux)
sudo reboot nowStep 5: Check BootCTL
sudo bootctl listOutput:
kaito@Comet:~$ sudo bootctl list
[sudo] password for kaito:
type: Boot Loader Specification Type #1 (.conf)
title: Pop!_OS recovery (default)
id: Recovery-5751-82C2.conf
source: /boot/efi//loader/entries/Recovery-5751-82C2.conf
linux: /boot/efi//EFI/Recovery-5751-82C2/vmlinuz.efi
initrd: /boot/efi//EFI/Recovery-5751-82C2/initrd.gz
options: boot=casper hostname=recovery userfullname=Recovery username=recovery live-media-path=/casper-5751-82C2 >
type: Boot Loader Specification Type #1 (.conf)
title: Pop!_OS (selected)
id: Pop_OS-current.conf
source: /boot/efi//loader/entries/Pop_OS-current.conf
linux: /boot/efi//EFI/Pop_OS-cdb75637-6004-4586-850a-ccc116f78c1c/vmlinuz.efi
initrd: /boot/efi//EFI/Pop_OS-cdb75637-6004-4586-850a-ccc116f78c1c/initrd.img
options: root=UUID=cdb75637-6004-4586-850a-ccc116f78c1c ro quiet loglevel=0 systemd.show_status=false splash nvid>
type: Automatic
title: Windows Boot Manager
id: auto-windows
source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
type: Automatic
title: Reboot Into Firmware Interface
id: auto-reboot-to-firmware-setup
source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4fStep 6: Next Boot --> Windows
from the above out put the one I'm interested is with the title named Windows Boot Manager and to be very precise, the id , in this case its auto-windows
systemctl reboot --boot-loader-entry=auto-windowsHappy Booting :D