And this is what you fail to realize: This is only true for booting different systems than Linux. If you have a multiboot system with five different Linux distributions only one distribution has to have a bootloader installed to the MBR. All the other distributions can be started from that bootloader without having themselves a bootloader installed on their partitions. It just isn't needed. While they have the capability to chainload to a different bootloader, they don't have to do that.

With legacy grub, one was required to hit up LQ and spend days troubleshooting the grub.conf file. With grub2, simple commands take care of setting up grub.conf and enabling a crippled OS to boot up again.

Wrong:
Not sure about lilo, but grub works in stages, one stage will be in the MBR, the rest in the partitions.
And for all intensive purposes, why would you look at other boot loaders if all your operating systems are Linux using grub?
Multi-booting boot loaders do not support one operating system, Linux operating systems all use the same kernel, which can all be loaded with Lilo or grub. The only boot loader that will load Mac OS kernel is Darwin. Have you given that any thought?

There's a good description of the Linux boot process on Kim Oldfield's site here.

I understand from the discussion (thanks :)) that the only generic software that can boot a Linux kernel is GRUB, GRUB2 or LILO. According to Wikipedia's Comparison of boot loaders, there are OS-specific tools that do the same such as AirBoot, Redboot and FreeLoader. There was also ASPLoader. They may be forks of GRUB or LILO, I haven't tried to find out yet.

All other MBR-resident solutions must use one of those residing in a partition boot sector. This includes Acronis "OS Selector", TeraByte "BootIt New Generation" (BING) and TeraByte "BootIt Bare Metal" (BIBM).

If that is correct, Wikipedia's Comparison of boot loaders's table column "Can boot ... Linux" is misleading to have "Yes" for at least some of the solutions listed instead of "Calls GRUB or LILO".

BING was great and presumably its replacement, BIBM, is great too but, for a computer on which Windows is rarely booted, the cost of running any MBR-resident software and then GRUB, GRUB2 or LILO (clutter, complexity and boot delay) does not justify the the benefit of the MBR-resident software (easy to use, pretty).

So....
What is your point?
Might I remind you, the benefits to BING have nothting to do with booting operating systems, which means, nothing to do with MBR. The benefits are in the imaging and partition tools.....
You are dwelling on a null subject, any boot loader can run the MBR.....
If all you want is to boot your various partitions, than use grub, lilo, acronis, etc. etc. etc.

I just want to tell my opinion regarding bootloaders, I used grub-legacy, grub2, grub4dos, lilo, syslinux. All are used with simple disk setup.

Grub-legacy is self-service. It can fix itself as long as it can find stage1 and stage2. It can fix itself on grub interactive prompt. It doesn't need modules to work properly. It has limitation in that it cannot boot isos. It can be installed easily anywhere.

Grub2 requires its directory /boot/grub/ consisting modules intact. Without this directory, grub2 cannot do its job. It cannot fix itself although it can give user interactive prompt. When grub rescue happens user is required to insmod (inserting) certain modules manually by first setting prefix to /boot/grub/ location. It can boot isos via loopback and has many modules to support its job. It need to be forced to install on root partition.

Grub4dos requires a lot reading for user to use bootlace.com properly. Some features are not yet implemented (like installing on root partition), the user need to input some longer parameters instead. It works just like grub and grub2 combined. It has interactive prompt just like other grubs and it can boot isos via map feature. It requires grub.exe to work properly.

I cannot talk much about syslinux (extlinux) except it can boot isos via memdisk feature. I have no experience installing it on root partition.

Lilo is just work although it has no interactive prompt and cannot boot isos. I once had difficulty booting zenwalk. Using lilo from within slackware I can successfully boot it.

Sorry for my english.

Nope, been there, done that.

Partially wrong, grub needs the stages only on one partition, it is able to start a kernel and OS (that itself has no bootloader installed) from any other partition on any disk in the system after loading the stages from that one partition. Here also: Been there, done that. No problem at all. It is even possible to install grub (stages inclusive) on one partition, independent from any OS. It is still able to boot any other OS from any partition on any disk in the system.

How can anyone spend days troubleshooting Grub1? It's the easiest thing in the world to get running again! Much simpler than Grub2.

On my box, (20+ OSes - the number varies), every one has Grub 1 in the root partition. Every one except one is booted by chainloading. If I install a new OS I can boot it immediately by chainloading (if, that is, the installer allows me to put the boot loader in the root partition) even before I have updated the menu.lst entry in the OS that the MBR points to. If the installer refuses, or stuffs up putting the bootloader in the root partition, it's dead easy to boot manually from a grub prompt. Four commands: root, kernel, initrd, boot. Auto-completion fills in the details of the kernel/initrd version.

When I had Grub2 in the MBR, it gave me a list of around a hundred entries, including 20 or so each of memtest entries, single-user entries, old kernels, non-framebuffer entries, and who knows what.
Certainly, you can make it more sensible by running update-grub twice, once with os-prober enabled, then make your own custom file, then run update-grub again with os-prober disabled, so that you only get your own custom grub.cfg. You can play around with /etc/default/grub and the files in /etc/grub.d. And you can spend days doing that.

