Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Next: , Previous: History, Up: Introduction


1.3 GRUB features

The primary requirement for GRUB is that it be compliant with the Multiboot Specification, which is described in Multiboot Specification.

The other goals, listed in approximate order of importance, are:

  • Basic functions must be straightforward for end-users.
  • Rich functionality to support kernel experts and designers.
  • Backward compatibility for booting FreeBSD, NetBSD, OpenBSD, and Linux. Proprietary kernels (such as DOS, Windows NT, and OS/2) are supported via a chain-loading function.

Except for specific compatibility modes (chain-loading and the Linux piggyback format), all kernels will be started in much the same state as in the Multiboot Specification. Only kernels loaded at 1 megabyte or above are presently supported. Any attempt to load below that boundary will simply result in immediate failure and an error message reporting the problem.

In addition to the requirements above, GRUB has the following features (note that the Multiboot Specification doesn't require all the features that GRUB supports):

Recognize multiple executable formats
Support many of the a.out variants plus ELF. Symbol tables are also loaded.
Support non-Multiboot kernels
Support many of the various free 32-bit kernels that lack Multiboot compliance (primarily FreeBSD, NetBSD, OpenBSD, and Linux). Chain-loading of other boot loaders is also supported.
Load multiples modules
Fully support the Multiboot feature of loading multiple modules.
Load a configuration file
Support a human-readable text configuration file with preset boot commands. You can also load another configuration file dynamically and embed a preset configuration file in a GRUB image file. The list of commands (see Commands) are a superset of those supported on the command-line. An example configuration file is provided in Configuration.
Provide a menu interface
A menu interface listing preset boot commands, with a programmable timeout, is available. There is no fixed limit on the number of boot entries, and the current implementation has space for several hundred.
Have a flexible command-line interface
A fairly flexible command-line interface, accessible from the menu, is available to edit any preset commands, or write a new boot command set from scratch. If no configuration file is present, GRUB drops to the command-line.

The list of commands (see Commands) are a subset of those supported for configuration files. Editing commands closely resembles the Bash command-line (see Bash), with <TAB>-completion of commands, devices, partitions, and files in a directory depending on context.

Support multiple filesystem types
Support multiple filesystem types transparently, plus a useful explicit blocklist notation. The currently supported filesystem types are BSD FFS, DOS FAT16 and FAT32, Minix fs, Linux ext2fs, ReiserFS, JFS, XFS, and VSTa fs. See Filesystem, for more information.
Support automatic decompression
Can decompress files which were compressed by gzip. This function is both automatic and transparent to the user (i.e. all functions operate upon the uncompressed contents of the specified files). This greatly reduces a file size and loading time, a particularly great benefit for floppies.1

It is conceivable that some kernel modules should be loaded in a compressed state, so a different module-loading command can be specified to avoid uncompressing the modules.

Access data on any installed device
Support reading data from any or all floppies or hard disk(s) recognized by the BIOS, independent of the setting of the root device.
Be independent of drive geometry translations
Unlike many other boot loaders, GRUB makes the particular drive translation irrelevant. A drive installed and running with one translation may be converted to another translation without any adverse effects or changes in GRUB's configuration.
Detect all installed ram
GRUB can generally find all the installed ram on a PC-compatible machine. It uses an advanced BIOS query technique for finding all memory regions. As described on the Multiboot Specification (see Multiboot Specification), not all kernels make use of this information, but GRUB provides it for those who do.
Support Logical Block Address mode
In traditional disk calls (called CHS mode), there is a geometry translation problem, that is, the BIOS cannot access over 1024 cylinders, so the accessible space is limited to at least 508 MB and to at most 8GB. GRUB can't universally solve this problem, as there is no standard interface used in all machines. However, several newer machines have the new interface, Logical Block Address (LBA) mode. GRUB automatically detects if LBA mode is available and uses it if available. In LBA mode, GRUB can access the entire disk.
Support network booting
GRUB is basically a disk-based boot loader but also has network support. You can load OS images from a network by using the TFTP protocol.
Support remote terminals
To support computers with no console, GRUB provides remote terminal support, so that you can control GRUB from a remote host. Only serial terminal support is implemented at the moment.

Footnotes

[1] There are a few pathological cases where loading a very badly organized ELF kernel might take longer, but in practice this never happen.


 
 
  Published under the terms of the GNU General Public License Design by Interspire