If Ubuntu is installed on the computer but you can't boot it because it lacks a boot loader, you must first ascertain whether it's installed to a GPT disk or an MBR disk. The former are generally used in EFI-mode boots and the latter are generally used with BIOS-mode boots, although that linkage is not nearly as strong as it is with Windows. If you've got an MBR disk but want to boot in EFI mode, or a GPT disk and want to boot in BIOS mode, you should re-assess your situation to decide what to do -- proceed with an unusual configuration, change the partition table type, or change the boot loader type.
Assuming you've got (or convert to) a GPT disk and want to install an EFI-mode boot loader, there are many options. The two easiest are:
- GRUB/Boot Repair -- Boot the Ubuntu installer in EFI mode, install the Boot Repair program, and run it. This should set up GRUB correctly on your disk. The biggest caveat is that, although Boot Repair usually works, sometimes it doesn't, and on rare occasion it can actually make matters worse. Of course, since you're unable to boot now, the risk of it getting worse seems pretty remote.
- rEFInd -- You can disable Secure Boot (if it's active), download the USB flash drive or CD-R version of my rEFInd boot manager, and boot from it. rEFInd should enable you to boot Ubuntu. If this works, install the PPA or Debian package version. rEFInd will then become your default boot manager, enabling you to boot without GRUB. This approach is a little more incremental -- the risk at each step is quite low, since you're either not changing the disk or you know that the program is almost certain to work when you make on-disk changes.
If you continue to have problems, or if you don't have a GPT/EFI setup, you should post back with details. The URL provided by Boot Repair will show us details about your system, which may be necessary to give a better answer. Alternatively, you can run Boot Info Script, post the RESULTS.txt file that it generates to a pastebin site, and post the URL to your document here.
EDIT:
Your symptoms are consistent with a buggy firmware; some manufacturers are known to release computers with buggy EFIs that "forget" or ignore their boot entries. Your question, though, implies that this all worked fine with your Elementary OS installation. That, in turn, suggests that the firmware's NVRAM entries are damaged in some way, thus preventing new entries from being recorded. This is also a bug, but it might be overcome.
One thing to try is entering your firmware's setup utility and selecting the option to reset all the settings to their default values. Unfortunately, I can't tell you exactly where that option is, since it varies from one firmware to another. (It's even possible that yours won't have such an option.) When this is done, you can try running Boot Repair again or install rEFInd as described above, and with any luck the repair will succeed.
Another thing you might try is the EasyUEFI program in Windows. You can use this to re-order existing entries, delete existing entries, and create new entries. You should be able to create an entry for Ubuntu (\EFI\ubuntu\shimx64.efi -- note the use of Windows-and-EFI-style backslashes as directory separators) and test it. You could also use EasyUEFI to clear out any extra or redundant entries -- but the efibootmgr output in your Boot Repair run makes it look like there's nothing suspicious or redundant to be cleared out. Still, checking with another tool (that is, EasyUEFI) may be worthwhile.
