The tools used to boot Linux are changing. Specifically, the Grand Unified Bootloader is now officially in maintenance mode only, and GRUB's developers have abandoned the original GRUB in favor of an entirely rewritten package, known as GRUB 2. Discover GRUB 2's new capabilities and how to use it.

[vent]
I do not like Grub2. I had few problems with grub, but Grub2 has been very unstable for me. 3 different Grub2 problems bit me on 1 laptop

1. By default, it would detect drives by UUID, and bomb when it couldn't find the drive (even though the UUID was correct). This is a known issue. I had to turn the UUID feature off.

2. There was a line with a "search...." statement in it. This also caused a problem, so I had to figure out how to get rid of it.

3. There was some line at the beginning that had to do with recordfail. I had an unclean shutdown, that I guess caused some file it was looking for to not exist - again a fail to boot. I had to edit some file in /usr/lib/ to get this to go away.

The bottom line is Grub 2 had configuration files spread out all over the place that you must edit if you have trouble. You can't just edit grub.cfg, as it will be regenerated with kernel updates. You have to find the right files to edit that are used as source when grub.cfg get recreated.

I don't think it is stable enough yet to be abandoning the grub line, but that seems to be just they way it goes in the Linux world. Maybe I'll have to go back to Lilo!!
[/vent]

Grub2 has been a major PITA! I can't even install newer versions of Ubuntu on most any machine anymore.

Grub2 may have more potential, but let us realize that potential before we use it wide-spread.

I, too, find it outright idiotic to edit ten different files to do what once only required editing one file. I finally, after HOURS of trying, managed to even get Grub2 to update properly enough to get an image to display instead of the ugly default look.

I'm sure the hassles will improve with time, but that should have been a priority prior to release.

People in the Linux community need to try and make things easy for those outside of the community to join and be proficient. That is what made BeOS so great. With BeOS, everything was clean and simple and worked as you thought it should work from reading a couple lines of a description.

It would also be nice if Linux installers would show all available OSes and permit configuring ( graphically ) the boot loader for the next boot. It shouldn't take hours of studying by a well-experienced computer tech to figure out how to change the order of operating systems and add a background.

Of course, on Ubuntu, I figured out that I had to 'sudo apt-get install grub2' which was counter-intuitive, considering grub2 was installed by default ( but apparently not the utilities... ).

On a related note, that makes me wonder why so few ( any? ) Linux distributions allow customizing the installation.

Ubuntu's installer could simply ask where you were to determine most everything they ask at the start of the installation.

And why do I have to select Monterrey, Mexico when I'm in Texas? That makes no sense to me ( yes, I know the actual reason, but it should be hidden from the user ).

@The loon: Ubuntu's installer could simply ask where you were to determine most everything they ask at the start of the installation.

Perhaps, but Ubuntu asks *far* fewer questions than Win 7 during installation. Ubuntu also has the courtesy to ask all of its questions up front and then complete installation unattended, rather than ask a few questions, install a bit, reboot, lather, rinse, repeat. And it leaves you with most common apps pre-installed, rather than almost naked like the competition.

I'm elated when I report various issues with a product, and someone informs me that they have had no problems. Now I can sleep at night!

Seriously, my main complain is _NOT_ that Grub2 is a worse product. I've had trouble with the original Grub (especially when the BIOS mis-reported a drive size), and I have had troubles at times with LILO. This is normal. In my case, I think it had to do with the particular Tablet PC I was using. Some Tablet PC's have a wierd way of initializing there devices at startup.

Anyhoo, the point is that when something invariably goes wrong (which happens with all software - I write software for a living ;} ), the means by which you resolve these issues is quite tortuous in Grub2. By having its configuration spread out in multiple places (at least 3 that I know of), and multiple files in each location, they have created quite a puzzle for the end user. At some point, a good front-end to all of this will be created (there is one I have looked at so far), then this will become less of an issue.

Really, I would see Grub2 _currently_ as more appropriate for Fedora. For Ubuntu, which emphasizes the "Just Works" philosophy, I do not believe it is stable and friendly enough for the end user. Just my $0.03 (my opinion is worth 50% more).

I last tested grub2 long -long- ago, so I can't really comment on how stable it is now.

However, it's not that people are lazy; The main problem with boot managers that if they break -nothing- works. You can't switch to last good known kernel / glibc, you're simply doomed.

As for your configuration, I have a far more complex setups (ranging from 3 x 320GB SATA drives to 16 x 144GB SAS drives), all running software RAID5 or RAID6.
In-order to solve the grub-doesn't-support-RAID[0/5/6] I usually setup two RAID arrays:
/dev/md0: a 200MB RAID1 across all drives.
/dev/md1: the main RAID5/6 array.

