NOTE:

My use of grub started almost accidentally--I did something to my computer's BIOS so that LILO was having trouble installing, and, the same day, also installed RH's beta (Roswell) that used Grub.

As is sometimes the case, at least for me, I found the documentation a bit difficult. However, as is also often true, once I figured out how to do it, it became fairly simple.

Daniel Robbins has an excellent tutorial on the developer works site, but you have to register with them to read it--to find it do a search on google for Robbins Grub and it should pop up. He also covers it in his guide to installing Gentoo Linux, a new and very good (imho) distro. (Go to the install guide and the section on Grub is down towards the bottom).

There is also the mini how to which covers booting with DOS. My other O/S's are 2k and XP on NTFS, and FreeBSD, so I don't cover booting Fat32 partitions.

The documentation that comes with Grub (more properly written GRUB, but I'm a lazy typist) is quite good, but a bit more complicated than may be necessary. So, first get Grub. If you're running RH, Mandrake or others that use RPMS you can just do a search on Google for grub.rpm. At time of writing, they're currently here but that could always change. It doesn't seem to matter which distro's Grub that you use. If you don't want an RPM then the current tarball location is here.

My installation experience has been peculiar. I'd install an RPM and find that I didn't have the files I needed in /boot/grub. Then, I'd run it off a floppy and it would be fine. T he next time, when I installed the RPM I didn't have to go through the business with the floppy--all files were in place. See my note on this below.

I had similar weirdness with the tarballs. once I untarred a file and everything was there--I simply had to copy the files over to /boot. Another time I had to go through the standard make, make install, etc, then boot it once from a floppy. (see below). So, at any rate, install the files. If you use an RPM and don't see a group of files like stage1, stage2,ffs_stage1-5 and other file systems with stages, then something went wrong. Do the procedure below with the floppy and see if it fixes itself. (Shrug). It did with me.

At any rate

First install Grub.

rpm -Uvh grub*

(the asterisk saves you from typing the version number). Hopefully it will install without a problem.

Now, install it to a floppy disk.

grub-install '(fd0)'

Now, at least once, with an RPM, this is what happened. When I'd installed Grub, it created a directory called grub in /boot, but the only file in it was the splash image. (a background image for the Grub boot screen.) However, after typing grub-install '(fd0)' not only did it install to the floppy, but it also created the other necessary files on the hard drive in /boot/grub. The trouble is that if you simply type grub-install it demands a target. I haven't done much experimenting with this aspect, but at any rate, it seems that if you install it, even to a floppy, it will then install the necessary files in /boot/grub. I have a feeling this is what would happen with the tar.gz as well.

If you're really daring, and you have those files, you can now create your grub.conf or menu.lst file, put it in /boot/grub and then install Grub to the hard drive. However, it's probably a good idea to at least test the booting from a floppy.

This is a good time to point out how Grub defines partitions. The first hard drive is (hd0) and the first partition on the hard drive is (hd0,0)

This will typed as shown above, complete with parentheses and commas. So, /dev/hdb would be

(hd1)

Where typical Linux numbering uses hda, b, etc, Grub uses 0, 1, 2 etc. Where Linux would indicate the partition with 1,2, et al Grub uses 0,1 and so on. So, the device is written as hdX where X is the number of the device. Counting starts at 0. The partition is hdX,Y where Y is the number of the partition. Again, counting starts at 0. Lastly, the device name is in parentheses and is followed by a comma, then the number of the partition, beginning with 0.

A few examples:

Linux: /dev/hda1 Grub: (hd0,0)
Linux: /dev/hdb2 Grub: (hd1,1)

As you can see it's simple once you're used to it.

The above becomes important when you first try to use Grub from a floppy. So, boot from the floppy and eventually you'll see the grub prompt.

grub >

First, the root--where Linux is. Assuming you had Lilo already running, you can figure this out by looking at your /etc/lilo.conf. If, for example, it says root=/dev/hda5 then to Grub it's at (hd0,4).

So, at the Grub prompt type

root (hd0,4)

(or whatever your Linux root partition is.)

You can, if you're not sure, simply type

root (hd0,

and hit the tab key--Grub will then list your partitions with the file system of each one. So, let's say that your Linux partition is on partition 5 of the 1st hard drive.

grub > root (hd0,4) Hit enter---you should get a message telling you that it's a Linux file system.

Next, the kernel location. Again, your /etc/lilo.conf should have this information--for example, my lilo.conf shows

image=/boot/vmlinuz-2.4.9

So, you would type

kernel /boot/vmlinuz-2.4.9 root=/dev/hda5

You should see a message that it's found it.

(As I haven't done a reinstall in awhile, I'm not sure if I just left out ro root when I wrote this or if, when at this stage the ro, for read only is simply not yet needed--if you get errors during boot up then change it to ro root=/dev/hda5)

Now, just type

boot

Hopefully, your kernel will boot without problem. Now, you can install it on your hard drive if you wish.

As mentioned, my experience with the later versions of the tar.gz files were a bit different each time. At least once, however, I had what I'd consider a normal experience. I downloaded a later version and simply did tar -zxvf grub*

I then had a grub directory with the version number.

cd grub*

./configure
make
make install

See above for my experience with this--I still didn't have the /boot/grub files such as stage1, stage2, etc. I first had to do the grub-install to a floppy.

So, now we have the files. If you got it from the alpha.gnu site, there should be one called menu.lst. If you did it from an RPM, it probably has to be created and called grub.conf.

menu.lst has sample configurations and instructions. As I used the RPM, I simply made my own, which I saved as /boot/grub/grub.conf

By the way, the tar.gz from the Gnu site doesn't seem to recognize grub.conf--renaming it to menu.lst solved the problem. I didn't experiment the other way, that is to say, I didn't check to see if RH's version would recognize menu.lst.

default=1
timeout=10
splashimage=(hd0,4)/boot/grub/splash.xpm.gz
title RH7.1J
root (hd0,4)
kernel /boot/vmlinuz-2.4.9 ro root=/dev/hda5
title Win2k
rootnoverify (hd0,0)
chainloader +1

So, default=1. This means that it's the 2nd listing. Had Linux been my default booting O/S, it would have been default=0. Here too, Grub begins counting from 0.

timeout=10

10 seconds to decide--unlike LILO, it's in seconds rather than tenths of seconds.

title RH7.1J

splashimage---with RedHat's Roswell beta edition they had a nice little graphic. When I installed the RPM from the CD it put that splash.xpm.gz in my /boot/grub file, so I used it. It can safely be ignored if you wish. If your tarball or RPM puts an image in your /boot/grub directory, then use it if you wish. I'm running RedHat 7.1 in Japanese on this particular machine, so that's what I call it. The title can be what you wish.

root (hd0,4)

The Linux partition is on /dev/hda5.

kernel /boot/vmlinuz-2.4.9 ro root=/dev/hda5

Mess up this line and it won't boot. This is similar to what we typed when booting from the floppy, but note that it's ro root rather than root.

title Win2k is self explanatory.

rootnoverify (hd0,0)

This was gleaned from the various howtos--apparently if it's an O/S that Grub doesn't know, you use rootnoverify rather than root--after is of course, its location on the first partition of the first hard drive, /dev/hda1 in Linux.

chainloader +1

This line is necessary for Grub to go into Win2k's loader. Be careful with the spacing--it's chainloader space + no space 1. I accidentally typed

chainloader + 1 and it wouldn't boot. So, we have our /boot/grub/grub.conf (or menu.lst) file. (By the way, unlike LILO you don't have to do anything after making changes to this file. Just make the changes and Grub will see it upon next boot.)

One other thing to keep in mind is that in some cases, root refers to two different things. For example, say, on the RedHat partition, I'd made a /boot and a / partition. Currently it reads

root (hd0,4)
kernel /boot/vmlinuz-2.4.9 root=/dev/hda5
However, if I had my /boot on /dev/hda5 and my / partition on /dev/hda6 the second line would change to

kernel /boot/vmlinuz-2.4.9 root=/dev/hda6
In other words, the first root (hd0,4) refers to the /boot partition. The "root" in the second line points to the / partition. So, keep that in mind--root can refer to two different partitions in different lines.

So, now to install it on the hard drive in the MBR.

grub >root (hd0,4)
setup (hd0)

the (hd0,4) refers to whatever partition is holding your /boot/grub files. If it were in the 2nd partition then it would be

root (hd0,1)

setup (hd0) installs it in the MBR. It's a good thing to have made a floppy that you tested--this way, if you've mistyped anything, you can still boot. Also, if you later install or reinstall an MS O/S you can boot from the Grub floppy and restore it in your MBR--simply use it to boot back into Linux and repeat the above procedure of root (hd0,4)
setup (hd0) If, when booting, you find that you made an error in your grub.conf file, you can hit e while the incorrectly configured O/S is highlighted and then edit it. For example, on another box, I copied my configuration without thinking. When I tried to boot Linux, I got a kernel panic. The reason was that I'd put the same ro root=/dev/hda5 when in this case, Linux was in /dev/hda2. So, upon reboot, while Linux was highlit, I hit e

This allowed me to edit that parameter and boot into Linux. Once in Linux I was able to correct my /boot/grub/grub.conf file.

GRUB can also boot FreeBSD without problem. During the FreeBSD installation, I chose to not install a bootloader. Then, I simply added the following to GRUB (FreeBSD was on the second primary partition, /dev/hda2 in Linux parlance and, as you hopefully have figured out by now, (hda,1) in Grubtalk.

title FreeBSD 4.4.
rootnoverify (hd0,1)
chainloader +1

As you can see, the syntax is the same as that for WinXP or 2K. This works without problem.

The above is the quick and dirty way to do it, and does work. However, as GRUB does see FreeBSD partitions, it can also be done this way.

If, in Linux, one starts GRUB with the command grub and then does the
root (hd0,
and hits the tab, if there are FreeBSD partitions, you will see,in addition to Linux or MS partitions, something similar to the following

Partition num: 2, [BSD sub-partitions immediately follow ]
BSD Partition num: 'a',Filesystem type is ffs, partition type 0xa5
BSD Partition num: 'b', Filesystem type is unknown, partition type 0xa5
BSD Partition num: 'c', Filesystem type is ffs, partition type 0xa5
and a few more of the same, depending upon how you partitioned your BSD installation.

So, rather than the rootnoverify with chainloader, one could also do

title FreeBSD Prerelease 4.5
root (hd0,1,a)
kernel /boot/loader

This works even if you didn't install a boot loader during FreeBSD installation. While the advantage is minor, it does boot a mite faster, skipping the chainloader sequence.

(A quick note on this--not thoroughly researched but... Although GRUB boots a system upgraded, through cvsup to 5.1 without problem, on a clean install, it had problems. A bit of checking deja indicated that this may be because of changes in the UFS file system. The easiest workaround is to go back to using the rootnoverify chainloader syntax, which still works.)

(Second note, the later versions of grub, 0.96 and up, possibly 0.95 and up, are once again able to boot FreeBSD 5.x with the correct syntax, that is, the hd0,1,a kernel /boot/loader. Also, DragonFlyBSD apparently requires this syntax and doesn't seem to work correctly with the rootnoverify, chainloader +1 syntax).

The quick and dirty method mentioned above also works with Solaris 8. (Keep in mind that Solaris 8 is seen by Linux as a Linux swap partition)

title Solaris 8.0
rootnoverify (hd0,6)
chainloader +1

FreeBSD has added GRUB to the ports collection. The syntax is slightly different, though not different enough to be confusing if you're used to GRUB. Some of this has been covered in the section about booting FreeBSD from Linux

FreeBSD, as you know if you use it, uses a different partition naming system than does Linux. So, if you ran grub, then typed

root (hd1,
and hit the tab key, you will see several BSD partitions listed by letter, then, other O/S partitions by number. So, as the boot partition is usually on the first partition, you probably want

(hdx,a).

Therefore, the FreeBSD section of my FreeBSD's /boot/grub/menu.lst reads

title FreeBSD
root (hd1,1,a)
kernel /boot/loader

The GRUB documentation suggests using the /boot/loader option for FreeBSD. Like the Linux GRUB, it will also boot MS or Solaris using the rootnoverify (hdx,x), chainloader +1 option.

One thing that I noticed--when I first set it up in FreeBSD, I forgot to add after the Linux entry the ro root=/dev/hdxx part. Despite this, it booted without problem. Perhaps the line is only necessary for the O/S that is actually running Grub. So, if I have GRUB running in FreeBSD rather than Linux, the lines
title Slackware 8.0
root (hd1,7)
kernel /boot/vmlinuz-2.4.16

are sufficient to boot the O/S without problem.

Skylinux added, that after setting up Grub in Slackware, if he had the "ro" option for root, (on Reiserfs) it would complain---he removed it so that it read

root (hd0,1)
kernel /vmlinuz-2.4.16 root=/dev/hda2 hdd=ide-scsi vga=791

(His extra lines concern enabling IDE SCSI emulation and a framebuffer setting)

Therefore, it seems as if the ro option can sometimes be a hindrance. Skylinux also gave me permission to put up his comlete list of framebuffer options

# VESA framebuffer console @ 1024x768x64k
vga = 791
# Normal VGA console
# vga = normal
# VESA framebuffer console @ 1024x768x64k
# vga=791
# VESA framebuffer console @ 1024x768x32k
# vga=790
# VESA framebuffer console @ 1024x768x256
# vga=773
# VESA framebuffer console @ 800x600x64k
# vga=788
# VESA framebuffer console @ 800x600x32k
# vga=787
# VESA framebuffer console @ 800x600x256
# vga=771
# VESA framebuffer console @ 640x480x64k
# vga=785
# VESA framebuffer console @ 640x480x32k
# vga=784
# VESA framebuffer console @ 640x480x256
# vga=769

I solved this by using FreeBSD's Grub on the other box. In ports, it's at version 0.91 at time of writing (May 2002). It booted the Linux that was on devfs without problems.

Installing it on FreeBSD this time was a little less smooth. As I've written above, usually, installing Grub to a floppy will then create the necessary files in /boot/grub. However, with FreeBSD, it didn't--furthermore, it wouldn't install it on the floppy, due to some messup with my Bios, being unable to locate something or another. With a sigh, I looked at the man pages--actually, in this case, the info pages, since the pkg-message said go to info rather than man.

The problem was easily solved with a little reading. At present, FreeBSD's Grub install from ports puts the various files in /usr/local/share/grub. (The info page says /usr/share/grub, but, as is often the case with FreeBSD when compared to Linux, FreeBSD will put most things into /usr/local/share, rather than /usr/share.) I simply copied the entire directory into my /boot/grub directory. From there, everything worked. Before doing that, when I tried the

setup (hd0)

command, it would search for those files, find they weren't in /boot/grub and abort. (As this was done very late at night, I had neglected to ensure that the files were there in /boot/grub).

So, when installing on FreeBSD, after installation, copy the /usr/local/share/grub files over to /boot/grub. Then create your menu.lst as described above.

kernel /boot/vmlinuz root=/dev/hdb2 ro
initrd (hd1,3)/boot/initrd.img

The name changes from distribution to distribution--sometimes it is something like initrd.img, sometimes just initrd, sometimes initrd-2.6.14.img, etc. In ArchLinux at least, you don't need the (hd1,3) part, it would simply read

kernel /boot/vmlinuz root=/dev/hdb2 ro
initrd /boot/initrd.img

These days, when I install a new distribution, I let it install Grub in its root partition (not the MBR). Then, I boot into ArchLinux, which currently has grub in the MBR. From there, I mount the new distro's partition. For instance, I create a directory in Arch's / partition called rh. Then, if I installed Fedora on hda2 I might do

mount /dev/hda2 rh
cd rh/boot/grub
less menu.lst 

Then, I can read Fedora's version of the menu.lst file and I see that I have to add

kernel /boot/vmlinuz-2.6.11-1.1369_FC4 ro root=LABEL=/ rhgb quiet
initrd /boot/initrd-2.6.11-1.1369_FC4.img

If I leave out the ro root=LABEL=/rhgb quiet then it won't boot.

ls rh/boot

After that, I can edit my main (in my case, ArchLinux's) /boot/grub/menu.lst accordingly and add the lines

kernel /boot/vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/hda2
initrd /boot/initrd-2.6.11-1.1369_FC4.img

To make it simpler, once the new distro's partition is mounted I could also simply cd into its boot partition and link the long vmlinuz name to vmlinuz and the initrd name to initrd.img. For example

cd rh/boot
ln -s vmlinuz-2.6.11-1.1369_FC4 vmlinuz
ln -s initrd-2.6.11-1.1369_FC4.img initrd.img

NetBSD has a few minor gotchas that took me a morning to solve. With NetBSD at present (1.6.1) /boot is a datafile rather than a directory. Some googling gave me a bit of a clue, but I actually found the answer by looking at the grub-install script.

In NetBSD, create a /grub partition. Then, copy over the files from /usr/pkg/share/grub/i386- to that grub partition. Then, if you do the usual grub, root (hd, and tab and then setup (hd0) it will install--first it will look for a /boot/grub partition, but then it will look for the /grub directory.

Recently, Adam Renner gave me his method of putting Grub in its own partition--this way, you can always have Grub there, and if, like myself, you're constantly experimenting with different distributions, you don't have to worry about reinstalling (or uninstalling) it each time.

Adam did it by creating a 10Meg logical partition, formatted as ext2. On his machine, it was hda11. So, then, step by step, after he booted into whichever Linux installation he was playing with at the time

Then, to setup grub to look at the new grub partition

Then, before doing a new installation, you can simply edit your grub file with your favorite text editor and not worry that removing distro x is going to trash your grub files

This question comes up from time to time--I was interested myself, and eventually found a post by someone named Matt on usenet--Matt, if you ever see this and want full credit, please drop me a line. (It came from a Kondara Linux FAQ, IIRC)

So, here are the steps

Create your image in Gimp or whatever--it should be 640x480 in 14 colors in an xpm format. (To get 14 colors, right click on the image, choose image => mode => indexed and put in 14 for the # of colors textbox. (The default is 256 IIRC). You can convert an already existing file from the command line, but I haven't gotten this to work. You need ImageMagic for it. The command would be, if the image was called image.jpg

Anyway, once the image is saved as an xpm (In the gimp, you choose this format when saving the file), compress it with gzip.

Then, move the image into your /boot/grub file and change your grub menu.lst or grub.con to refer to image.xpm.gz rather than the default image (splashimage.xpm.gz in both RedHat and Gentoo)

(Note, this only works in distros that have the patch allowing a grub splash screen--ArchLinux for example, doesn't have it.)

initrd (hd1,3)/boot/initrd

(In that particular case, I looked at SuSE's own /boot/grub/menu.lst and got the necessary lines there.)

Hopefully, this information will be useful. It seems as if GRUB is gradually replacing LILO so we better get used to it.