#Grub2 windows 10 uefi bios windows#

If it turns out you have problem #3, you can fix it by using the efibootmgr command in your Kali Live USB - but only if that Live USB is bootable in the UEFI native style. (If you cannot disable Secure Boot, get the -signed version of the first package if available, and also the shim package.) Fixing it would require chrooting to the HDD-based installation and using the package management tools to replace the grub-pc and grub-pc-bin packages with grub-efi-amd64 and grub-efi-amd64-bin respectively. If, on the other hand, there is a sub-directory named i386-pc, you have a traditional BIOS/MBR version of GRUB installed, confirming problem #1. If there is a sub-directory named x86_64-efi, you have an UEFI version of GRUB installed and can definitely exclude problem #1. After mounting the Linux partition(s) on the HDD, go to the directory /usr/lib/grub and list the contents of that directory. The next step would require booting Kali (or some other Linux) from live USB and using it to gain access to the Kali installation on the HDD. Often (but maybe not always) the UEFI BIOS Setup offers a way to do one or both of these things. If problem #2 seems likely, it can be worked around by disabling Secure Boot, or by clearing the Secure Boot Primary Key (PK) variable. If there is no mention of Kali in the output, you can tentatively exclude problem #2 for now - you definitely have at least problem #1 or #3. This will list the boot options registered in NVRAM and the BootOrder settings.

#Grub2 windows 10 uefi bios windows#

The first step for identifying between these cases would be letting the system boot to Windows 10, running a Command Prompt as an Administrator, and using the bcdedit /enum firmware command. Or maybe the firmware implementation will only accept the boot filename of a standard Windows bootloader - that would qualify as a firmware bug. That at least would make this case easier to troubleshoot.)ДЈ.) The Kali installer may have successfully installed a Secure Boot-capable UEFI bootloader, but failed to register it in the firmware NVRAM. (Other UEFI implementations will output a scary security error message if Secure Boot is enabled and they encounter a bootloader with a missing or invalid Secure Boot signature. If your firmware prefers UEFI-style boot over legacy BIOS style, this bootloader will be completely ineffective, as the firmware just won't load the old-style Master Boot Record at all, once it sees that the Windows UEFI bootloader is in place.Дў.) The Kali installer may have installed an UEFI version of GRUB, but without the shim.efi that is necessary for Secure Boot - and the Secure Boot implementation of your system's UEFI firmware may silently bypass any bootloader that does not have the necessary Secure Boot signatures, if Secure Boot is enabled.

There are several possible things that might be going wrong.ДЎ.) The Kali installer may have installed a traditional BIOS/MBR-style version of GRUB instead of an UEFI version.