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.
In theory, you should be booting just fine, or at the very least getting to a GRUB boot menu when you boot. The fact that you're not suggests you've got a defective EFI. I therefore recommend that you check your manufacturer's site for an update. (Most manufacturers call their EFIs "BIOSes," although really they aren't.) If that doesn't help, try the following, in sequence, stopping once you get Linux booting:
- Re-run Boot Repair again.
- Boot to an emergency system, mount
/dev/sda1 somewhere, create a directory on that partition called EFI/BOOT, and copy EFI/ubuntu/grubx64.efi to EFI/BOOT/bootx64.efi.
- Try using a USB flash drive or CD-R version of my rEFInd boot manager. If it boots up, select either of the
vmlinuz* options, hit F2 or Insert twice, and add ro root=/dev/sda3 to the boot options. If this boots Linux, try installing the Debian-package version of rEFInd. In theory, this should get the computer booting using rEFInd, and without a need to use F2/Insert to add kernel options.
- If rEFInd doesn't come up when you reboot, then boot to Linux via the rEFInd USB/CD-R and type
sudo mvrefind.sh /boot/efi/EFI/refind /boot/efi/EFI/BOOT in a Terminal window.
- If that doesn't bring rEFInd up, reboot into Linux and type
sudo /boot/efi/EFI/BOOT /boot/efi/EFI/Microsoft/Boot.
- If that doesn't bring rEFInd up, then return the computer to the store for a refund; it's hopelessly defective. One caveat: If you can get to rEFInd but Linux isn't working, it's possible you've got an encryption/LUKS problem. I've never used this technology, so I'm not sure of precisely how it interacts with boot loaders, particularly on EFI systems.
Best Answer
Your Boot Repair output looks OK to me -- as far as I can tell, you should be booting to GRUB when the computer starts up. It could be you've got buggy firmware, though, so you might check Sony's Web site for an update. (Of course, if you need to boot Windows to update the firmware, that could get ugly.) If you can update the firmware but the problem persists, re-running Boot Repair might fix the problem.
Another thing you can try is preparing a CD-R or USB flash drive with my rEFInd boot manager. (There are download links for both media types on that site.) If rEFInd boots, it should provide a menu with various options. The Windows option should work, as should an Ubuntu option that boots via GRUB. There should also be at least one option to boot a
vmlinuz*file. This one won't work unless you hit F2 or Insert twice to edit the kernel options. Addingro root=/dev/mapper/ubuntu--vg-rootshould work. If you can get into Linux via rEFInd, you can try installing the rEFInd Debian package. Ordinarily, this would set up rEFInd as your default boot manager, thus solving your problem. (This will also obviate the need to add kernel options manually.) Unfortunately, given the nature of your problem, I'm not sure this will work for you, but it's worth a try.If installing rEFInd to your hard disk doesn't work, you could keep fiddling with EFI firmware settings in an effort to find a workaround. Check the Installing rEFInd Manually and Alternative Naming Options sections of the rEFInd documentation for some ideas. Alternatively, if a USB flash drive does the job as a workaround, you could buy a small USB flash drive to hold rEFInd and leave it permanently installed in one of your computer's USB ports. (Some drives are very small -- nearly flush when fully inserted.)
One more comment: Your Boot Repair output indicates inconsistent naming of the volume group that holds your root (
/) filesystem. Sometimes it's/dev/mapper/ubuntu--vg-root, but other times it's/dev/mapper/ubuntu-vg-root. It looks to me like the former is correct and the latter is a result of a bug in the Boot Repair script itself, but it's worth keeping this inconsistency in mind. I vaguely recall hearing of a case in the past when somebody used a dash (-) in a volume group name and it caused problems, but I don't recall the details. It's unlikely that this is the source of your current problem, since it sounds like nothing that could read the volume group is even launching, but if you get rEFInd or GRUB to launch but then run into problems getting the system to fully boot, you might just try deleting the whole physical volume and re-installing again, this time using a volume group name that lacks a dash.