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
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
Based on this, it looks like something like this happened:
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
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.