Ubuntu – Is that ok dual boot with two different firmware(Winodws vs linux, between UEFI and Legacy)

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.

For most hardware, the boot mode (EFI vs. BIOS) is irrelevant. The drivers Linux loads are identical in either case, as should be the performance. The main caveat here is that the hardware may be initialized in different ways depending on your boot mode, and if the Linux drivers make assumptions about how the hardware is initialized, one way or the other may work better. This sometimes made booting one mode or the other (usually BIOS mode) preferable in the past, but this type of problem is becoming rather rare today. This type of issue mostly affected video hardware and drivers, but in principle it could affect anything.

In your specific case, my suspicion is that you've got "bleeding-edge" hardware with poor Linux support, or perhaps hardware that requires special configuration to work correctly in Linux. Your best bet is to post separate questions about each specific device that's not working to your satisfaction. You can also test with both BIOS-mode and EFI-mode installations to determine empirically which one works better for you, since there is no way to accurately generalize which mode is best.

The correct answer to the question of which mode is best is: It depends. For instance:

• If you're dual-booting with an OS that's already installed in one mode or the other, it's almost always best to boot Ubuntu (or any other Linux) in the same boot mode as the one that's already in use.
• Using BIOS/CSM/legacy mode almost always complicates the boot process, as described in detail on this Web page of mine. The result is that enabling BIOS-mode booting makes problems more likely to crop up, especially if you've already got an EFI-mode OS installed.
• Knowledge of BIOS-mode boot processes is more widespread, which can counter the preceding issue on a single-OS system.
• As I've described, some hardware initialization issues can favor one boot mode or the other (usually BIOS mode is easier to get working). Such problems seem to be fading in frequency, though.
• EFI-mode booting is usually a bit faster than BIOS-mode booting, although details differ from one OS to another.
• Your choice of boot loaders is somewhat different. If you venture beyond the default GRUB, you might prefer something that's available in only one boot mode. Currently, this would tend to favor EFI, since there are some EFI-specific boot managers (gummiboot, rEFIt, and rEFInd) with no BIOS counterparts; but AFAIK the only BIOS-specific boot program for Linux without an EFI port or workalike are BURG and LOADLIN, both of which are (AFAIK) abandoned.
• Secure Boot (a UEFI-specific feature) can help you control your boot process, preventing unauthorized code from running. If you want to, and if you're willing to put in the effort, you can even use Secure Boot to prevent Windows from running on your computer.
• On some computers, GPT presents problems when booting in BIOS mode; but GPT is the standard for EFI. GPT offers some minor advantages on sub-2TiB disks, but is required on disks larger than that. (Assuming 512-byte logical sectors; but larger logical sectors are iffy for booting in BIOS mode, and are very rare on internal disks.)

If you need a more specific "BIOS" or "EFI" answer as to which you should use, you'll have to provide much more specific information about your setup.