How much simpler it is to write a menu. lst: you only really need entries for default OS, timeout, and then title, root, kernel, initrd for each kernel you want included. Then in the OS that the MBR points to, you have title, root, chainloader +1, for each partition. You can write this one in about three minutes before you even install your OSes with title (eg): "Whatever in sda12", and so on. This way, I don't need to update-grub or edit the menu.lst for a new installation or a kernel upgrade.

Grub2 was supposed to be the answer to the multi-booter's dreams.
It solved a lot of problems that I didn't have by introducing a lot of problems I didn't need.

Fortunately you can always get rid of it, and you can just copy across Grub1 from an OS that has it, without even bothering about dependencies and package managers.

Well, this is an opinion thread, so I shan't apologise for the rant.

Which is one of the things that make it brilliant.

Thanks impert :)

AIUI, the arrangement of installing legacy GRUB (or GRUB2 or LILO) to each root partition has several advantages, especially when combined with a boot loader entirely resident in the MBR(s):

1. There is no common /boot file system to accumulate redundant files.
2. Shorter menu(s) when each root file system has several kernels.
3. root partition boot sectors can be more safely restored unlike the MBR+ which includes the partition table so restoring it after partitions have changed ... :eek:
4. If using a boot loader entirely resident in the MBR(s), can use one which is easier to use and re-install (especially on a system with no functioning OS) than legacy GRUB, GRUB2 or LILO.
5. Each OS can install the boot loader best suited to it in its root partition.
6. When an OS is scrapped, all its boot loader components are automatically removed when its partition is deleted or re-loaded.

... and one disadvantage: takes a little longer to boot.

Multi-booting with lilo in the MBR, and other bootloaders in their distros' root partitions, is dead easy. Just a matter of putting in lilo.conf, for example:
Then running lilo (which some people claim is inconvenient).

@ catkin:

The main advantage of having a bootloader in each root partition, as I see it, is that you don't have to update your "main" menu.lst or grub.cfg (ie the one the MBR points to) every time there is a kernel change on another system, or you decide to replace Ubuntu with Zenwalk or whatever. Also, you don't need to keep track of the strange kernel options that some OSes seem to like (Fedora . . )

Except with OSes that Grub can't boot, you're not limited to chainloading, of course. It's perfectly feasible to manually write a menu.lst with all the kernels & versions & initrds & options explicitly set out, but you'll have to update it when things change. You can use Grub2 in the MBR to do this for you - I did for a while - but you'll have to boot into the OS that the MBR points to and run update-grub. Much simpler to chainload.

As for the slower booting, the major loss of time is human reaction time in choosing the OS. If you want choice, you have to live with that.

Redundant kernels accumulate in the different /boot directories if, like me, you're a bad housekeeper. I don't lose sleep over this. On most systems a new kernel is automagically placed as first entry on the menu.lst/grub.conf/grub.cfg, so the next boot will use it.

This has never been a problem for me, as I have a brace of spare empty partitions.

I'm not sure what you mean in item 4. I find Grub1 easy to install (except for the broken version in Debian Squeeze). If there's something easier, I don't know of it.

Thanks impert :)

All good points and understood.

I used to use BootIt New Generation (BING) and am hoping that BootIt Bare Metal (BIBM) is equally sweet and can be installed in the MBR only. Version 1.06 doesn't like my hardware so I can't report about it yet. Will update this thread when I do (1.07-beta is OK on the hardware; waiting for TeraByte support to advise).

Installing legacy GRUB is mildly tedious because it's not available for Slackware64 unless the 32 bit libraries are installed so it has to be done from Knoppix -- and I don't install legacy GRUB often enough to be fluent with it whereas BING was so simple it did not require fluency. This despite being very comfortable at the command prompt and with text configuration files.

Simple as that: The bootloader part of the MBR is in the first 446 bytes, the partition table is in the following 64 bytes. So if you just back up the first 446 bytes instead of the whole 512 bytes that issue is simply not existent. Besides that, I don't see the point in backing up the MBR, you would need to start a live system to restore it, but if you have a live system running you can simply re-install the bootloader.

Legacy GRUB's stage 1.5 is installed in first 30 kilobytes of hard disk immediately following the MBR (Wikipedia). Thus, to restore legacy GRUB the first 30.5 kB could be restored. Thinking about it some more, it could be done without affecting the partition table by:
The count=1 is probably not required but does no harm and guards against an accidentally too large MBR.backup file overwriting the partition table.

Would it not be possible to restore MBR.backup and GRUB_1.5.backup in this way from an OS booted from CD/DVD, USB device etc. such as Knoppix?

AFAIK if the "live system running" were a 64 bit system without the ability to run 32-bit programs, it could not be used to re-install legacy GRUB.

The only loader that seems to have dropped out of favor ... in any case, I don't miss it ... is LILO, simply because if you forgot to issue the right command at the right time you could wind up with an unbootable system. Systems like Grub know how to read and use text files, and they also provide a limited number of on-the-spot commands.

I have even seen Windows shops that used these loaders (taking special care to replace Windows' endless attempts to put back its "NTLDR"), because this technique afforded them more flexibility in dealing with the occasional boot problem. Their standard boot configuration was to use (I think, Grub) to load NT.