multi-booting linux distros advice

[3fRI]

Trying out Linux distros via a live CD is fine to get a taste, but sometimes I like to actually install the distro and try it for a spell. I've had no problem installing Ubuntu-based distros side by side, but when I try to install and dual-boot Mint with a non-Debian base distro such as CrunchBang or PCLinux, nothing boots and I receive a boot error message. Consequently, I have to re-install MInt. Is this a Grub issue or is there a specific way to set up the boot partitions as noted in this link: viewtopic.php?f=46&t=98998&p=563649&hilit=boot+error+message#p563649

[srs5694]

My first piece of advice is to use a virtual machine, such as VirtualBox, rather than a side-by-side installation, at least for initial evaluation purposes, and sometimes for more than that. This works well for many purposes and avoids partitioning and boot loader headaches. If you don't like the distribution you're trying in this way, you can remove it by deleting its virtual machine files. If you decide you like it well enough to make it your primary system, then you can deal with the hassles of multi-booting or replacing an existing installation.

My second, and more tentative, suggestion is to get a computer with (U)EFI support, or to begin booting in that way. I'll say up front that EFI can be problematic because of buggy firmware implementations, poor distribution support, and lack of expertise on the part of users. On the other hand, EFI was designed with a better partitioning system (GPT rather than the ancient MBR) and a boot loader system that permits side-by-side boot loader installations. Ideally, each boot loader handles one OS, and a boot manager in the firmware handles switching between the boot loaders. In practice, many firmware implementations have very poor boot managers, so you'll have to use a separate boot manager, such as rEFIt or rEFInd, or even the chainloading functionality of GRUB. Overall, then, EFI can make multi-booting much easier, but you'll have a learning curve to deal with before you get to the point where it's beneficial. You must also have EFI-capable hardware. Prior to about a year ago, few PCs were EFI-enabled, but most PCs sold today do have EFI capabilities.

[MikeF90000]

My first piece of advice is to use a virtual machine, such as VirtualBox, rather than a side-by-side installation, at least for initial evaluation purposes, and sometimes for more than that.

Very good suggestion for either newbies or more experienced Linux users.

My second, and more tentative, suggestion is to get a computer with (U)EFI support, or to begin booting in that way.

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.
Some hints for starters:
- create a standalone 'rescue' CD to repartition your HD using gparted. My favorite is the user friendly Parted Magic.
- create a rescue partition and install a rescue or frugal type distro in it - these are easier to recover. I suggest Puppy Linux or even Parted Magic. Either grub-legacy or grub2 can be installed by these distros, to your preference.
- if you have occasion to use Windoze, install it first in a primary partition.
- install the Linux distros next and let them install 'their' grub to the volume boot record (non-default) not the MBR. grub2 will complain but will do it with the --force option if needed.
Sample disk layout:
sda1 (primary, ext4) - puppy w/frugal install
sda2 (primary, ntfs) - windows system/boot
sda3 (primary) - linux swap or windows system
sda4 - (extended)
sda5, 6, etc (logical, ext4) - as many linux, bsd, etc partitions as you need

To the OP, fixing the original boot error requires more details and investigation. I suspect that during installation an inappropriate choice was made.

[3fRI]

Thanks SRS and Mike, I'm already using EFI/rEFIT and gparted/Parted Magic and will try a virtual machine next.

[wayne128]

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
2. Use a master boot loader which is easy to maintain and learn as well as consistent
2.a. grub legacy fit the bill
2.b. on win7, win vista side I use EasyBCD as boot manager, it can handle all sorts of OS
save trouble.

3. I partition in a way to easily maintain, change, delete, add, clone
example is
sda1 a linux OS controlling MBR with master boot loader
sda2 a swap shared by all Linux OSes
sda3 a ntfs for win OS
sda4 extended
sda5 a ntfs data partition shared by win OS and all Linux
sda6,7,8,...20...30 one partition per OS.

4. chain load from grub legacy to any other Linux OS root partition, chainload to Win OS by default.

to do this, always install Linux OS with their own boot loader onto root partition, yes onto root partition, so that they become chainloadable by grub legacy as well as other boot manager.

hope this gives some ideas for you to consider

[srs5694]

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".)

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.

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").

[3fRI]

Thanks again for the informative feedback.

FWIW, I'm not running Windows. I'm using rEFIT to dual-boot Mac OS X (10.6.5) and LM 12 Cinnamon on the iMac. My MacBook is no longer a MacBook per se since I'm only running LM 12 LXDE on it, which boots via GRUB 2. I'm now using Virtual Box to test different distros, and will stick with that for the time being.

[srs5694]

Thanks again for the informative feedback.

FWIW, I'm not running Windows. I'm using rEFIT to dual-boot Mac OS X (10.6.5) and LM 12 Cinnamon on the iMac. My MacBook is no longer a MacBook per se since I'm only running LM 12 LXDE on it, which boots via GRUB 2. I'm now using Virtual Box to test different distros, and will stick with that for the time being.

One thing to keep in mind is that VirtualBox uses BIOS boot mode by default, although it does support EFI, as well. This might be important if you decide to start using a distribution you tested in VirtualBox directly on the Mac's real hardware, since anything you learned about booting that distribution in BIOS mode might not apply if you try to boot it in EFI mode on the Mac. There are many possible ways to install Linux on a Mac, so it's impossible to give specific advice on what you might need to change or un-learn, but you should be aware that you may need to make some adjustments to partitioning and boot loader installation and configuration.

[urbanomad]

Hello srs, I have been trying to get Linux Mint 13 64-bit Cinnamon to boot (it installed fine on the second go), but it doesn't show in the rEFInd menu as a bootable OS. The partition is formatted as ext4fs. I followed your instructions up to the super grub 2 disk which never booted and gave me an error, hit any key to continue. I am running on iMac9,1 with 10.7.4 and I also do not have Windows installed and why I'm posting here as well. Any thoughts would be greatly appreciated.