I know other questions similar to this have been asked, but I think this situation is a bit different.

System is a Lenovo T430 with 2xSSDs (one is in the optical drive bay).

Original install was Win10 in primary SSD. Added Mint to make it dual boot, all good.

Decided to make it triple boot with Kali on the Secondary SSD - STILL good (Kali picked up both Mint and Win 10).

All worked great until I got the bright idea of installing XP (there’s a reason for it, don’t worry) alongside Kali on the Secondary SSD. I pulled the Primary SSD and put the Secondary in its place. I imaged the original Kali first, then wiped the drive and installed XP. Once I got that going, I installed the newest version of Kali. During the process, it asked if I wanted to force UEFI. I initially said no, and then it seemed to want to wipe the drive, which I obviously didn’t want to do either. So, I said yes, force UEFI. Needless to say, Kali installed, but didn’t see XP (which is fine, I had partitioned them separately so it didn’t overwrite the XP install. I booted to the XP cd, fixed the MBR, and it booted to XP but Kali was invisible. Ok, I thought, whatever, maybe they don’t play nice together. No worries, I’ll just take images of each partition and reimage that drive when I need to use one or the other. Easy peasy.

So, I got the primary and secondary back to original configuration (Win 10 + Mint on primary, XP and unreachable Kali on secondary), wiped the secondary (after imaging the XP and Kali parts separately), and installed Kali again as the sole OS on the secondary. The message popped up again saying “do you want to force UEFI?” I figured hey, I’m using all modern O/S now, so no problems and said yes.

Only this time, it won’t see Windows on the Primary. It sees Mint and boots to it, but not Windows. The partitions look to still be there in gparted. I tried using Win 10 repair, no go. Tried reinstalling Mint, thinking maybe it would pick it up and revert to the original config, but no - Mint fails when trying to write Grub.

So, I’m stuck. I already wiped out The secondary drive so it’s blank (take it out of the equation for now - less complicated).

How do I get Windows back? I know Kali didn’t really eat it, it just overwrote something that points to it. I know it’s there, and I have a lot of things I need on it.

Thanks in advance for any help. I know just enough about Linux to get myself into trouble (clearly), but not enough to say I’m proficient.

Edit: photos are added. It looks to me like SSD2 is GPT and SSD1 is MBR? Also, both are 2.5” SSDs, this laptop is too old for NVMe drives. Thanks!

Help!enter image description hereenter image description here


3 Answers 3


OK, some background information first:

  • An OS that is booted in UEFI-native way will have an ability to access the boot configuration while the OS is running as a set of UEFI NVRAM boot variables; this is part of the UEFI specification. In Linux, the most user-friendly way is the efibootmgr command; in Windows, the bcdedit command can access the UEFI boot variables when run as an Administrator. To view the boot variables, run efibootmgr -v as root in Linux, or bcdedit /enum FIRMWARE as Administrator in Windows.

  • Some UEFI firmware implementations won't offer complete access to UEFI boot variables in the "BIOS" configuration menu, but insist on a simplified BIOS-like boot disk selection. This can bite you when trying to build advanced multi-boot scenarios. You'll need to be aware of the existence of the UEFI boot variables and be prepared to edit them if the various installers get them wrong.

  • If you have a NVMe SSD, your system firmware needs to specifically support booting from it, as a NVMe SSD is not at all like a SATA drive. Some UEFI firmwares will only support booting from a NVMe device in UEFI mode. This usually does not prevent the OS from being able to access a NVMe device, if it has a NVMe driver available.

  • Most UEFI-aware OS installers will detect the mode the OS installer is booted in (BIOS or UEFI) and will install a matching type of bootloader, no questions asked. Kali apparently can offer "forcing UEFI" i.e. installing an UEFI bootloader even if the installer is booted BIOS-style.

  • With BIOS-style boot, the MBR of a disk can only be occupied by one bootloader/manager at a time; usually you'll choose the one that's most capable of booting multiple OSs (e.g. GRUB). If other OSs overwrite the MBR, you'll need to be able to boot the "designated MBR manager OS" using external boot media and rewrite the MBR.

  • With UEFI-style boot, bootloaders are contained in an ESP partition (basically a FAT32 partition) in a standardized directory structure. The bootloaders of multiple OSs can coexist in a single ESP partition just fine. But there is a single "magic" bootloader filename that the UEFI firmware will seek if there are no UEFI boot variables to direct it to a specific bootloader file: on x86_64 hardware, it is \EFI\BOOT\BOOTX64.efi. Windows will normally place a second copy of its \EFI\Microsoft\Boot\bootmgfw.efi file in this location to enable booting Windows even if the UEFI NVRAM boot variables are lost (e.g. because of a BIOS update/reflash). Kali's "Force UEFI?" may or may not mean writing a copy of UEFI GRUB into \EFI\BOOT\BOOTX64.efi of the ESP partition instead.

  • Different OSs have different levels of UEFI support and the choice of boot method may be tied to the choice of partitioning type:

    • Windows XP (the common 32-bit version) cannot boot UEFI-style and cannot access GPT-partitioned disks. Only BIOS-style boot capable.
    • A 64-bit version of Windows XP (rare, finding drivers may be difficult) can access GPT-partitioned disks but requires a MBR-partitioned system disk to boot from. Only BIOS-style boot capable.
    • Windows 10 can support both boot styles, but requires a MBR-partitioned system disk to boot BIOS-style and a GPT-partitioned system disk to boot UEFI-style. You cannot mix and match.
    • Linux can usually be configured to boot in any combination, although the more esoteric combinations may require special attention. UEFI on MBR-partitioned disk requires a FAT32 partition with partition type 0xef to contain the UEFI bootloader(s); BIOS-style boot on GPT-partitioned disk requires a BIOS that supports GPT and a special "biosboot" partition to contain the part of GRUB that's normally embedded between the MBR and the beginning of the first partition, as this space is not available in GPT partitioning.
  • Unlike Windows XP, Windows 10 needs multiple partitions. When booting UEFI-style, it needs an ESP partition (which may be shared with other OSs), a main Windows system partition (typically the C: drive) and a small recovery partition. On new installations, there is usually also a "Microsoft reserved" partition, although it is not technically absolutely necessary: installations upgraded from earlier versions of Windows might not have it.

  • Most bootloaders/boot managers can only boot OSs using the same boot style as the bootloader. If you have a dual-boot with one legacy OS and one UEFI-native OS, the only way to switch between the OSs may be to use the BIOS menus to switch between boot modes or "UEFI/legacy first" preferences. The rEFInd Boot Manager is an UEFI-native bootloader that apparently can in some cases start up a BIOS-style bootloader, but that is not guaranteed to work with all systems; you may need to try it and see if it works for you.

  • It's useful if your system's BIOS menus offer a good selection of boot method options:

    • enable/disable Compatibility Support Module = BIOS-style boot capability
    • the ability to restrict to BIOS-style boot methods only
    • prefer UEFI/BIOS style boot method when booting from removable media
    • prefer UEFI/BIOS style boot method when booting from HDD/SSD
    • or even the capability to include both BIOS and UEFI-style boot targets in the boot order list simultaneously

Some laptops or name-brand desktops may offer a simplified BIOS menu with very limited configurability. In these cases, you may have to figure out whether the system prefers UEFI or BIOS, and in worst cases you may have to create OS installation media with the "wrong" type of bootloader intentionally disabled (for USB sticks, delete \EFI\boot\bootx64.efi to make it BIOS-only, or replace the MBR boot code with a valid non-boot MBR to make it UEFI-only).

It sounds like your primary disk is GPT-partitioned and the OSs on it probably use UEFI. To confirm this, please run fdisk -l and edit the output into your original question.

If that's true, your UEFI boot variables may currently be misconfigured and/or the Windows UEFI bootloader (located as /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi as viewed from Mint) may be damaged. Please run sudo efibootmgr -v in Linux to check the current state of your UEFI boot variables and edit the output into your original question, or if it's quite long, e.g. put it into a pastebin site and link it into your question.

The most convenient way to visualize the state of your ESP partition would probably be to run sudo tree --charset ASCII /boot/efi from Linux. Please add that to your original question too. To make it shorter, you can omit the sub-directories of the /boot/efi/EFI/Microsoft/Boot directory, as there are multiple language-specific directories.

Armed with this information, I (or someone else in this StackExchange) will probably be able to help you without resorting to blind guesswork.

From the pictures, your sda disk is partitioned MBR-style, but the efibootmgr -v output includes a Windows Boot Manager line, that indicates the system was booting Windows in UEFI style at some past point. UEFI variables identify the ESP partition they refer to by the GPT partition unique GUID (PARTUUID in Linux), and the GUID on the Windows Boot Manager line does not match GUID on kali's line.

On the other hand, the ubuntu line refers to a MBR partition, and the line includes the value 0xd1e9685 which matches exactly the disk identifier of sda.

Based on this, it looks like something like this happened:

Either the sda disk was converted from GPT to MBR at some point, or both disks were already present when Windows was installed, and sda was already partitioned MBR-style. But the Windows installer was booted in GPT-style and so it looked for a place to add a ESP partition onto a GPT-partitioned disk for proper UEFI-style boot. So it formatted the secondary SSD in GPT-style and placed the ESP partition and the Windows bootloader within it instead, since it was probably completely uninitialized at that time.

(This tendency to place the ESP on different disk from the rest of Windows if given a chance is a known issue with Windows 10 installer. The standard recommendation is to temporarily unplug or disable any other disks before running the Windows 10 installer if your system has more than 1 disk.)

When installing Mint, the installer was again booted UEFI-style, but unlike Windows installer it won't touch disks unless explicitly told to, so it created its own ESP partition to a MBR-partitioned disk (sda5, partition type 0xef).

The first Kali apparently also created its own ESP partition on the secondary SSD, but in GPT partitioning, each partition has an unique GUID and UEFI uses it to identify which ESP partition each OS uses to boot, so this did not cause any mix-ups.

When you disconnected the primary SSD and put the secondary one in its place for installing XP, you may have seen a single partition with type 0xee on it. This was a dummy MBR partition table that's part of the GPT partition standard, to indicate to any GPT-unaware operating systems that the disk is in use. But you assumed the disk was unused, and ignored it - so as a result, the Windows bootloader was overwritten without you being aware of it.

Your second installation of Kali must have also been booted UEFI-style, and it created a ESP partition on the MBR - just like Mint did. Kali's "Force UEFI" probably means two things:

  • it will remove any existing MBR boot code, so the disk will be unbootable MBR-style
  • it will also write a copy of its bootloader into \EFI\BOOT\BOOTx64.efi on the ESP partition.

As a result, you now had two OSs with different boot methods on the same disk. Kali's UEFI GRUB cannot boot Windows XP because that would require switching the BIOS compatibility back on when jumping from GRUB to the XP bootloader, and GRUB does not know how to do that. Your system appears to prefer booting legacy-style over UEFI, as after fixing the XP's MBR the firmware went straight back into booting BIOS-style... which makes switching into Kali's UEFI GRUB impossible, as the 16-bit BIOS compatibility mode has no hope of meaningfully using UEFI GRUB's 64-bit code.

When you moved the disks back into their original locations, and wiped the secondary disk again, the Windows bootloader was now wiped twice over. The Windows 10 boot recovery got confused as it saw the majority of Windows (configured to boot UEFI-style) on a MBR-partitioned disk and no ESP partition on a GPT-partitioned disk anywhere in sight. The Mint installer may have also gotten confused somehow, but that is probably not the most important thing.

The best way out of this situation and into a sane configuration is probably to use Mint to access the Windows sda2 disk, and copy everything important out of there onto removable media or other safe location:

sudo mkdir /windows_c
sudo mount -t ntfs-3g /dev/sda2 /windows_c
cd /windows_c
cp <whatever> </some/where/safe>

Then disconnect the secondary SSD, wipe the primary one and start by installing Windows 10 UEFI-style. If possible, you may want to change the BIOS settings to switch the legacy BIOS-style compatibility off for this, to ensure everything goes in UEFI-style. Then install Mint next to it.

Then you can remove the primary SSD, install the secondary one in its place, switch the BIOS-style compatibility back on and install XP. Now move both disks back into their original places, and maybe install Kali in UEFI mode onto the second disk (without selecting "Force UEFI"). Then boot into Mint, make sure the os-prober package is installed, and run sudo update-grub to get Kali onto Mint's boot menu.

Now whether you use Kali's or Mint's GRUB, both should give you three options: Kali, Mint and Windows 10. To get into XP, you'll unfortunately need to go into BIOS settings and explicitly choose to boot legacy-style from the secondary disk.

  • Thank you for the quick reply - I have attached two photos and updated some information. It did not like the sudo tree command.
    – Ryan Lee
    Jan 30, 2021 at 23:44
  • Edited for analysis and suggested way forward. Freddy's suggestion to convert the sda disk "back" to GPT might or might not work; if it does, it could be a quicker way back to Windows.
    – telcoM
    Jan 31, 2021 at 11:20
  • Sorry, been pretty busy. I’m really trying not to reinstall Windows if possible. I can scrap Mint if I need to, but I’m hoping to recover the Windows that is already there if at all possible.
    – Ryan Lee
    Feb 2, 2021 at 5:08

Convert your disk back to GPT with gdisk:

sudo gdisk /dev/sda

The output should look similar to this:

$ sudo gdisk /dev/sda
[sudo] password for xxx: 
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present

Found invalid GPT and valid MBR; converting MBR to GPT format
typing 'q' if you don't want to convert your MBR partitions
to GPT format!

Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.

Command (? for help):

If you don't get a warning like above, press w to write the changes to disk, confirm with y. Then run sudo gdisk /dev/sda again, press p to check that your EFI partition is listed with code EF00. If that's not the case, you need to change the type (option t, choose partition number, enter ef00, w to write changes, confirm with y), otherwise quit with q. Then reboot. With a bit of luck your Windows should be bootable again.

If you get a warning, quit with q. You need to resize your Mint partition by the amount of mentioned blocks beforehand to make space for the secondary partition table at the end of the disk. You may use gparted for that. Or delete /dev/sda6 if you're going to do another fresh install. Then repeat.

You can change your boot mode in Bios from UEFI/Legacy Boot -> Both to UEFI only to prevent booting in legacy mode ever again.

You may also want to delete the existing "kali" and "ubuntu" UEFI boot entries with efibootmgr, e.g.

sudo efibootmgr -b19 -B

to delete the Boot0019* kali entry.

  • Thank you for the tip, I will try it.
    – Ryan Lee
    Feb 2, 2021 at 5:08
  • Alright, so I did this - the error wasn’t there, but everything else you mentioned looked the same. Restarted, and now I get this: “System BootOrder not found. Initializing defaults. GNU GRUB version 2.04 Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completion. Anywhere else TAB lists possible device or file completions.
    – Ryan Lee
    Feb 3, 2021 at 14:50
  • I did not delete the Kali et. al. entries as you suggested as a secondary idea yet. Thoughts?
    – Ryan Lee
    Feb 3, 2021 at 14:52
  • What happens if you turn on your ThinkPad, press F12 and choose "Windows Boot Manager"? Does it boot? If not, boot from your Windows USB and try the repair options. You can delete the other UEFI entries later if they don't bother you.
    – Freddy
    Feb 3, 2021 at 15:09
  • I reinstalled Mint over the previous install, and got no error writing grub this time at least. The system boots to Mint. Now how can I get it to see Windows?
    – Ryan Lee
    Feb 3, 2021 at 15:09

UPDATE: I can now boot into Windows.

Here’s what I did:

  1. converted to GPT as per Freddy’s suggestion. Didn’t fix the issue itself, though it did allow me to reinstall Mint normally.
  2. reinstalled Mint (hoping Grub would pick Windows back up - it did not, but booted directly into Mint without grub, meaning for whatever reason, it didn’t see Windows
  3. booted from Win10 install usb and tried boot repair. Failed, so I popped over to command prompt. There, I tried a series of commands found here: https://docs.Microsoft.com/en-us/Windows/client-management/advanced-troubleshooting-boot-problems

I went straight to Method 3. It found Windows under D:\Windows as indicated. So I knew it was still there and valid.

Upon rebooting, THIS time, I entered Grub - but still no Windows to be found in the Grub menu.

Rebooted again, went to the “one time boot menu” and, just for the hell of it, tried Windows Boot Manager (which had failed every other time before). This time, it booted into Windows.

I am still not quite sure what the magic combination was, but I suspect GPT conversion was step 1, Fix BCD errors was step 2, and now the Windows Boot Manager sees it.

  • In Mint, run sudo os-prober and sudo update-grub. The first command should find your Windows installation and the second regenerates your Grub config and adds a Windows entry.
    – Freddy
    Feb 3, 2021 at 15:51
  • Awesome, thanks Freddy - again, it worked. I’m gonna image this and not screw its up again 😉
    – Ryan Lee
    Feb 3, 2021 at 17:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .