GRUB Legacy (GRUB Version 1): Configuration and Boot Entries

Learn how GRUB Legacy works with BIOS, menu.lst, device.map, disk and partition names, Linux boot entries, initrd, and chainloading.

GRUB Legacy is the older, version 1 generation of the GRUB boot loader. It is found mainly on older BIOS-based Linux systems. This lesson explains how its configuration identifies disks, locates boot files, starts Linux, and transfers control to another operating system.

Before editing a legacy boot configuration, review basic Linux paths such as the Linux filesystem structure and make sure you have a recovery method available.

What a Boot Loader Does

A boot loader is a startup program that loads an operating system kernel or hands control to another boot loader. On a traditional BIOS system, the sequence is broadly:

The computer powers on.
BIOS firmware performs hardware self-tests and initializes enough hardware to boot.
BIOS consults its configured boot order and selects a disk.
Boot code on that disk starts GRUB Legacy.
GRUB displays a menu, loads a selected kernel and possibly an initrd, or chainloads another boot sector.
The kernel starts and eventually mounts the Linux root filesystem at /.

A boot menu is useful when several kernels, recovery modes, or operating systems are installed. Boot-time kernel parameters are also important: they can identify the filesystem that should become /, enable diagnostic output, select a recovery mode, or pass hardware-specific options.

GRUB Legacy Overview

GRUB means Grand Unified Boot Loader. GRUB Legacy is the common name for GRUB version 1. It played a major role as a Linux boot loader before being largely replaced by GRUB 2.

GRUB Legacy is designed for the BIOS boot model. It does not have official EFI/UEFI support, so it is not the appropriate boot loader for a design that requires native EFI booting. GRUB 2 is a later generation with a different configuration model and should not be treated as a drop-in syntax replacement for GRUB Legacy.

Configuration Files and Structure

The most common GRUB Legacy configuration file is /boot/grub/menu.lst. Some distributions use /boot/grub/grub.conf instead. The related mapping file is usually /boot/grub/device.map.

/boot/grub/menu.lst
/boot/grub/grub.conf
/boot/grub/device.map

Do not assume the filename from memory. First identify which file the installed GRUB setup actually uses. The menu file generally contains global directives followed by one or more boot entries. Global directives affect menu behavior overall; directives below a title line normally describe one entry.

Make a backup before editing. Keep at least one known-working entry intact, and avoid changing disk references, kernel filenames, and initrd filenames all at once.

GRUB Legacy Disk and Partition Names

GRUB Legacy names disks with identifiers such as hd0 and hd1. A partition is written with a comma between the disk and partition number, for example (hd0,0).

hd0 means the first disk visible to the firmware.
hd1 means the second firmware-visible disk.
(hd0,0) means partition 0 on disk 0.
(hd0,1) means partition 1 on disk 0.

GRUB partition numbering is zero-based, while common Linux device names use one-based partition numbers. Thus, the typical first-disk, first-partition correspondence is (hd0,0) to /dev/sda1. This is a typical mapping, not a guarantee.

Concept	GRUB Legacy notation	Typical Linux notation	Numbering rule	Notes
First disk	`hd0`	`/dev/sda`	Disk number starts at 0 in GRUB	Usually, but not always, the same physical disk
Second disk	`hd1`	`/dev/sdb`	Disk number starts at 0 in GRUB	Depends on firmware-visible order
First partition on first disk	`(hd0,0)`	`/dev/sda1`	Partition number starts at 0 in GRUB and 1 in Linux	The comma is required
Second partition on first disk	`(hd0,1)`	`/dev/sda2`	Partition number starts at 0 in GRUB	Common correspondence

GRUB does not use separate naming schemes for PATA, SATA, SCSI, and USB storage. Its hdN names reflect the order presented by firmware. Linux may discover devices in a different order, especially after disks are added, removed, or moved between controllers. Verify the actual order instead of assuming that hd0 always means the Linux device that Linux calls /dev/sda.

The device.map File

/boot/grub/device.map records associations between GRUB disk identifiers and operating-system disk devices. A simple example might look like this:

(hd0) /dev/sda
(hd1) /dev/sdb

The file helps GRUB and its utilities translate between names such as hd0 and device files such as /dev/sda. If disks are added, removed, reordered, or presented differently by firmware, the mapping can become stale or incorrect. That can make a menu entry point to the wrong physical disk.

