This is probably a Secure Boot issue, at least in part. (Selecting the correct EFI-mode boot option may be part of the issue, too.) On the one system I've got that can handle Secure Boot, enabling it and trying to boot from a disc that can boot in either EFI or BIOS mode, but without a valid Secure Boot signature, results in a BIOS-mode boot, even if I tell the computer to boot in EFI mode. This behavior exactly matches your description of what's happening to you. Furthermore, you say this is a new computer with Windows 8 installed, which means that it almost certainly shipped with Secure Boot active.
If I'm right, you have three options for how to proceed:
- Disable Secure Boot in your firmware -- this is the easiest method if you're familiar with setting basic firmware options, but you'll need to track down the right one.
- Install using a distribution that's been signed with a Secure Boot key -- Ubuntu 12.04's installer has not been so signed, AFAIK, but I suspect that Ubuntu 12.10's has been. I'm not positive of that, though. (I've not yet tested it on my Secure Boot-capable PC.) Fedora 18 is supposed to be signed, but it's not yet been released, and I'm not sure of the status of whatever pre-release version is out there.
- Create your own Secure Boot keys, sign everything yourself, and use Secure Boot in that way. This is the hardest approach by far.
For more information on all of these approaches, see this Web page I wrote on the subject. Note that the Web page says nothing about OS installation. Most of the issues and procedures would be the same for OS installation as for anything else, but modifying files on an installation CD is trickier than modifying files on a USB flash drive, so keep that in mind when you're considering your options.
Addition: I can think of a number of reasons why you might be getting an "Operating system not found" message even when booting in EFI mode with Secure Boot disabled. I suggest you check the following:
- Check your Secure Boot setting again. Yes, I know you said you've disabled it, but firmware settings can be tricky sometimes. It's worth double-checking.
- Using gdisk or parted, verify that the USB drive you're using has a valid GUID Partition Table (GPT) with an EFI System Partition (ESP; identified as partition type code EF00 in gdisk, or by a "boot" flag in parted). If the disk uses an MBR partition table, a fussy firmware might reject it. Likewise if it lacks an ESP.
- If the disk uses a hybrid optical disc/hard disk configuration (as some installation disk images do), it could be that a fussy firmware will reject it. In this case, backing it up, creating a fresh GPT on the disk with a new ESP, and restoring everything on a file-by-file basis might get it working.
- Mount the ESP and look for a file called
EFI/BOOT/bootx64.efi
. (Case shouldn't matter; but see below.) This is the boot loader file. If it's absent, the disk won't boot. You'll need to figure out what happened to the file and restore it.
- Although the FAT filesystem used on ESPs is case-insensitive, I've encountered one badly broken EFI with case sensitivity issues. Messing with the filename case might fix it, but there are a lot of possible variants.
- Check that the ESP uses FAT32, not FAT16. Most EFIs seem to be happy with both, but the spec does say the ESP should be FAT32, and I know of one implementation that's unhappy with a FAT16 ESP.
You could also try booting something else in EFI mode. One possibility is rEFInd, which is an EFI boot loader that, if you can get it to boot, it may be able to detect and run the Ubuntu installer's boot loader. There's a CD image of rEFInd, but that really is a CD image, not a USB image. To create a USB image, you'd need to download the binary file and install it manually. Tip: There's a new install.sh
script that's available here. (It's destined for the next release, but that release isn't finalized yet.) This version of the script includes a new option, --usedefault
, that can be used to help create a bootable USB flash drive. You'd use it like this:
sudo ./install.sh --usedefault /dev/sdc1
This example should create an EFI-bootable USB flash drive on /dev/sdc1
, provided that partition is an ESP on the USB flash drive. Note that you must partition the disk and create a FAT ESP before running install.sh
.
One more possibility is to install in BIOS mode and then sort it out later. You can install rEFInd, gummiboot, or an EFI-enabled version of GRUB after installing in BIOS mode. You might need to jump through some hoops with renaming boot loaders to get things working, but if you can't get your installer to boot in EFI mode, this may be your only option.
There are many ways to do this, but the procedure I recommend, in broad strokes, is this:
- Start with an EFI-based x86-64 (AMD64) computer. Don't bother trying to install in BIOS/CSM/legacy mode, since this will complicate your GRUB installation and configuration, particularly if the target system boots with Secure Boot active.
- Unplug all the hard disks from the computer you'll be using for the installation.
- Plug in the target USB flash drive and an Ubuntu x86-64 (AMD64) installation medium and boot to the latter. Note that you must install an Ubuntu of the same architecture as the target computer's firmware. This is normally AMD64. Do not use the i386 version of Ubuntu.
- Install normally. Use automatic partitioning or set things up manually, as you see fit; but if the latter, be sure to create an EFI System Partition (ESP).
- Once Ubuntu is installed, using any convenient computer, mount the ESP from the USB flash drive,
cd
to its EFI
directory, type sudo cp -r ubuntu BOOT
and then sudo mv BOOT/shimx64.efi BOOT/bootx64.efi
. (Or issue equivalent commands in another OS.) The point here is to install Shim as EFI/BOOT/bootx64.efi
on the ESP of the USB flash drive, while keeping its follow-on grubx64.efi
and grub.cfg
files accessible.
At this point, the USB drive should be bootable on any EFI-based computer of the same architecture as the target system (AMD64 in this example), give or take hardware incompatibility issues.
An important warning: The computer you use for the installation may no longer boot its OS, even after you plug its hard disk back in, because it may have wiped its NVRAM boot variables after you unplugged its hard disk. If the computer was running Windows, it will probably boot to Windows; but if it had been running Ubuntu or some other Linux, you may need to use the efibootmgr
command to create a new boot entry or Boot Repair to completely re-install GRUB. There are ways around this problem, but they're surrounded by a swirl of conditionals -- if the disk is set up this way, then that; if the computer boots in this way, then this other thing. Dealing with these would double or triple the length of the procedure I've just presented. Repairing the broken boot afterwards is likely (but not certain) to be simpler, and is certainly simpler for me to describe. OTOH, there's a chance that this will create a new mess of a problem, so you should be aware of the possibility.
Best Answer
Solved I reinstalled in UEFI mode and now it boots into my OS as it should. The issue was cause by initially installing in legacy BIOS by mistake.