I found the most difficult part of this process was getting a linux live cd that would boot up under EFI...which is essential. The only one I could get to work consistently for my motherboard was a USB stick with an ARCHBOOT image.

Get the EFI Shell program and make sure you can get that to run. It should go in "$EFI_MOUNT/efi/boot/bootx64.efi". This is a command line (actually a pretty horrible MS-DOS clone) that can start GRUB2 or a kernel from the EFI partition if your normal boot sequence breaks. Watch out as there's two different versions of it for different versions of EFI.

GRUB2 is pretty awkward to install and you need to get the cmdline switches exactly right. Use sys-boot/efibootmgr to see if it's added itself to the firmware boot list.

If you're using GRUB then you don't need a kernel in the EFI partition, but it's a good idea to keep a working one around as a rescue method.

Yes, systemrescuecd does have the possibility to boot in UEFI...it didn't work for me for some reason, but it might work for you.

First, you really need to get your system booted up with a linux CD in UEFI mode...you can't go anywhere until you successfully do that...and it may or may not be easy.

You must confirm you are booted in UEFI mode by looking for /sys/firmware/efi/. If that efi directory is there and populated, you are in UEFI mode. If that directory isn't there, you may need to manually install the efivars kernel module. On some live cds, I had to do that...including the ARCHBOOT cd image I used.
Again, there is no way to install grub2 until you are in UEFI mode.

After that, it's pretty simple...just follow the instructions under the UEFI/GPT section of the GRUB2 wiki:

Here's some general info on configuring grub, but really, it's pretty straightforward once you get past the initial step of booting up.

GRUB2 uses a generated grub.cfg now. User modifications are made to files in the /etc/grub.d directory with contains the menu entries and an /etc/defaults/grub config file. The /etc/defaults/grub is primarily for the more 'automated' configuration...which never worked for me. I manually created my own grub entries in /etc/grub.d. Here's my /etc/grub.d/15_gentoo file:

There are some good tips so far in this thread, but also some misconceptions and lack of important information. Some key issues:

Most modern x86-64 motherboards can boot in either (U)EFI mode or in BIOS mode. Thus, you can choose which you want to use. EFI-mode boots offer some minor advantages, such as (possibly) being a bit faster and the ability to boot without GRUB (which IMHO is a monstrosity); but EFI-mode booting is also very much a bleeding-edge technology. In the short run, if you're familiar with BIOS-mode setup and don't want to learn the EFI stuff quite yet, it's simpler to stick with a BIOS-mode installation. OTOH, the industry is moving to UEFI pretty rapidly these days, so sooner or later you'll have to learn it.

In gdisk, the partition type code EF00 refers to an EFI System Partition (ESP), which is a FAT partition that holds an arbitrary number of boot loaders, boot managers, EFI drivers, and other EFI software and configuration files. The type code EF02 refers to a BIOS Boot Partition, which is a storage area for raw code used to hold GRUB 2's second-stage boot loader.

The ESP should officially hold a FAT32 filesystem, although in practice FAT16 usually works, and occasionally it works better than FAT32. The EFI spec is mute on the subject of the ESP's size. Microsoft creates a 100 MiB ESP by default, and Apple creates one that's 200 MiB. My own recommendation is to size it somewhere between 100 MiB and 500 MiB, depending on how you intend to use it. Some boot loaders, such as the kernel's EFI stub loader and ELILO, require that the EFI be able to read the kernel and the initrd file. The easiest way to ensure that this is possible is to put these files on the ESP. Thus, if you use one of these boot loaders, a large (200 MiB or bigger) ESP is advisable, so that you've got room to store multiple kernels and initrds, especially if you multi-boot multiple distributions or over time as these files' sizes inevitably creep upward. OTOH, if you use GRUB to boot, it can read the kernel and initrd from another partition, so the ESP can be in the 100-200 MiB range.