Understanding GRUB root

The GRUB root setting identifies the filesystem from which GRUB reads its own files, including kernel and initrd images. It is not automatically the same thing as the Linux runtime root filesystem mounted at /.

Item	What it identifies	When it is used	Example location	Effect of separate /boot
GRUB root	Filesystem containing GRUB-readable boot files	When GRUB resolves paths in an entry	`(hd0,0)`	Points to the separate `/boot` partition
Linux root filesystem	Filesystem mounted as `/` after the kernel starts	When Linux processes the kernel's `root=` argument	`/dev/sda2`	Still points to the Linux `/` filesystem, not necessarily `/boot`

Paths in kernel, initrd, and commonly splashimage directives are interpreted relative to the GRUB root setting. If /boot is part of the Linux root filesystem, the GRUB filesystem may contain a directory named /boot. If /boot is a separate filesystem, that filesystem itself is commonly mounted at GRUB's selected root, so the path usually omits the mounted /boot prefix.

Global Menu Directives

Directive	Scope	Purpose	Key behavior	Common mistake
`default`	Global	Selects the automatically booted entry	Uses a zero-based menu-entry index	Counting the first entry as 1 instead of 0
`timeout`	Global	Sets the selection wait period	Value is normally measured in seconds	Expecting an unlimited selection period
`splashimage`	Global	Selects a boot-menu background image	Path is resolved using GRUB disk and path syntax	Using a path on the wrong GRUB root filesystem

For example, default 0 selects the first entry, while default 1 selects the second. The timeout gives a user an opportunity to choose another entry before the default starts.

Linux Boot Entry Directives

A Linux entry normally begins with title, followed by the location and files needed to start the kernel.

title: Text displayed in the boot menu.
root: Selects the GRUB filesystem containing boot files.
kernel: Names the Linux kernel image and supplies kernel command-line arguments.
root=: An argument passed to the Linux kernel identifying the filesystem intended to become /.
initrd: Names the initial RAM disk or initial RAM filesystem image.

The two uses of “root” must be kept separate. The GRUB root directive tells the boot loader where to find files. The root= kernel argument tells Linux which filesystem to mount as its runtime root.

Single-Partition Linux Example

In this example, the first partition contains the Linux installation and its boot files:

default 0
timeout 5
splashimage=(hd0,0)/grub/splash.xpm.gz

title Linux
root (hd0,0)
kernel /vmlinuz root=/dev/sda1 ro
initrd /initrd.img

Here, (hd0,0) is the filesystem GRUB reads. The kernel path and initrd path are relative to that filesystem. The kernel is instructed to mount /dev/sda1 as Linux /.

Separate /boot Filesystem Example

Suppose /dev/sda1 is mounted as /boot, while /dev/sda2 contains the Linux root filesystem. GRUB should use the boot partition:

title Linux with separate boot filesystem
root (hd0,0)
kernel /vmlinuz root=/dev/sda2 ro
initrd /initrd.img

The paths are /vmlinuz and /initrd.img, not /boot/vmlinuz and /boot/initrd.img, because GRUB's root is already the separate boot filesystem. The kernel's root=/dev/sda2 still identifies the eventual Linux root filesystem.

Multiple Entries

Multiple entries can select different installed kernels or provide recovery choices:

default 0
timeout 8

title Linux current kernel
root (hd0,0)
kernel /vmlinuz-current root=/dev/sda2 ro
initrd /initrd-current.img

title Linux recovery kernel
root (hd0,0)
kernel /vmlinuz-recovery root=/dev/sda2 single
initrd /initrd-recovery.img

Every referenced kernel and initrd must exist under the selected GRUB root. The entry's disk, partition, filenames, and kernel root= value must describe the same intended installation.

What the initrd Does

An initrd, also called an initial RAM disk or initial RAM filesystem image, is a temporary filesystem loaded into memory during early kernel startup. It contains early drivers, utilities, and configuration needed before the real root filesystem is available.

For example, the initrd may provide support for a storage controller, RAID or volume setup, an encrypted device, or a filesystem module. The kernel uses it to discover and prepare the real root filesystem, then switches to that filesystem for normal operation.

A missing initrd may prevent the kernel from finding or mounting the root filesystem. A mismatched initrd may lack the required drivers or configuration, or may be intended for a different kernel. Select matching kernel and initrd filenames when maintaining entries.

