GRUB: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
No edit summary
Line 85: Line 85:


Some versions of GRUB 2 like to put multiboot modules in relatively high physical memory addresses, in contrast to GRUB-legacy which loaded them into low memory. Be careful when making your kernel work with GRUB 2 that it is not making any assumptions about where the multiboot modules will appear.
Some versions of GRUB 2 like to put multiboot modules in relatively high physical memory addresses, in contrast to GRUB-legacy which loaded them into low memory. Be careful when making your kernel work with GRUB 2 that it is not making any assumptions about where the multiboot modules will appear.

When your kernel gets control, the machine state is defined as follows: [http://www.gnu.org/software/grub/manual/multiboot/html_node/Machine-state.html Multiboot machine state]. Your code should have minimal dependency on this initial state; for example, define your own GDT instead of relying on the GDT setup by GRUB.


== See Also ==
== See Also ==

Revision as of 00:06, 23 May 2012

This page is a work in progress.
This page may thus be incomplete. Its content may be changed in the near future.

GRUB 2 is the GNU Project's next-generation bootloader. It has a more complete feature set than GRUB 0.97 (commonly referred to as "GRUB Legacy"). Still, all things considered, GRUB Legacy is more mature and most of the available documentation is for GRUB Legacy (hence the brief page).


History

GRUB 2 started its life as the PUPA (note the pun) research project and was rewritten from the ground up. Since then GRUB 2 (actually at time of update 1.97) has grown more stable and even hobby operating systems are starting to make use of the new bootloader instead of GRUB Legacy.

Features

  • Basic scripting support
  • GUI (better bootsplash support, custom colors, custom themes, ...)
  • Memory management
  • Cleaner design
  • Better portability
  • Internationalization
  • Rescue mode

Upgrading from GRUB Legacy

WARNING: These steps have not been tested very well yet. Use at your own risk!

Since GRUB 2 is very different from GRUB Legacy, the directions for getting your kernel up and running are different. GRUB 2 differs from GRUB Legacy in that to implement all but the most basic functionality, the user must load so-called "modules": little bits of code that add components (e.g. a different file system or a VGA font). This section gives you an overview of the process you need to go through when you want to have GRUB 2 load your kernel. It's actually rather simple to create a GRUB2 image (assuming you have GRUB2 either built or installed):

ISO instructions

There have been a lot of tries to make Grub2 work good with ISOs, but mostly failed. The only combination of commands that seems to work is the following.

First create a directory tree called "iso", where you put your kernel (and any other needed files) somewhere. Then in the boot/grub subdirectory create the grub.cfg file which is your configuration.

Now run:

grub-mkrescue -o bootable.iso iso

Be sure that your grub.cfg is syntactically correct. A common mistake is to put the menuentry brace on newline. It must be like:

menuentry "Place your os name here" {
}

Floppy instructions

mkdir tmp
grub-mkimage -p /boot -o tmp/core.img multiboot sh fat # This should work.. I hope :D

Explanation

Let's go through those grub-mkimage options:

-p By default, GRUB 2 looks in /boot/grub for its configuration file. -p changes this.
-o Like so many other GNU tools, grub-mkimage uses -o to set the output file. By default, it's stdout.
multiboot This module is required to load multiboot-compliant kernels.
biosdisk This module is required for GRUB 2 to be able to boot from a LiveCD.
iso9660/fat Allows GRUB 2 to look on the image for different files.
sh This module allows GRUB to parse the configuration file.

GRUB 2, like GRUB Legacy, needs a configuration file to find your kernel. In GRUB Legacy it's called menu.lst, but in GRUB2, it's called grub.cfg. The syntax for the configuration file is also a bit different.

Here's a sample configuration file (NOTE: This file should be placed into the /boot/grub folder of your disk image, and be named grub.cfg):

set timeout=15
set default=0 # Set the default menu entry

menuentry "OS Name" {
   multiboot /boot/kernel-file   # The multiboot command replaces the kernel command
   boot
}

That's basically it. Copy these files to a disk image, pop it in an emulator, and you're done!

Double check that you put the brace on the same line of "menuentry". It can't be on a new line. This is not C.

Multiboot

Some versions of GRUB 2 like to put multiboot modules in relatively high physical memory addresses, in contrast to GRUB-legacy which loaded them into low memory. Be careful when making your kernel work with GRUB 2 that it is not making any assumptions about where the multiboot modules will appear.

When your kernel gets control, the machine state is defined as follows: Multiboot machine state. Your code should have minimal dependency on this initial state; for example, define your own GDT instead of relying on the GDT setup by GRUB.

See Also

External Links