Grub Installation Mini How-To
Yves Bellefeuille
document explains how to install Lilo.
Many users have asked for similar information on installing Grub, so I
wrote it.
This is a first version. Comments are welcome.
This is posted in comp.os.linux.setup and comp.os.linux.misc; follow-ups
are set comp.os.linux.setup.
- - -
Grub Installation Mini How-To
Yves Bellefeuille <y...@storm.ca>
version 0.1
11 December 2005
This explains how to install and configure the Grub boot loader. It was
tested with Fedora 4 and with Debian 3.0.
Grub notation
=============
Grub has its own notation to refer to hard disks and partitions. These
are numbered from 0, not from 1. Also, there are parentheses around the
parameters.
Examples:
Grub notation traditional notation meaning
(fd0) /dev/fd0 first floppy drive
(hd0) /dev/hda first hard disk
(hd1) /dev/hdb second hard disk
(hd0,0) /dev/hda1 first partition on
first hisk disk
(hd1,3) /dev/hdb4 fourth partition on
second hard disk
Installing Grub
===============
To install the grub loader on /dev/hda, become root using the command
"su -", then do the following command:
grub-install /dev/hda
After doing this, a new directory called /boot/grub will be created.
This directory will contain several files, including the following:
/boot/grub/stage1
/boot/grub/stage2
/boot/grub/e2fs_stage1_5
There will also be other files ending with "_stage1_5"; these are to
boot other operaring systems.
Do "grub". You will see the prompt "grub >".
If the configuration file will be in the first partition of the first
hard disk (/dev/hda1), then do:
root (hd0,0)
If the configuration file will be on /dev/hda2, then do "root (hd0,1)",
and so on.
Grub will answer: "Filesystem type is ext2fs, partition type 0x83", for
example.
Then, do "setup (hd0)" to install Grub on first disk drive, Grub provides
some information, ending with this if all went well:
Running "install /boot/grub/stage1 [... more output ...] succeeded
Done
Hint: the line before the last one will say either
"/boot/grub/grub.conf" or "/boot/grub/menu.lst". This indicates the
name of the configuration file for your version of Grub. For more
information, see "Configuration", below.
To exit the installation, do "quit".
Configuration
=============
After installing Grub, you must make a configuration file. The
configuration file is located at /boot/grub/grub.conf.
With older versions of Grub, the configuration file was located at
/boot/grub/menu.lst. It's suggested that you make a link from
the old name to the new name:
ln -s /boot/grub/grub.conf /boot/grub/menu.lst
In some distributions, this link already exists.
Here's an example of a configuration file. Linux is on /dev/hda1 and
will be loaded by default. A DOS or Windows partition is on /dev/hda2
and can be loaded instead by choosing it from the Grub menu at boot-up.
default=0
# By default, boot the first entry that follows.
# The entries are numbered starting with 0, not with 1.
timeout=10
# Timeout before booting the default, in seconds.
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
# Some distributions provide a nice background image. This is "a
# gzipped xpm which is 640x480 with a 14 color palette", according to the
# "info" for Grub. This is entirely optional.
# Example to boot Linux.
title Fedora4
# Name of Linux partition.
root (hd0,0)
# Location of partition.
kernel /boot/vmlinuz-2.6.14 ro root=/dev/hda1
# Location of kernel, then "ro", then partition containing kernel
# Using traditional name.
# Add kernel parameters, if any, for example "vga=ext".
initrd /boot/initrd-2.6.14.img
# Location of initrd (initialized RAM disk), if any.
# Example to boot DOS or Windows.
title MS-DOS
# Name of DOS or Windows partition.
rootnoverify (hd0,1)
# Specify location of partition.
chainloader +1
# Add chainloader command.
Changing the configuration
==========================
With LILO, it was necessary to run /sbin/lilo when the configuration
file was changed. This is not necessary with Grub: simply change the
configuration file, without rerunning or reinstalling Grub.
It is only necessary to rerun the "grub" command if the location of the
configuration file is changed.
--
Yves Bellefeuille <y...@storm.ca>
Google users: To reply to posts, click "show options" next to the
poster's name, and then click "Reply" in the line that says:
"Reply | Reply to Author | Forward | Print | Individual Message"
imotgm
This is misleading, as it implies a direct relationshp between (hd0) and
/dev/hda, as well as (hd1) and/dev/hdb. (hd0) will be the first hard disk,
and (hd1) will be the second hard disk, as grub sees them, no matter what
cable connection it is on. Below are examples or different device.map
files for various set-ups. These are as written by grub.
[First set-up]
(fd0) /dev/fd0
(hd0) /dev/hda
(hd1) /dev/hdc
(hd2) /dev/hde
(hd3) /dev/hdg
(hd4) /dev/sda
All IDE devices are "master" BIOS boots /dev/hda. (Normal)
[Second set-up]
(fd0) /dev/fd0
(hd0) /dev/hdc
(hd1) /dev/hda
(hd2) /dev/sda
All IDE devices are "master" BIOS boots /dev/hdc (Specified)
[Third set-up]
(fd0) /dev/fd0
(hd0) /dev/hdc
(hd1) /dev/hde
(hd2) /dev/hdg
(hd3) /dev/sda
All IDE devices are "master" BIOS boots /dev/hdc (Normal) There is no
/dev/hda.
> (hd0,0) /dev/hda1 first partition on first hard disk
> (hd1,3) /dev/hdb4 fourth partition on second hard disk
Again (hd0,0) is in fact the first partition on the first hard disk, as
grub sees it, but there is no absolute link to /dev/hda. If there is only
one hard drive on the machine, and it is connected at /dev/hdg, grub will
still see it as (hd0). If you specify in BIOS to boot from the second hard
drive, grub will then see that as (hd0) as shown in the second example
above. If you boot from /dev/sda then grub will see that as (hd0).
This must be clearly spelled out on any grub how-to, to avoid confusion.
Just today, I read an erroneous how-to that proclaimed that /dev/hda would
be (hd0) and a second drive mounted at /dev/hdc would be (hd2). Grub
counts from "0", counts only floppy, and hard drives, and does not skip
numbers. There can be no (hd2) without an (hd1). If there are only two
hard drives, and they are mounted as /dev/hda, and /dev/hdg, the first
will always be (hd0), and the second will be (hd1). (hd0) will be the
device who's MBR BIOS uses to boot.
In most cases, and especially with older BIOS, /dev/hda will be (hd0), if
in fact there is a hard drive attached to that position. (hd1) will be
wherever it may be found.
In Red Hat, and Fedora. SUSE, Mandrake/Mandriva, and others use
/boot/grub/menu.lst
>
> With older versions of Grub, the configuration file was located at
> /boot/grub/menu.lst. It's suggested that you make a link from the old
> name to the new name:
It's what each disto uses, by choice, not new versus old.
Windows needs an active partition to boot from. Which partition is set
active can be changed by various means, so a good insurance to make sure
that windows boots is to add the "makeactive" option (without the quotes).
It may be unnecessary, most of the time, but it will do no harm being
there.
> Changing the configuration
> ==========================
>
> With LILO, it was necessary to run /sbin/lilo when the configuration
> file was changed. This is not necessary with Grub: simply change the
> configuration file, without rerunning or reinstalling Grub.
>
> It is only necessary to rerun the "grub" command if the location of the
> configuration file is changed.
--
imotgm
"Lost? Lost? I've never been lost... Been a tad confused for a
month or two, but never lost."
Yves Bellefeuille
> [First set-up]
>
> (fd0) /dev/fd0
> (hd0) /dev/hda
> (hd1) /dev/hdc
> (hd2) /dev/hde
> (hd3) /dev/hdg
> (hd4) /dev/sda
I see your point: Grub's notation skips over drives than don't exist using
the traditional notation, so to speak.
> [Second set-up]
>
> (fd0) /dev/fd0
> (hd0) /dev/hdc
> (hd1) /dev/hda
> (hd2) /dev/sda
>
> All IDE devices are "master" BIOS boots /dev/hdc (Specified)
I'll have to try it to be convinced. ;-)
> In Red Hat, and Fedora. SUSE, Mandrake/Mandriva, and others use
> /boot/grub/menu.lst
There seems to be a direct link between the version of Grub that's used
and the name of the configuration file. The change seems to have happened
in version 0.94.
Thanks for the comments!
Grant
>
>This must be clearly spelled out on any grub how-to, to avoid confusion.
>Just today, I read an erroneous how-to that proclaimed that /dev/hda would
>be (hd0) and a second drive mounted at /dev/hdc would be (hd2). Grub
>counts from "0", counts only floppy, and hard drives, and does not skip
>numbers. There can be no (hd2) without an (hd1). If there are only two
>hard drives, and they are mounted as /dev/hda, and /dev/hdg, the first
>will always be (hd0), and the second will be (hd1). (hd0) will be the
>device who's MBR BIOS uses to boot.
IOW: Grub enumerates drives,partitions at boot time, just like WinNT :)
Grant.
Enrique Perez-Terron
Others have commented on this. Grub uses the Bios to access drives.
A modern bios that let you specify in setup what disk to boot from,
will list that disk first. Other disks are listed and given numbers
in the order that the bios finds them. The bios on some systems is
really a combination of several bioses, chained together. Eg. scsi
controllers have such bios components. This makes the order somewhat
unpredicatble, eg. if a scsi controllers is moved to another pci slot.
> Installing Grub
> ===============
>
> To install the grub loader on /dev/hda, become root using the command
> "su -", then do the following command:
>
> grub-install /dev/hda
>
> After doing this, a new directory called /boot/grub will be created.
> This directory will contain several files, including the following:
>
> /boot/grub/stage1
> /boot/grub/stage2
> /boot/grub/e2fs_stage1_5
>
> There will also be other files ending with "_stage1_5"; these are to
> boot other operaring systems.
^^^^^^^^^
Ooops, no. to boot from partitions using other file systems, like reiserfs.
^^^^
> Do "grub". You will see the prompt "grub >".
But if the user does grub-install, this is not needed. Grub install
does just this. (Run "grub", issue commands "root" and "setup".)
> If the configuration file will be in the first partition of the first
> hard disk (/dev/hda1), then do:
>
> root (hd0,0)
>
> If the configuration file will be on /dev/hda2, then do "root (hd0,1)",
> and so on.
Hint: if in doubt, try "find /boot/grub/stage2" and "find /grub/stage2".
Grub will look inside all partitions and list those having the specified
path.
> Grub will answer: "Filesystem type is ext2fs, partition type 0x83", for
> example.
>
> Then, do "setup (hd0)" to install Grub on first disk drive, Grub provides
> some information, ending with this if all went well:
>
> Running "install /boot/grub/stage1 [... more output ...] succeeded
> Done
>
> Hint: the line before the last one will say either
> "/boot/grub/grub.conf" or "/boot/grub/menu.lst". This indicates the
> name of the configuration file for your version of Grub. For more
> information, see "Configuration", below.
>
> To exit the installation, do "quit".
There are cases when grub-install (and also the grub, root, setup
procedure) will fail. Particularly, if the Bios setup has another disk
than hda specified as boot disk, grub cannot know this. If the bios
finds scsi disks in a different order than the linux kernel, grub may
get it all wrong, because when running under the kernel, grub cannot
see what the world will look like when it tries to boot and talk with
the Bios.
There are two ways of overcoming this. One is, if you know how the Bios
enumerates the disks, you can write a "devices.map" file.
Another is, boot off a grub floppy or grub iso, and run grub commands
from the command line prompt. At that point, grub will
be seeing the disks through the Bios, and no mistake is possible.
If the user needs to explore the disks using this interface in order
to determine what is (hd0), what is (hd1), and where is /grub/grub.conf,
the user can use the command "find".
I suggest you make it clear for the readers that "root" in grub is
not necessarily "/", but whatever partition contains the grub files
(when running the "setup" command), or whatever partition contains
the kernel and initrd files (when booting, as in the config file.)
On the other hand, the "kernel" grub command takes arguments after the
kernel file name, that will be passed to the kernel as a kernel command
line. The contents of these arguments are not examined by grub, only
by the kernel, its modules, or possibly the "init" program. All those
argument speak the language of the kernel, and e.g. the root= argument
will be like root=/dev/hda7 to specify the partition containing "/".
It is only necessary to rerun the grub-install command if the stage1_5 and
stage2 files have been modified or rewritten.
-Enrique
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Yves Bellefeuille
> But if the user does grub-install, this is not needed. Grub install
> does just this. (Run "grub", issue commands "root" and "setup".)
It seems to me that installing Grub this way only works if the Grub files
are already in /boot/grub, and they're not there by default, at least
under Debian. Running grub-install is necessary to put the files in
/boot/grub. (No doubt one could also specify the directory with the files,
but that's more complicated.)
Thanks for the comments!
imotgm
> On Tue, 13 Dec 2005, Enrique Perez-Terron wrote:
>
>> But if the user does grub-install, this is not needed. Grub install
>> does just this. (Run "grub", issue commands "root" and "setup".)
>
> It seems to me that installing Grub this way only works if the Grub files
> are already in /boot/grub, and they're not there by default, at least
> under Debian. Running grub-install is necessary to put the files in
> /boot/grub. (No doubt one could also specify the directory with the files,
> but that's more complicated.)
Those files are different from the ones that end up in /boot/grub. There's
a build process that takes place first.
Grub-install is a shell script. You really should open it in a text
editor, and read it, to see how it works. From the grub-install shell
script;
"grub-install copies GRUB images into the DIR/boot directory specfied by
--root-directory, and uses the grub shell to install grub into the boot
sector."
Which translates, as Enrique said, first it installs the stage1, 1_5, and
2, as well as creating the device.map, menu.lst, and other files, into
/boot/grub, then runs the grub shell to do the "root" and "setup"
processes to install stage1 to the MBR, and the other stages after the
partition table, within the boot sector. It's an all in one process. When
it's done, you're ready to boot from grub. If it finds that the "stage"
files already exist in /boot/grub, it just does the grub shell commands.
Yves Bellefeuille
> Which translates, as Enrique said, first it installs the stage1, 1_5, and
> 2, as well as creating the device.map, menu.lst, and other files, into
> /boot/grub, then runs the grub shell to do the "root" and "setup"
> processes to install stage1 to the MBR, and the other stages after the
> partition table, within the boot sector. It's an all in one process. When
> it's done, you're ready to boot from grub. If it finds that the "stage"
> files already exist in /boot/grub, it just does the grub shell commands.
Obviously you're very knowledgeable about Grub. I'd like to suggest it
would make more sense for you to write a Mini How-To.
imotgm
> On Wed, 14 Dec 2005, imotgm wrote:
>
>> Which translates, as Enrique said, first it installs the stage1, 1_5, and
>> 2, as well as creating the device.map, menu.lst, and other files, into
>> /boot/grub, then runs the grub shell to do the "root" and "setup"
>> processes to install stage1 to the MBR, and the other stages after the
>> partition table, within the boot sector. It's an all in one process. When
>> it's done, you're ready to boot from grub. If it finds that the "stage"
>> files already exist in /boot/grub, it just does the grub shell commands.
>
> Obviously you're very knowledgeable about Grub. I'd like to suggest it
> would make more sense for you to write a Mini How-To.
I've thought about it, but really didn't think it necessary. What I'd like
to see happen is to have more people read the documentation that's already
available. I usually try to help someone having a problem with grub,
because I think it's the best bootloader out there. Then I point them to
the info files, as portrayed by konqueror. If you haven't done so, open
konqueror, as a web browser, and in the location box, enter;
info:grub <Enter>
Konqueror uses info2html to translates the grub manual into an easy to
navigate form. All the answers a user could need are there. Try it. Then
if you want to make a short synopsis, for the gnubies, do so.
I find that most problems with grub can be solved by choosing
"Installation" from the main menu, then "Installing GRUB natively" from
that page. Usually, by the time someone has a boot problem, grub-install
has already been run during the distro's installation process, so
/boot/grub already exists, and has the proper files installed. The only
problem is in a bad stanza in menu.lst/grub.conf, or they pointed
grub-install at the wrong place, the first time.
The other thing I stress, is moving the Windows drive to hdb, or hdc,
intact, with no changes, when someone wants to install Linux on a separate
drive. Putting the Linux only drive on hda, and installing grub into that
MBR, eliminates the possibility of Windows clobbering grub when a Windows
repair is made. Windows will only write to the MBR of the drive it is
installed on.
Drive mapping, in the form of a Windows stanza as such,
title Windows
root (hd1,0)
map (hd1) (hd0)
map (hd0) (hd1)
makeactive
chainloader +1
will boot Windows without any problems, and if the Linux drive is removed,
the Windows drive will boot natively, as it has not been modified, or even
touched, during the Linux installation.
I have drive caddies in four bays of a full tower, so I can experiment
with different combinations rather easily. 95+% of the time I have two
120GB drives in the top two bays. I have all my drives jumpered as master,
and a DVD-R/W and CD-R/W as slave devices. I have Grub installed in each
drives MBR, to boot the distros on that drive, should it be the only drive
present, with a master grub in the "hda" drive to boot from all the
drives. I've had as many as a dozen Linux OSs, bootable from my master
grub, at one time, on these two, and additional drives. I change OSs like
other people change shirts, just to see whats out there.
The grub on my master disk in hda, was installed by SuSE 7.2, when that
was the latest and greatest, on a 15GB or 20GB drive, that held two
Distros. I added drives, and finally copied that drive to this 120GB
drive, using dd and cp -a. On first boot from the new drive, the copied
grub just worked, without any tinkering. With all the Distros I've
installed, that original grub still runs the show even though the OS it
belonged to is long gone, along with SuSE 8.0, 8.1, 8.2, Mandrake 9.1,
SuSE 9.1, which at some time were my main working distros, and a slew of
other trial OSs. I've also run setup on Win98, winnt.exe and winnt32.exe
on Win2K numerous times, and they simply do not know or care about grub on
hda. They do not touch it.
Ten other drives, some with OSs, some with just data partitions, share the
bottom two drives. I have two drives that dual boot Win98 and Win2K, and a
Win2K only drive. I can, if I wish, remove the second Linux drive, insert
all three Windows drives, and boot any one of them, from hdc, hde, or hdg,
as I have three Windows stanzas in my master menu.lst, with proper drive
mapping for each position. Removing the Linux drive on hda, will cause the
first Windows drive in the stack to boot normally, as it's never been
touched by anything other than Windows. In point of fact, no Windows drive
has been in the machine since last March, as I just don't do Windows.
Anyway, that's just background, so you understand that I've tried just
about every combination one can, because my layout made it easy, to try to
trip grub up, and haven't yet. If something doesn't work, grub did not
screw up, I did.
By the way, I learn as much from helping others fix their grub installs as
I do from my own experiments. While looking at info: grub, just now, as
I'm writing this for you, I see there's been some changes that I was
unaware of. From the info:grub/installation page, it seems that there is
now less building involved, and the stage files can now be copied directly
to /boot/grub, as you thought. Here's the paragraph.
"GRUB comes with boot images, which are normally put in the directory
`/usr/lib/grub/i386-pc'. If you do not use grub-install, then you need to
copy the files `stage1', `stage2', and `*stage1_5' to the directory
grub-set-default::) if you intend to use `default saved' ( default) in
your configuration file. Hereafter, the directory where GRUB images are
initially placed (normally `/usr/lib/grub/i386-pc') will be called the
"image directory", and the directory where the boot loader needs to find
them (usually `/boot/grub') will be called the "boot directory"."
So, because of you, I got an updated refresher course, and learned
something new. I stand corrected.
Thank you.
Enrique Perez-Terron
> On Tue, 13 Dec 2005, Enrique Perez-Terron wrote:
>
>> But if the user does grub-install, this is not needed. Grub install
>> does just this. (Run "grub", issue commands "root" and "setup".)
>
> It seems to me that installing Grub this way only works if the Grub files
> are already in /boot/grub, and they're not there by default, at least
> under Debian. Running grub-install is necessary to put the files in
> /boot/grub. (No doubt one could also specify the directory with the files,
> but that's more complicated.)
You are probably right! I missed that, thanks for telling me.
-Enrique
Enrique Perez-Terron
> On Wed, 14 Dec 2005, imotgm wrote:
>
>> Which translates, as Enrique said, first it installs the stage1, 1_5, and
>> 2, as well as creating the device.map, menu.lst, and other files, into
>> /boot/grub, then runs the grub shell to do the "root" and "setup"
>> processes to install stage1 to the MBR, and the other stages after the
>> partition table, within the boot sector. It's an all in one process. When
>> it's done, you're ready to boot from grub. If it finds that the "stage"
>> files already exist in /boot/grub, it just does the grub shell commands.
>
> Obviously you're very knowledgeable about Grub. I'd like to suggest it
> would make more sense for you to write a Mini How-To.
I would end up with a 100-pages thing nobody has the time to read.
I like your attempt, it's concise.
-Enrique
Enrique Perez-Terron
> info:grub <Enter>
Obviously, in an ordinary console window, the command is
info grub <Enter>
[...]
> Drive mapping, in the form of a Windows stanza as such,
>
> title Windows
> root (hd1,0)
Isn't this "rootnoverify" ? My remarkably unreliable memory says I had
a problem with that once... Oh, that was perhaps a an NTFS partiton!
Anyone knows?
> map (hd1) (hd0)
> map (hd0) (hd1)
> makeactive
> chainloader +1
[...]
> By the way, I learn as much from helping others fix their grub installs as
> I do from my own experiments. While looking at info: grub, just now, as
> I'm writing this for you, I see there's been some changes that I was
> unaware of.
That is exaclty how it works for me too.
Besides, I have never been very happy with the documentation. When I read it,
for some reason I don't fully understand, I always have a feeling of not
knowing what is meant. It's like with the "map" command, once I had a case
where I was never able to boot a windows partition, and I never figured
out what was wrong. Since the partition wasn't on the first disk, I
thought I should try the map command. Of course I tried the example in
the manual, but it did not work, and then I read the info page more
carefully, but the text really does not answer any question you may have.
At what point does it take effect? Why do I need both
map (hd1) (hd0)
and
map (hd0) (hd1)
?
Why does not the latter simply reverse the effect of the first one?
etc. In the end I read the source code, and found that map does not
take effect until you give the "boot" command. At that point it installs
some code that hook's into the "int 13H" instruction, which is used
to call the Bios disk operations. This code uses a small table to
translate the disk number in the "int 13h" request, and then it calls
the original "int 13h" handler. The map command specifies entries in
this table. Finally piece in mind.
I used to feel unsure about when the info page is talking about the
grub Linux command, and when is it talking about the Grub native
command. Looking in "Installing Grub natively", almost nothing is
documented. The options to the setup command that appear in
grub-install are not documented. And in grub-install, what is
--root-dir? Oh, yes it's the root dir! But what the heck is that???
When do you use that? I had to read the grub-install
code to find out. And, my fool, I have already forgotten much of
what I found out. But now I can google for much of it, because
I wrote about it here (in earlier posts).
When everything just works, it is OK to have a rather short recipe.
If necessary d/l and install the RPM (sw package). Then run grub-intall.
Presto.
But when you need to research what is going wrong, or you want to figure
out how to achieve something unusual, then you need to know, e.g., where
are the stage1_5 files installed during setup? What is the mission of
stage1_5? Where does Grub actually load stage2 from during boot? How
does it know? etc.
-Enrique
imotgm
> On Thu, 15 Dec 2005 02:14:45 +0100, imotgm <imotg...@invalid-yahoo.com> wrote:
>
>> info:grub <Enter>
>
> Obviously, in an ordinary console window, the command is
>
> info grub <Enter>
But if you do that in konqueror, you get a google search. ;-)
>
> [...]
>
>> Drive mapping, in the form of a Windows stanza as such,
>>
>> title Windows
>> root (hd1,0)
>
> Isn't this "rootnoverify" ? My remarkably unreliable memory says I had
> a problem with that once... Oh, that was perhaps a an NTFS partiton!
> Anyone knows?
"rootnoverify" is for when you point grub at a part of a disk that is
beyond that which grub can read. Grub can obviously read the first sector
of the first partition of a disk. I've never had a problem with this with
Win98 on a Fat32 partition, or Win2K with NTFS. I've never, believe it or
not, even seen a WinXP installation running, yet alone had one installed,
but I've told numerous people to do this with XP, and all have reported
that it works just fine, just like Win2K. On the other hand,
"rootnoverify" won't hurt anything, so if it makes you feel better, have
at it.
>
>> map (hd1) (hd0)
>> map (hd0) (hd1)
>> makeactive
>> chainloader +1
>
> [...]
>
>> By the way, I learn as much from helping others fix their grub installs as
>> I do from my own experiments. While looking at info: grub, just now, as
>> I'm writing this for you, I see there's been some changes that I was
>> unaware of.
>
> That is exaclty how it works for me too.
>
>
> Besides, I have never been very happy with the documentation. When I read it,
> for some reason I don't fully understand, I always have a feeling of not
> knowing what is meant. It's like with the "map" command, once I had a case
> where I was never able to boot a windows partition, and I never figured
> out what was wrong. Since the partition wasn't on the first disk, I
> thought I should try the map command. Of course I tried the example in
> the manual, but it did not work, and then I read the info page more
> carefully, but the text really does not answer any question you may have.
>
> At what point does it take effect? Why do I need both
>
> map (hd1) (hd0)
>
> and
>
> map (hd0) (hd1)
>
> ?
Basically, as near as I can tell, the thinking is that if you map (hd1) to
(hd0) you now have the possibility of a poorly written BIOS to see two
(hd0)s if you don't also remap (hd0) to (hd1). Lilo has used the boot
mapping in pairs also, but now has the single commands boot as=0x80
and master-boot. There may be something going on in the background to
complete the pair, but on the surface, it's single, and quicker.
>
> Why does not the latter simply reverse the effect of the first one?
> etc. In the end I read the source code, and found that map does not
> take effect until you give the "boot" command. At that point it installs
> some code that hook's into the "int 13H" instruction, which is used
> to call the Bios disk operations. This code uses a small table to
> translate the disk number in the "int 13h" request, and then it calls
> the original "int 13h" handler. The map command specifies entries in
> this table. Finally piece in mind.
>
> I used to feel unsure about when the info page is talking about the
> grub Linux command, and when is it talking about the Grub native
> command. Looking in "Installing Grub natively", almost nothing is
> documented. The options to the setup command that appear in
> grub-install are not documented. And in grub-install, what is
> --root-dir? Oh, yes it's the root dir! But what the heck is that???
> When do you use that? I had to read the grub-install
> code to find out. And, my fool, I have already forgotten much of
> what I found out. But now I can google for much of it, because
> I wrote about it here (in earlier posts).
See what you started. Now it can come back and bite you.
>
> When everything just works, it is OK to have a rather short recipe.
> If necessary d/l and install the RPM (sw package). Then run grub-intall.
> Presto.
>
> But when you need to research what is going wrong, or you want to figure
> out how to achieve something unusual, then you need to know, e.g., where
> are the stage1_5 files installed during setup? What is the mission of
> stage1_5? Where does Grub actually load stage2 from during boot? How
> does it know? etc.
For the most part, it doesn't actually install stage1_5 unless it's
commanded to embed it. The most common thing is to install stage1 in the
MBR, and read stage1_5, and 2, from the files in /boot/grub. Stage1 can't
read file systems, which is why it must be told where to find stage1_5.
Each of the stage1_5 files can read 1 file system, so stage1 asks, "Anyone
know where we're at?" and marries the one that says "Yes". Once it can
read the fs, it searches for, and finds, stage2, and is complete. Only
then does it put up the menu, and wait to be told, by selection, which
kernel to load, or load the default when the timer runs out.
Timothy Murphy
> The other thing I stress, is moving the Windows drive to hdb, or hdc,
> intact, with no changes, when someone wants to install Linux on a separate
> drive. Putting the Linux only drive on hda, and installing grub into that
> MBR, eliminates the possibility of Windows clobbering grub when a Windows
> repair is made. Windows will only write to the MBR of the drive it is
> installed on.
I don't think you should "stress" this.
It is not necessary, and is likely to cause trouble.
(It's not as easy as you seem to think to move a Windows partition.)
Personally, I would save the grub MBR with dd
before doing anything with Windows that might over-write it.
Then you can just put restore it if necessary.
In my opinion, grub is a very good bootloader,
but the grub documentation is dire.
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
Mark South
(vicious snippage)
> When everything just works, it is OK to have a rather short recipe.
> If necessary d/l and install the RPM (sw package). Then run grub-intall.
> Presto.
That's the only way GRUB works for most people. If it doesn't work the
first time they go on to LILO.
> But when you need to research what is going wrong, or you want to figure
> out how to achieve something unusual, then you need to know, e.g., where
> are the stage1_5 files installed during setup? What is the mission of
> stage1_5? Where does Grub actually load stage2 from during boot? How
> does it know? etc.
All this is made harder for people who, like me, learn quickly from
examples. In the GNU world, examples are generally illegal in
documentation. (Just read the BNNF, Loser!") I learn far more from BSD
man pages than from GNU info, because they generally include some example
uses.
Sadly, the BSDs use their own bootloader, so there appears to be no BSD
man page for GRUB.
--
mark south: world citizen, net denizen
echo znexfb...@lnubb.pb.hx|tr a-z n-za-m
"Take it? I can't even parse it!" - Kibo, in ARK
Yves Bellefeuille
> Which translates, as Enrique said, first it installs the stage1, 1_5, and
> 2, as well as creating the device.map, menu.lst, and other files, into
> /boot/grub, then runs the grub shell to do the "root" and "setup"
> processes to install stage1 to the MBR, and the other stages after the
> partition table, within the boot sector. It's an all in one process. When
> it's done, you're ready to boot from grub.
This is true as far as it goes: run "grub-install" install Grub, and you
can boot from Grub.
But it does no configuration whatsoever. You have to manually enter the
commands "root", "kernel", "initrd" and "boot" whenever you boot.
Obviously, for most people, this isn't good enough, and they should
continue on and configure Grub using the "grub" command.
Enrique Perez-Terron
> On Wed, 14 Dec 2005, imotgm wrote:
>
>> Which translates, as Enrique said, first it installs the stage1, 1_5, and
>> 2, as well as creating the device.map, menu.lst, and other files, into
>> /boot/grub, then runs the grub shell to do the "root" and "setup"
>> processes to install stage1 to the MBR, and the other stages after the
>> partition table, within the boot sector. It's an all in one process. When
>> it's done, you're ready to boot from grub.
>
> This is true as far as it goes: run "grub-install" install Grub, and you
> can boot from Grub.
>
> But it does no configuration whatsoever. You have to manually enter the
> commands "root", "kernel", "initrd" and "boot" whenever you boot.
>
> Obviously, for most people, this isn't good enough, and they should
> continue on and configure Grub using the "grub" command.
I don't quite follow you. running grub-install generally does what is needed
to install Grub to the point that on boot, grub starts and find the config file.
What you need to do additionally is to edit the config file. This however,
you do with vi, emacs, or kate, etc. Not with Grub.
In most cases you don't need to do much with the config file, because the
kernel installation program automatically adds a new stanza to the config
file when a new kernel is installed. For the initial install, it also
often sets up a correct config file. But if, e.g., you have different
distributions in different partitions, or you have Windows partition,
then you probably will have to do some hand editing of the config file.
That, what you do with Grub, grub-install does right, with one exception.
And that exception does not get any better by using Grub afterwards.
The exception is, that Grub needs to know how to access the disk in question
through the Bios. If you know that /dev/hde will be accessible through the
Bios as the first disk (hd0), put that piece of information in devices.map.
Otherwise install-grub, and also grub (as run under the Linux kernel) might
believe that /dev/hde is e.g., (hd4). If you need to tell grub how to
access hde, and you don't know how to do that through the Bios, you may have
to boot into grub, and run the "native" or "standalone" grub and explore
your disks from there, to find out. Once you have found out, you can
a) use the "setup" command in the native grub and be done with the setup,
or boot Linux, edit devices.map, and run grub-install.
In those cases where a devices.map file is necessary, there is a good
chance that the config file needs amendments too.
-Enrique
Yves Bellefeuille
> I would end up with a 100-pages thing nobody has the time to read.
> I like your attempt, it's concise.
It's nice to be concise, but it's also nice to be correct. :-)
I'll post a corrected version.