Booting Non-Linux Systems by Chainloading

GRUB can directly load a Linux kernel because it understands the relevant kernel-loading directives. For systems whose kernel GRUB Legacy does not load directly, GRUB can instead chainload another boot sector or boot loader.

rootnoverify: Selects a partition without asking GRUB to mount or inspect it as a GRUB-readable filesystem.
chainloader: Transfers execution to boot code loaded from the selected location.

title Other operating system
rootnoverify (hd0,1)
chainloader +1

chainloader +1 commonly means that GRUB should load the first sector of the selected partition and hand control to it. DOS- and Windows-based installations often use this pattern. Unlike a Linux entry, this entry does not name a Linux kernel or initrd; it starts another loader's boot process.

Boot method	Relevant directives	What GRUB loads	Typical use case	Limitations
Direct Linux boot	`root`, `kernel`, `initrd`	Linux kernel and optional initrd	Linux installations and recovery kernels	Requires correct kernel, initrd, and root filesystem references
Chainloading	`rootnoverify`, `chainloader`	Another partition boot sector or boot loader	DOS- and Windows-based installations	Depends on valid secondary boot code and correct partition selection

Safe Maintenance Workflow

Identify whether the machine boots through BIOS or EFI/UEFI. GRUB Legacy is intended for BIOS.
Identify the active configuration file: menu.lst or grub.conf.
Back up the configuration and note the currently working entry.
Inspect device.map and verify firmware disk order.
Determine whether /boot is part of / or a separate filesystem.
Verify the GRUB root partition and the exact kernel and initrd filenames.
Check that the kernel's root= argument identifies the intended Linux root filesystem.
Keep the known-working entry while testing a new or modified entry.

Some failures happen before Linux is running. A GRUB error about a missing file, wrong partition, or invalid chainloader target is a boot-loader problem, not necessarily a Linux kernel problem. Conversely, if the kernel starts but cannot mount /, investigate the kernel root= argument and initrd contents rather than only the GRUB root directive.

Troubleshooting Common Failures

The Wrong Operating System or Disk Boots

Likely causes include a changed firmware boot order, a mismatch between GRUB's hdN order and Linux's device names, or a stale device.map. Compare the disk references in the menu file with /boot/grub/device.map, verify firmware disk order, and confirm which partition actually contains the GRUB files and kernels.

GRUB Cannot Find the Kernel or initrd

Check whether the GRUB root points to the partition containing the boot files. Then check whether the path should include /boot. A separate boot filesystem commonly requires /vmlinuz; a filesystem containing the Linux / directory may instead require /boot/vmlinuz. Finally, verify that the files were not renamed or removed.

The Kernel Starts but Cannot Mount Linux Root

Separate the GRUB root setting from the kernel's root= argument. Confirm that root= identifies the intended Linux root partition and that the initrd matches the selected kernel and includes required storage and filesystem support.

The Wrong Entry Starts Automatically

Count menu entries from zero. The first entry is index 0, the second is index 1, and so on. If entries were reordered, update default. Check timeout as well, because a short timeout may leave little opportunity to make a manual choice.

A DOS or Windows Entry Does Not Start

Verify the partition passed to rootnoverify, confirm that chainloader +1 targets the intended partition boot sector, and check that the secondary boot code is present and undamaged. This is a chainloading problem, not a Linux kernel-loading problem.

GRUB Legacy Fails on an EFI-Based Design

Confirm the firmware mode used by the machine and installed operating system. GRUB Legacy is BIOS-focused and lacks official EFI support. An EFI-capable boot solution is required when the system is designed to boot through EFI/UEFI.

Key Points to Remember

GRUB Legacy is GRUB version 1 and is mainly for BIOS systems.
The usual configuration file is /boot/grub/menu.lst; some systems use /boot/grub/grub.conf.
(hd0,0) uses zero-based GRUB numbering and commonly corresponds to /dev/sda1, but disk order must be verified.
/boot/grub/device.map records GRUB-to-operating-system disk mappings.
GRUB root locates boot files; kernel root= identifies the Linux filesystem mounted as /.
Kernel and initrd paths are interpreted relative to the GRUB root setting.
initrd supplies early drivers and tools needed before the real root filesystem is available.
rootnoverify and chainloader transfer control to another operating system's boot code.
Back up the configuration, preserve a working entry, and verify filenames and disk order after hardware changes.