First, some basics....
There are two critical classes of programs involved in booting a computer, under either BIOS or EFI:
- The boot manager -- This program presents a menu or otherwise enables the user to select which OS to boot.
- The boot loader -- This program loads an OS kernel into memory and starts it running.
Some programs, including GRUB and most other Linux boot loaders you may have heard of under BIOS, actually perform both functions. Thus, Linux users tend to be a little linguistically sloppy and use "boot loader" when referring to either type of program. Understanding the distinction, though, is important for EFI because some EFI programs fulfill just one function but not the other. Furthermore, EFI provides a built-in boot manager. Unfortunately, the EFI specification is mute on the subject of what sort of user interface the built-in boot manager should provide. The result is that it's almost useless on some machines, awkward on others, and barely tolerable on the best of them.
The built-in EFI boot manager can be controlled from an OS by editing EFI variables. In Linux, this task is handled by the efibootmgr utility, which is a typical bare-bones Linux command-line tool. As such, it's not really very user-friendly. When you boot the computer, you typically access the boot manager by pressing Esc or a function key, but details vary from one machine to another.
Shifting gears a bit, GRUB is designed to work in much the same way for both BIOS and EFI systems. Under BIOS, GRUB installs part of itself to the Master Boot Record (MBR), which is the first sector on the hard disk. BIOS is hard-coded to execute code in the MBR, so GRUB takes control of the computer when it boots, presents a menu, and loads a kernel or redirects the boot process to another boot loader stored elsewhere. Under EFI, the process is a bit different: GRUB registers itself with the EFI's NVRAM (at install time via efibootmgr, even if you didn't type the command yourself). The EFI's boot manager then launches GRUB, which presents a menu and launches a kernel or redirects to another boot loader.
Another key difference between BIOS and EFI is that BIOS boot loaders are stored, in whole or in part, in the MBR and other "hidden" parts of the disk. EFI boot loaders and boot managers (aside from the built-in boot manager) are stored as ordinary files on the ESP. This makes EFI a little easier to manage -- at least in theory and once you understand it.
Now, all this theory out of the way, I can more directly address your question: The bulk of Linux doesn't care about the boot mode, so converting an existing BIOS-mode install to boot in EFI mode requires installing an EFI boot loader for Linux. There are in fact several such programs available. You've alluded, directly or indirectly, to two of them, but there are others:
- GRUB 2 -- This is the default of most distributions and so is usually easy to get working on a fresh installation. OTOH, it's rather arcane and difficult to get working manually. Under both BIOS and EFI, it can read kernels from just about anywhere.
- GRUB Legacy -- This boot loader doesn't officially work under EFI, but Fedora released a heavily-patched version that did. This variant is no longer being maintained. Like GRUB 2, it can load kernels from most Linux filesystems.
- ELILO -- This boot loader is modeled after the LILO boot loader for BIOS. It's easy to configure if you're used to LILO. It requires that your kernels be stored on the ESP. It's no longer being actively developed, but it still gets the job done.
- SYSLINUX -- This boot loader is similar in broad strokes to ELILO, and is related to a BIOS boot loader of the same name. Like ELILO, it requires your kernel be stored on the ESP.
- The EFI stub loader -- The Linux kernel itself includes an EFI boot loader, so you can boot your system using nothing but the EFI's built-in boot manager and a kernel registered directly to it. Launching the kernel directly from the EFI's boot manager in this way therefore requires that the kernel be stored on the ESP (or at least on a FAT partition, or sometimes HFS+ on Macs). One of the posts to which you linked was about such a configuration, but that type of setup is uncommon and is not something I recommend because it's inflexible.
In addition to these boot loaders, there are a few dedicated EFI boot managers that can help expand your options:
- gummiboot -- This program is a simple text-mode boot manager that can launch any of the preceding boot loaders, including a Linux kernel; however, it can only redirect the boot process to a program stored on its own partition, which is normally the ESP. Thus, to use gummiboot to launch a kernel directly (via the EFI stub support) requires your kernel to be stored on the ESP.
- rEFIt -- This program originated on the Mac, and remains popular on that platform, although rEFIt has been abandoned for years. It can redirect the boot process to any partition that the EFI can read, and rEFIt includes a couple of EFI drivers enabling the EFI to read ext2/3fs or ReiserFS volumes. Unusually, rEFIt actively scans for boot loaders when it starts, which makes it very adaptable in a multi-boot environment. It's not very good at launching Linux kernels, though, because rEFIt can't pass the kernels the custom options that they usually require to work well.
- rEFInd -- This is my own fork of rEFIt. It adds drivers for ext4fs, Btrfs, NTFS, HFS+, and ISO-9660; and it enables passing options to Linux kernels. Therefore, the combination of rEFInd with the EFI stub loader provides most of the flexibility of GRUB in terms of kernel locations. rEFInd also retains rEFIt's active scanning for boot options, which can greatly reduce the hair-pulling involved in maintaining a system with multiple Linux distributions installed; when you install (or delete) a new kernel in any distribution, rEFInd picks up the change the next time you boot.
It's a little unclear to me what your current setup is, but the impression I get is that you've got at least two Linux installations, including at least one that formerly booted in BIOS mode. If so, you might want to consider using rEFInd. If it's installed as your default boot program, it will actively scan your system for kernels and create a menu at every boot. You'll need to install EFI filesystem drivers for the filesystem(s) that hold your kernels, but the install script may take care of this detail for you. You may also need to create configuration files called /boot/refind_linux.conf for each distribution; this file holds static boot options. (This is sometimes unnecessary, though; it depends on your partition layout and distribution-specific needs.) If you install rEFInd using its installation script under Linux, refind_linux.conf will be created automatically for that distribution, but you may need to create its equivalent for your other distribution(s). The rEFInd documentation includes a page on booting Linux that can help you do all of this.
If you don't want to use rEFInd, you should be able to get one distribution's GRUB to pick up the other installations' kernels. If you can boot one distribution via GRUB, running update-grub (on Ubuntu or similar distributions) or grub-mkconfig -o /boot/grub/grub.cfg should do the job. (You may need to change that output path, though; grub.cfg may be stored elsewhere on some distributions.) The trouble is that if and when you update the kernel on this second distribution, you'll need to boot into the first and rebuild the GRUB configuration file to get GRUB to recognize the new kernel. The alternative is to install GRUB twice, once for each distribution. You could then use the EFI's boot manager to pick which GRUB to launch, or configure each GRUB with an entry to the other one.
As you can see, you have a lot of options. For yet more information on this topic, see my Web page on EFI boot loaders for Linux.
I realize this isn't the step-by-step procedure you wanted, but the combination of an understanding of how things work and knowledge of your own precise setup usually works better than any sort of "cookbook" procedure, especially when the procedures are so dependent upon the details of the configuration going into the process.
