Cfrtjryk

I have a Dell Inspiron 5559. At present it is booting in UEFI mode with inbuilt Windows 10. I need to dual boot between Kali Linux and Windows 10. I followed the many tutorials online but they all are variant.

Can anyone tell me how to dual boot Kali Linux with Windows? I have installed Kali by booting it with live USB. But my problem is the GRUB loader is installed but it is not asking me whether to choose Windows or Linux. The boot loader booting Windows 10 default.

When i try add Linux with easy BCD in windows it is showing:

EFI boot loader Detected--- Easy BCD has detected that your machine is currently booting in EFI mode. Due to limitations set by Microsoft, many of easy BCD multi booting features cannot be used in EFi mode and have been disabled.

are you trying to install Kali (or whatever distribution) of linux on to the existing hard drive having windows 10?

if not and your linux is on another hard disk then the easiest method is to F12 prior to booting to access the UEFI boot menu; this is not the GRUB2 menu. at this point the EFI boot menu (not the BIOS menu and not the GRUB2 menu) will allow you to choose which .efi file on which boot partition to kick off. And you can dual-boot this way.

recognizing you have a dell inspiron, a laptop, then you are most likely on 1 drive for everything. Reports are windows 10 when booting/rebooting will repair/remove any boot loader installed in to the windows 10 boot partition.
https://ubuntuforums.org/showthread.php?t=2294337

When you do F2 to enter SETUP and go to BOOT menu, you will then have a menu option to choose which .efi boot files. Your laptop only has 1 drive so there will only be one choice presented and that would kick off windows 10. But for example if you had a tower pc that could hold 4 hard drives each having their own boot partition you would then have 4 choices in this EFI boot menu.

I believe what you need to do, because windows 10 is Microsoft and it doesn't play nice sharing boot menus/partitions,
you need to get the motherboard EFI menu to automatically select a boot partition different from the OEM Windows 10 boot partition where this different partition just has GRUB2 on it.
Grub2 will precede the windows 10 boot loader in when things happen,
and then have GRUB2's menu give the choices to choose either the windows 10 partition or your linux partition for booting.
This way windows 10 only sees it's own boot manager on it's own partition unmolested. In windows 7 at least it was more forgiving on modifying the windows boot partition; I believe that has all ceased with windows 10 and the secure boot mentality.

So you want to create a new partition on your Dell oem win10 hard disk, completely separate from the windows partition, and install GRUB2 on it. this might be partition #4 for example.

Whether you can then have the motherboard firmware/EFI point to partition #4 on a disk instead of partition #1 to launch GRUB2 I don't know. I am more of an ELILO guy than a GRUB2 guy and have always had my boot partition as partition #1 on the disk. But if you can, then configure GRUB2 to provide your 2 menu options for launching either windows 10 or linux.

There are several possible things that might be going wrong.

1.) The Kali installer may have installed a traditional BIOS/MBR-style version of GRUB instead of an UEFI version. 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.

2.) 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.

(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. That at least would make this case easier to troubleshoot.)

3.) The Kali installer may have successfully installed a Secure Boot-capable UEFI bootloader, but failed to register it in the firmware NVRAM. Or maybe the firmware implementation will only accept the boot filename of a standard Windows bootloader - that would qualify as a firmware bug.

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. This will list the boot options registered in NVRAM and the BootOrder settings. 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.

If problem #2 seems likely, it can be worked around by disabling Secure Boot, or by clearing the Secure Boot Primary Key (PK) variable. Often (but maybe not always) the UEFI BIOS Setup offers a way to do one or both of these things.

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. After mounting the Linux partition(s) on the HDD, go to the directory <mountpoint>/usr/lib/grub and list the contents of that directory. If there is a sub-directory named x86_64-efi, you have an UEFI version of GRUB installed and can definitely exclude problem #1.

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. 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[-signed] and grub-efi-amd64-bin respectively. (If you cannot disable Secure Boot, get the -signed version of the first package if available, and also the shim package.)

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 the Live USB is booting in the legacy BIOS/MBR style, the legacy compatibility firmware code will hide away the interface that is needed by the efibootmgr command.

Alternative tools for fixing problem #3 in the Windows side:

• there used to be a program named EasyUEFI from the same manufacturer as EasyBCD. Even the completely free version of that program would have been sufficient. Unfortunately, only a trial version of it is now available for free.


• there seems to be a program called BOOTICE from a Chinese developer that apparently could do the job. I haven't tested it.


• I think Windows 10's native bcdedit command might be able to register a new UEFI bootloader, but the procedure seems a bit awkward and I haven't tested this.


• You can use mountvol X: /S as an administrator to gain access to the EFI System Partition in Windows. Once done, hide the ESP again with mountvol X: /D.