In Linux, the ESP is conventionally mounted at /boot/efi; however, some users mount it elsewhere. Mounting it at /boot can be convenient, since kernels normally get stored at /boot, which automatically puts them on the ESP.

If you boot in BIOS mode, the BIOS Boot Partition can be quite small -- something like 32KiB worked at one time, although I hear some recent versions aren't happy with anything smaller than about 2 MiB.

If you're uncertain of which way you want to boot, you can always create both an ESP and a BIOS Boot Partition. That way, you can switch boot modes relatively easily. (Your Linux installation itself needs no changes to switch boot modes; you just need to switch the firmware's configuration and possibly install or update a boot loader.)

IMHO, GRUB 2 on EFI is the worst possible boot configuration. In my experience on three UEFI PCs and one Mac, GRUB 2 has been unreliable, flaky, and just generally awful. It often works initially but then starts failing to boot. Other times it doesn't work at all. IMHO, ELILO and Fedora's patched version of GRUB Legacy are both superior to GRUB 2, and the kernel's EFI stub loader is better still. See my Web page on the topic for more information about EFI boot loader options.

Installing an EFI shell program can be useful. It normally goes in the ESP's root directory as shellx64.efi or something similar, although this isn't really standardized. Some EFIs provide an option to launch the shell, but others don't. For the latter, either installing the shell as a boot loader (so that it appears in the firmware's boot menu) or adding it to another boot manager program (such as GRUB or rEFInd) can make it available. (In fact, rEFInd has an option specifically to launch an EFI shell.)

FWIW, I maintain rEFInd, which you might or might not want to use. I've designed it specifically to help manage Linux boots with the kernel's EFI stub loader; with the right options, simply installing a new kernel (and its matching initrd, if necessary) on the ESP or another partition that the EFI can read will make it bootable, with no configuration file changes for the new kernel required.

Nice response srs5694, I gonna stick with the BIOS-mode, but I will create the EF00 partition and the EF02 partition too, just to be sure that in the future, I can stick with the method that I want._________________Sysadmin of GentooQuébec.org Wiki Signature
IRC on Freenode : #gentoo-quebec

I don't know if EFI-mode booting is enabled with the default firmware settings, but I'm pretty sure that Intel has been shipping EFI-based motherboards for at least two or three years. I know I've got EFI support on an Intel motherboard that I bought at least two years ago. I recommend you read your manual to see what the options are. (Download the manual in PDF form and use a PDF viewer's search function to search for "EFI" and "legacy.") Find the EFI options on your actual computer and set them however you want. If you need specific advice on this, post information on the options your board has -- they vary greatly from one system to another, so it's impossible to offer general advice on how to set the options to achieve a particular goal.

By the way, anyone is able to boot with Grub2 inside a UEFI enviromnent right now ?

If so, can you post how you did it with Grub2, because right now, it's not working on my side.

Right now, I'm using the Legacy boot mode to boot my Linux, since my UEFI setup is not working.

I've used GRUB in EFI mode, but it's not my preferred way of booting. The best GRUB instructions I know of are the Ubuntu wiki's UEFIBooting page (which used to be hosted on the GRUB site, but they inexplicably removed it, so the Ubuntu people picked it up). A simpler introduction exists on my Web page on the subject.

For EFI-mode booting, I prefer to use the 3.3.0 or later kernel's EFI stub loader, which turns the kernel into its own boot loader. In my experience, this is the most reliable way to boot an EFI-based computer into Linux. The problem is that this boot loader is only a boot loader. If you need to select which kernel to run, or especially which OS to run, you'll need a boot manager on top of that. Many EFI implementations provide a boot manager, but most of these are pretty poor. Thus, you may want to use my rEFInd or the simpler gummiboot boot manager.

The directory "/sys/Firmware/EFI" doesn't exist even on EFI systems; it should be "/sys/firmware/efi" (all lowercase).

