Windows – Can not boot to Ubuntu after installing it

Using Boot Repair, as MariusMatutiae suggests, may work; however, that program sometimes does more than is wise, so I prefer to avoid it. There are at least three less radical solutions:

Solution 1: Use the Firmware

Many EFIs provide a built-in boot manager that enables you to adjust the boot order. Your Ubuntu/GRUB entry probably still exists, so all you need to do is to adjust the boot order using the firmware. The trouble with this approach is that the EFI setup utilities vary so much that it's impossible to provide universally-applicable instructions for how to do this. If your firmware supports this feature, though, it's likely to be the simplest way to do it -- once you figure out how to get to the option!

Solution 2: Use bcdedit in Windows

The Windows bcdedit tool can add a non-Windows boot loader to the boot list. The trick is figuring out what the file is. You can do it this way:

1. Boot to Windows
2. Open an Administrator Command Prompt window. (Don't use a third-party shell for this, either; I've seen reports that bcdedit won't work correctly with some of them.)
3. Type mountvol S: /S to mount the ESP as S:. (You can change S: to something else if you like.)
4. Using the Command Prompt, check S: to locate your Ubuntu boot loader. It's probably either S:\EFI\ubuntu\grubx64.efi or S:\ubuntu\shimx64.efi. If you see the latter, it should be safe to use it, and it may be necessary to use it -- shim is how Ubuntu deals with Secure Boot (SB), but on a non-SB computer, it will have little effect. If Secure Boot is inactive, then shim may or may not be installed, so you may need to refer to grubx64.efi directly.
5. Type bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi, changing shimx64.efi to grubx64.efi if shimx64.efi isn't present. Change the path if it's something else, which is unlikely.
6. Optionally, type bcdedit /set {bootmgr} description "Ubuntu" to set the name that appears in the EFI's own boot manager list. Change Ubuntu to whatever you like.

If you already know the filename for your boot loader, you can skip steps #3 and #4. (The ESP doesn't need to be mounted to use bcdedit in this way.)

This method has the advantage that it keeps Windows from messing with the boot order -- sometimes Windows will try to adjust the boot order unbidden. I don't know if this would prevent a repeat of this problem if/when you upgrade to whatever comes after Windows 8.1, though.

Solution 3: Boot to Linux and Use efibootmgr

You can probably boot to Linux by using the firmware's own boot manager, which you can access on most computers by hitting Esc or a function key at boot time, although which key varies from one computer to another. Alternatively, you may be able to use rEFInd on a USB flash drive or CD-R as a boot manager if yours is inadequate. You can also boot using a Linux live CD or emergency disk, but be sure you boot in EFI mode -- a BIOS-mode boot won't be adequate. Once you're in Linux, you can use efibootmgr to adjust the boot order:

1. Open a Terminal window.
2. Type sudo efibootmgr -v to obtain a list of boot programs. One will be for Linux, and will launch either shim or GRUB. Note the BootOrder list. Chances are the Windows entry is now first, and the Ubuntu entry comes later in the list. Some entries may be confusing. Just ignore them; focus on finding the Ubuntu entry and identifying its number (in the Boot#### entry at the start of the line).
3. Type sudo efibootmgr -o {list}, changing {list} to a comma-separated list of boot numbers, as in sudo efibootmgr -o 5,0 if Boot0005 is for Ubuntu and Boot0000 is for Windows. You can add more entries if you like, but the first one is the most important, since that's what will be booted first.

If an Ubuntu entry does not exist, you can create one with efibootmgr, as in:

efibootmgr -c -d /dev/sda -p 1 -l '\EFI\ubuntu\shimx64.efi' -L "Ubuntu"

Change -d /dev/sda to point to your whole-disk device and -c 1 to specify the partition number. (In fact, /dev/sda and 1 are the defaults, so you really need these only if your ESP is not /dev/sda1.)

This is a common problem with Windows 8.0 and 8.1 machines.

With Windows 8.0, Microsoft no longer relies on an efi file to boot windows, they use a more advanced format for speed up the boot process and keep more persistence between reboot cycles. Sadly, GRUB cannot yet detect this boot format.

The proper way to dual boot Windows 8.1 is to first disable quickboot and secureboot in BIOS, then boot into Windows. This will force the the windows bootloader to generate an efi file for other bootloaders like GRUB.

You of course, have a bigger problem because you now have a GRUB bootloader and thus cannot force Windows 8 to generate the efi file. To do this, ensure quickboot and secureboot are disabled. When you are at GRUB, press c to drop to the GRUB command line. Boot to Windows using the following command:

chainload (hd0,0)+1

You may need to use the tab-autocomplete option to find the correct partitions.

IF THIS FAILS, SEE BELOW.

Now that Windows has an efi file, reboot into Kali Linux. From a root terminal run:

sudo update-grub 

You should see a GRUB debug output line roughly equivalent to:

/dev/sdb1@/EFI/Microsoft/Boot/bootmgfw.efi

The file "bootmgfw.efi" is what you need to force the Windows bootloader to generate. You should now have a dual boot between Kali and Windows 8.

IF CHAINLOAD FAILS:

Before beginning, you need to have a Kali (or any type of Debian live cd) and the Windows recovery disk/USB. You do not need to re-install the entire system. When the Windows recovery environment starts, choose the option to open a command prompt. Run the following commands:

diskpart
select disk 0

This mounts the harddrive with Windows and GRUB.

Next run:

list volume

This should list the partitions on the disk, including the peripheral mount (your recovery cd or USB). Make a note of the drive letter. The run the following to quit diskpart:

exit

Now that you have the drive letter of the recovery partition that includes the bootloader files, enter the boot directory (you need the quotes):

cd "<your drive letter>\boot"

Now run:

dir

This lists the files in the boot directory. You should see a file named

bootsect.exe

If you don't, you're in the wrong place. Consider looking up a more in depth recovery tutorial.

Next:

bootsect /nt60 SYS /mbr

Now reboot, GRUB will not appear but Windows should start. What you've done is set the Windows bootloader as the system entry point, you have not actually deleted any partitions for either operating system including the one containing GRUB. Again, at this point, ensure quickboot and secureboot are disabled. Reboot into Windows generating the boot efi file. Now that Windows it bootable from GRUB, we need to restore it. Using your Kali/Debian live disk, boot into the Linux operating system and open a root shell. Ensure boot-repair (only available from a live disk) is installed:

sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair && boot-repair
sudo boot-repair
sudo update-grub

This will replace the Windows bootloader as the system entry point with GRUB, again in the process nothing is actually deleted.

If this isn't available as on option (it is on my Ubuntu and Kali live disks), look at your distro version's GRUB restore options.

On the update-grub command, you should see debug output resembling this:

/dev/sdb1@/EFI/Microsoft/Boot/bootmgfw.efi

Now reboot, you should see Kali and Windows options in GRUB now.

SIDENOTE:

I would not recommend a strictly Windows/Kali dualboot for a few reasons.

First, Kali uses legacy GRUB, not GRUB 2 (now 2.02). This can make dualbooting very painful and laggy on high resolution, modern displays. If you have a discrete graphics card, this can cause other problems getting booting to work properly.

Second, Kali uses a custom Kernel version (noted Kali1) for which many modern Ethernet cards do not have drivers (available as bcmwl-kernel-source for standard kernels). You either have to modify drivers, or add Debian repos for standard kernels and swap this.

Third, why Kali? It's a pen-testing distro that, comparatively (and respectfully), sucks at most everything else. If you truly are doing pen-testing, you should have separate boot, root, and home partitions, where root and home are encrypted and require passwords prior to booting that you provide to initramfs. I don't do a lot of pen-testing, but when I do I sure as hell don't write my plugins and scripts in Kali. For this reason, I always keep another Linux distro installed.

What I'm getting at here, is Kali is for experienced Debian users, who ought to know the current problems with dual-booting Windows 8. Consider installing a friendlier distro alongside Windows first, I like Ubuntu (or one of it's flavors if you're a Unity hater). Ubuntu has better documentation, and ships with GRUB 2.02 and more grub tools. This along side the community will make an initial dual-boot setup easier. Once you have a stable dual-boot setup, adding a third Linux distro is incredibly easy (although harder if you encrypt Kali root dir).

My current boot system is GRUB 2.02 with Windows 8.1, Ubuntu 14.04, and Kali (with Kali1 and generic kernels/initramfs).

Hope this helps someone along the way.