If the boot drive dies, I simply switch the BIOS to the next one. (If I somehow failed to write update the drive's MBR, I simply pxeboot/LiveCD and fix the MBR)

But I do suspect that my 40G IDE/PATA drive coupled with a mass storage SATA with an IDE config on the both could be to blame. Yes, I have a Franken-POS; I cannot afford nifty new upgrades often. And yes, my hard drive configuration is weird-- I should have pure IDE or have just SATAs in a RAID setup. But y'know, I'm working with what I've got and what I can genuinely afford. Is that preventing me from upgrading my Mint/Ubuntu installations? Why yes it is. But I'm OK for now.

It is, however, a serious pita if it doesn't work on a particular setup. And wtf is the deal with the new format of the menu entries? For fsck's sake, it almost looks like C++! And why on earth, when I tell it to install to a specific drive, does it insist on trying to probe for drives I do not have and giving seek errors as a result?
If GRUB2 works in its default config, you're covered. If you need to change anything, you'll quickly see how screwed up it is despite some of the cool new features such as being able to boot ISO images. This is like the Pulseaudio situation... except worse, as the boot loader is a bit more important.
Oh, and why when one distro does something stupid like this do the others follow suit? Do these devs have some sort of inferiority complex that they need to get all whiz-bang and update to something that isn't ready? And we wonder why desktop Linux isn't going very far...

GRUB2 has bitten me more than once. When Ubuntu 9.10 first came out, I tried it as the only OS on a system. GRUB2 wouldn't boot after a default install though. This left me uninterested in Ubuntu for a while. Strangely enough, Linux Mint 8 (based on ubuntu 9.10) worked fine on the same system.

Today, I have a triple-boot system with a mix of SATA and PATA drives. I have Mac OS X on the SATA (spare me the wagging fingers please) and Windows XP/Linux Mint 8 on a PATA. Long story short, GRUB2 took over the boot partition of my SATA drive, so I had to disconnect it during the Mint install. Now I must choose which drive to boot from using the BIOS boot selector; not TOO big a deal but I didn't have this issue with regular GRUB or LILO for that matter i.e. Slackware didn't touch the SATA drive during a test install.

Why do all Linux developers have a hard-on for spreading config options into dozens of different files, in multiple sub-directories? What is wrong with a single, simple config file?

First it was xinetd. Then Apache 2.x. Then a bunch of other software followed suit. Now Grub2. ProFTPd took it to the extreme (1 option per file, filename is the option name, contents are the option values).

It's irritating in the extreme, and makes it *VERY* hard to manage from the CLI. I thought software was supposed to get *easier* to manage as time went on.

First it was xinetd. Then Apache 2.x. Then a bunch of other software followed suit. Now Grub2. ProFTPd took it to the extreme (1 option per file, filename is the option name, contents are the option values).

Personally, that way is my favorite way. I have never used ProFTPd, but that is similar to Linux's procfs or sysfs. I think it makes it extremely easy to manage with scripts, ex:

echo 42 > options/some_option

All of the programs I have written work this way. I then wrote a small GUI program that displays the options and lets you edit them, sort of like GConf. I think it is actually very easy to use. It also makes the programming a lot easier (no parsers needed).

It might makes things easy to automate ... but it makes it a royal pain in the arse to deal with manually. And when you're working on multiple servers across multiple network links, it becomes even more of a royal pain in the arse. And when things go wrong ... it's even worse.

Personally, I find multiple config files much easier to deal with. They certainly make scripts that deal with config files easier, but I also like that I can, for example, enable or disable a site in Apache 2 using ln -s and rm and that to change a single site, I do not have to find it in a config file. (Admittedly, I am not a heavy user of Apache but I do similar things with apt.)

Apt also makes good use of it with the apt.conf.d and sources.list.d directories. Notably, apt will look for the files apt.conf and sources.list and check for the directories only if the files do not exist, so if you prefer to have everything in one file, you can.

I have not looked into the grub2 configuration much as the Debian install of it just worked for me. I just looked and (noting that it may be different on other distros) it appears to be made out of a single config file /boot/grub/grub.cfg which is built by running the shell scripts in /etc/grub.d/ in order, which seems like a pretty sane way to handle things, especially as it includes an example file which just dumps its contents into that place in the config file (which is empty by default) for adding your own directives. If you really wanted to, you could just replace that with a single file pretty easily.

Some things, it makes sense to split into separate files. Like Apache virtual hosts. But does everything else under /etc/apache2 have to be in separate files? Really?

Same with all the apt.sources.d directories. Is it really easier to manage all those files, then just firing up a text editor and adding/removing a simple # in the first column?

What's even worse, though, is when using separate config files actually breaks features ... like the mess that is logrotate (at least in Debian/Ubuntu). /etc/logrotate.conf is supposed to be the global config file that all the other files under /etc/logrotate.d/ pick up ... yet it doesn't actually work that way, and you still have to duplicate all your monthly/compress options in all the files. Which means you now have to edit dozens of files to change the rotation policy ... instead of just one.

There's a time and a place to separate config files and use includes. Grub configuration is not one of them.

Why do all Linux developers have a hard-on for spreading config options into dozens of different files, in multiple sub-directories? What is wrong with a single, simple config file?

Simple answer: automation. Most Linux systems these days focus on automation and scripting with GUI frontends. Separate files are much easier to deal with in automation and scripting tasks at least if done well.
That being said, there's a place for this and I don't believe the entire grub configuration is the best place for it. I could see splitting out each section, i.e. default config parameters and then each os entry being separate files, but the way they do it now is just overkill especially when it flies apart as it too often does.

I was elated when I discovered GRUB after having had to use LILO. Just edit menu.lst and that is ALL! I was positively deflated when I discovered what they had done with GRUB2 -- nothing is easy about it, it is more prone to break things, very sad... For my use, went back to GRUB.