The first command in the "Installing Grub2 with the UEFI mode" section is "mount /dev/sda1 /boot/efi"; however, there's no guarantee that the ESP will be on /dev/sda1. You should instruct readers how to identify the ESP via gdisk or parted.

The command "mkdir -p /boot/efi/{EFI/BOOT,GRUB2}" is likely to be confusing to somebody who needs to read this documentation. Even expressed this way, it should be "mkdir -p /boot/efi/EFI/{BOOT,GRUB2}" -- the EFI directory of the ESP holds the subdirectories that hold boot loaders, so it's not optional. Several subsequent commands omit the EFI directory. This might work for you, but it doesn't conform to the expectations in the EFI spec, so it's conceivable that such installations will cause problems down the road.

It looks like you're configuring GRUB to look for grub.cfg on the ESP rather than in /boot/grub. This is good; it's far better this way than what Ubuntu does, since it renders the system more resilient to removal of Linux or damage to the /boot partition (or the root partition, if you don't split off a separate /boot).

You should point out what might need to be changed in the efibootmgr command near the end. Also, you need either doubled-up backslashes or quotation marks around single backslashes in the filename passed to the --loader parameter. Using both is redundant. I'm sure it works on some systems, but some might flake out when they see that.

I realize that's a page on GRUB, but you might want to point out that alternatives to GRUB exist for EFI-based computers. GRUB 2 is familiar to users of BIOS-based systems, but IMHO it's far from the best choice for most EFI users, and a comment that other alternatives exist is worth including somewhere.

The directory "/sys/Firmware/EFI" doesn't exist even on EFI systems; it should be "/sys/firmware/efi" (all lowercase).

I changed for /sys/firmware/efi, thanks for this one

srs5694 wrote:

The first command in the "Installing Grub2 with the UEFI mode" section is "mount /dev/sda1 /boot/efi"; however, there's no guarantee that the ESP will be on /dev/sda1. You should instruct readers how to identify the ESP via gdisk or parted.

This guide is part of an installation guide, so the user knows that the /dev/sda1 is the ESP partition.

srs5694 wrote:

The command "mkdir -p /boot/efi/{EFI/BOOT,GRUB2}" is likely to be confusing to somebody who needs to read this documentation. Even expressed this way, it should be "mkdir -p /boot/efi/EFI/{BOOT,GRUB2}" -- the EFI directory of the ESP holds the subdirectories that hold boot loaders, so it's not optional. Several subsequent commands omit the EFI directory. This might work for you, but it doesn't conform to the expectations in the EFI spec, so it's conceivable that such installations will cause problems down the road.

I changed that one too.

srs5694 wrote:

It looks like you're configuring GRUB to look for grub.cfg on the ESP rather than in /boot/grub. This is good; it's far better this way than what Ubuntu does, since it renders the system more resilient to removal of Linux or damage to the /boot partition (or the root partition, if you don't split off a separate /boot).

srs5694 wrote:

You should point out what might need to be changed in the efibootmgr command near the end. Also, you need either doubled-up backslashes or quotation marks around single backslashes in the filename passed to the --loader parameter. Using both is redundant. I'm sure it works on some systems, but some might flake out when they see that.

I realize that's a page on GRUB, but you might want to point out that alternatives to GRUB exist for EFI-based computers. GRUB 2 is familiar to users of BIOS-based systems, but IMHO it's far from the best choice for most EFI users, and a comment that other alternatives exist is worth including somewhere.

By the way, do you know if there will be an official refind Gentoo package ?

I don't know. According to this thread, somebody was working on an ebuild of rEFInd a while back, but I don't know if it's going to make it into the official tree. One stumbling block has been a very outdated version of GNU-EFI; however, I just received notification that this bug report I filed a while back on this issue has received attention, so a newer version should be out soon. OTOH, the version to which they've updated hasn't worked for me, so this may make matters worse. (Maybe not, though; it could be a quirk on my end that's caused problems.)