Thanks SRS and Mike, I'm already using EFI/rEFIT and gparted/Parted Magic and will try a virtual machine next.
If you're already using EFI, then you may want to look into rEFInd.
It's my fork of rEFIt that adds new features, including support for the new Linux kernel EFI stub loader,
which essentially turns the Linux kernel into its own boot loader. In my experience, the EFI stub loader is the most reliable Linux EFI boot loader; it lacks GRUB 2's bloat and unreliability, it's better at keeping video working right than Fedora's patched GRUB Legacy, and it doesn't freeze 32-bit systems the way ELILO does. The combination of rEFInd with the EFI stub loader makes kernel upgrades easy; just copy the kernel and initial RAM disk, using the right filenames, to your distribution's Linux kernel directory on the ESP (or some other partition that the EFI can read) and it should boot, with no need to edit configuration files or run scripts to detect the new kernel. The big problem with this approach is that it's so new; you need a 3.3.0 or later kernel (or some earlier versions with patches applied) to get it to work, and to the best of my knowledge no distribution yet supports either the EFI stub loader or rEFInd, so you'll need to do the initial setup and kernel copying manually. If you're up to these challenges, this approach makes the old BIOS/GRUB method look like something from a medieval torture chamber. If not, you'll have to wait a while for kernels with EFI stub support, and perhaps rEFInd packages, to make their way into your distributions.
If you can't use the EFI stub loader, then I recommend using ELILO or possibly Fedora's patched GRUB Legacy. Both are much less finicky than GRUB 2. See my EFI boot loaders Web page
for more information on all of these boot loaders. If you set up either rEFIt or rEFInd as your primary boot manager, you'll be able to launch ELILO and/or GRUB Legacy installations for each of your distributions with no problems.
Note that Linux installers can do any number of things when you install them. If you install in BIOS mode, the BIOS-mode boot loader will be irrelevant, unless your firmware notices it and decides to switch to BIOS-mode booting as a result. If you install in EFI mode, then ideally the new boot loader will stay out of the way; however, it's likely to become the default boot loader, so you'll need to use your firmware's user interface or the efibootmgr utility to switch back to the original boot manager (rEFIt in your current setup). Ubuntu, and Mint IIRC, has a serious bug that causes it to wipe out all previously-installed EFI boot managers when installed in EFI mode. This is supposedly being fixed in Ubuntu 12.04.
For these reasons, I recommend a few preventive measures:
- Back up your ESP before you install a new distribution. That way, if you run into problems like a trashed ESP, you can always restore your original files.
- You should learn your firmware's options for managing your boot loaders. On some, these tools are limited to the point of being useless. On others, they enable you to add or remove boot loaders to the list maintained in NVRAM, select a boot loader, and so on.
- Learn to use the text-mode efibootmgr utility in Linux. Note that it will only work when you boot in EFI mode, which means it won't work from Parted Magic or most other emergency discs. (You can use it from an Ubuntu CD booted to live CD mode, though. You'll need to install it via "sudo apt-get install efibootmgr".)
MikeF90000 wrote:Whoa, IMO this a bit of overkill. Linux is very happy booting and living in any kind of partition with the classic 'MSDOS' partition table.
It certainly can be done that way; however, my advice is based on the fact that I'm on the leading edge of this transition. (I've been playing with EFI for a while, I have several Web pages on the topic, and I'm the person who forked rEFInd.) EFI booting is just starting to get to the point where it's getting better than BIOS booting. The flaws of BIOS booting boil down to two things:
- BIOS booting places one very simple boot program in control of the entire boot process. Typically, the last-installed OS takes control of the boot process, and if that's not what you want, restoring it requires jumping through a lot of hoops that are typically beyond the typical user. That last-installed boot loader is likely to overwrite whatever had been there before, making restoration impossible without accessing that program via an emergency disc. EFI boot management still has its pitfalls, and of course one program does end up being the primary boot program, but with decent implementations, restoring the boot manager you want to control the process is much easier, since a proper EFI OS installer won't trash the existing boot managers.
- The BIOS boot process involves reading boot code from non-file sources -- the MBR, the boot sectors of partitions, and elsewhere. This makes managing the process difficult, since the tools to access these locations are primitive and dangerous. With EFI, the boot process is handled by files and by data stored in NVRAM. Files are easy to manipulate, so adjusting your boot loader family is relatively easy. NVRAM data can be trickier, but at least there are dedicated tools for managing it, and these tools are less likely to cause damage than are tools like dd (which you might use to back up or restore a BIOS boot loader) or improper use of something like grub-install.
All that said, I did say that switching from BIOS to EFI was something I suggested tentatively.
The EFI tools are still immature, and Linux distributions by and large don't yet use them very well. If you understand them, though, managing them is much easier than managing BIOS installations. Thus, the tradeoff is an initial learning curve to use the best of the available EFI boot loaders (that is, not
GRUB 2) and to understand what your distribution does with respect to boot loaders when you install it, vs. an easier boot management process once you're using the best available tools. This comparison will most likely come to favor EFI more and more over time, since EFI support is improving, whereas BIOS support has been more-or-less stable for years.
wayne128 wrote:For me , my multiboot experience is with mixing all sorts of distros.
My simple method ( simple enough for me to play, delete, add, swap OS, etc ) are:
1. I use only MBR formatted drive... to stay away from GPT releted grub issue
Much of your advice makes sense in a BIOS environment, but 3fRI is booting in EFI mode, which is an entirely different ball game. Among other things:
- EFI normally uses GPT. This isn't strictly required, in theory, but some implementations require it in practice. GRUB has no issues with GPT on EFI systems, although as I've noted before, GRUB 2 is a bloated and unreliable mess on EFI systems.
- In EFI, the firmware controls the boot process, not any single boot loader. Although in practice you're likely to launch one boot manager or boot loader automatically, this detail is normally handled by an NVRAM setting rather than a place of privilege on the hard disk. This can be a subtle distinction, but it's an important one, since it's easier to switch the system between multiple installed boot loaders on an EFI system. (This is somewhat theoretical; some EFI implementations are buggy in ways that throw monkey wrenches into this issue.)
- You're less likely to need chain loading in EFI, beyond chain loading from an initial boot manager (the EFI itself or a boot manager such as rEFIt, rEFInd, or GRUB Legacy) to the boot loaders for your individual OSes.
- Because you normally use GPT with EFI, there's no way to create an extended partition; all your partitions are just "partitions" (not "primary," not "extended," and certainly not "logical").