GRUB Legacy (Version 1): Configuration, Disk Naming, and Boot Entries

Learn how GRUB Legacy works, read menu.lst and grub.conf, translate disk names, build Linux and chainloaded entries, and troubleshoot boot problems.

GRUB version 1, commonly called GRUB Legacy, is a BIOS-era boot loader used to start Linux and other operating systems. This lesson explains its startup role, configuration files, disk notation, Linux boot entries, chainloading, and safe maintenance practices.

What a boot loader does

When a computer starts, firmware performs hardware initialization and basic self-tests. On a BIOS-based system, the firmware then locates boot code on a selected disk and transfers control to it. A boot loader is software that runs at this stage of startup.

1. The firmware initializes hardware and performs startup checks.
2. The firmware loads the boot loader from the configured boot disk.
3. GRUB displays a menu or selects a default entry.
4. GRUB loads an operating-system kernel, or transfers control to another boot loader.
5. For Linux, the kernel uses an optional initial RAM disk and then mounts the real Linux root filesystem.

A boot menu is useful when a computer has several operating systems or several kernel versions. For example, one entry can start a normal Linux kernel, another can start a recovery kernel, and a third can chainload another operating system.

GRUB Legacy and GRUB 2

GRUB means Grand Unified Boot Loader. GRUB Legacy is GRUB version 1, the older implementation. GRUB 2 is a later generation, not merely a different spelling of the same configuration system.

GRUB Legacy was widely used historically, but most installations have been replaced by GRUB 2. GRUB Legacy is designed for BIOS boot environments and is not officially designed for EFI/UEFI booting.

Where the configuration lives

The common GRUB Legacy menu configuration file is:

/boot/grub/menu.lst

Some distributions use this alternative filename:

/boot/grub/grub.conf

Distribution layouts vary. In some installations, menu.lst and grub.conf may be alternate names, links, or files where only one is the active menu configuration. Confirm which file the installed boot loader reads before editing it.

GRUB Legacy also commonly records disk-name mappings in:

/boot/grub/device.map

Make a backup of the active configuration before changing it, and preserve at least one known-good boot entry. A syntax error or incorrect disk reference can prevent normal startup.

Configuration structure

A GRUB Legacy configuration has two broad parts:

• Global directives affect the menu as a whole, such as the default entry, countdown, and background image.
• Per-image directives define individual choices in the menu. A boot entry normally begins with title and continues with the commands required to start that operating system.

Entries are processed in the order in which their title lines appear. The numeric value of default refers to that order, starting at zero.

Global example

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

Here, default 0 selects the first menu entry, and timeout 5 waits five seconds. If the entries are reordered, the meaning of default 0 changes even though the directive itself has not changed.

GRUB Legacy disk and partition notation

GRUB Legacy names disks with identifiers such as hd0 and hd1. Disk and partition numbering starts at zero:

• hd0 is the first disk visible in firmware order.
• hd1 is the second disk visible in firmware order.
• (hd0,0) is partition zero on disk zero, conventionally the first partition.
• (hd0,1) is partition one on disk zero, conventionally the second partition.

GRUB identifiers do not mean “PATA disk,” “SATA disk,” “SCSI disk,” or “USB disk.” They reflect the order in which firmware presents drives to the boot loader. Adding, removing, rearranging, or booting with removable storage attached can change that order.

The device.map file

/boot/grub/device.map records mappings between GRUB drive names and Linux device paths. An illustrative file might contain:

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

This mapping helps GRUB and administrators relate its notation to Linux device names. It should still be checked against the current firmware order and attached hardware. A stale or incorrect mapping can cause an entry to address the wrong disk.

GRUB root versus Linux root

The word root has two different meanings in a Linux boot entry:

• GRUB's root directive selects the partition containing files GRUB must read, especially its configuration, kernel, and initrd.
• Linux's root= kernel parameter tells the Linux kernel which filesystem should become Linux /, the main root filesystem.

If there is no separate /boot filesystem, GRUB's root is commonly the Linux / partition. Because the boot directory is inside that partition, paths include /boot. If /boot is a separate filesystem, GRUB's root is commonly that /boot partition, so paths begin at its filesystem root and do not repeat the mount-point name /boot.

Linux boot entries

Read a Linux entry from its title line downward:

• title supplies the menu label.
• root selects the GRUB partition containing the kernel and initrd.
• kernel names the kernel image and supplies parameters such as Linux root= and read-only mode.
• initrd loads the initial RAM disk associated with that kernel.

No separate /boot partition

In this example, the first partition contains both Linux / and its /boot directory:

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

The GRUB paths include /boot because root (hd0,0) points to the filesystem whose directory is mounted as Linux /boot.

Separate /boot partition

Here, (hd0,0) is the separate boot partition, while /dev/sda2 will become Linux /:

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

The kernel and initrd paths do not contain /boot, because GRUB is already reading from the filesystem mounted as /boot. The kernel's root=/dev/sda2 is independent: it identifies the main Linux root filesystem.

What the initrd does

initrd means initial RAM disk. It is an image loaded into memory before the main Linux root filesystem is available. The kernel starts an early userspace environment from it.

An initrd can supply storage and filesystem drivers, discovery utilities, and configuration needed to locate and mount the real root filesystem. It is especially important when support for the storage controller, volume system, encryption, or filesystem is not built directly into the kernel.

The initrd must normally match the kernel and installed system. A missing or incorrect initrd can allow the kernel to start but leave Linux unable to find or mount its root filesystem.

Booting non-Linux systems with chainloading

GRUB Legacy can directly load Linux kernels, but it commonly starts other operating systems by chainloading. Chainloading means handing execution to another boot sector or boot loader instead of loading that operating system's kernel itself.

rootnoverify selects a target partition without asking GRUB to read or validate its filesystem. chainloader +1 then transfers control to the first sector of that selected partition:

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

This pattern is common for Windows and DOS-era systems. The three parts work together: select the partition with rootnoverify, identify its partition boot sector with +1, and pass execution there with chainloader. There is no Linux kernel or initrd line in this entry.

Choosing the default entry

Suppose a configuration contains these entries in order:

title Linux normal
...

title Linux recovery
...

title Other operating system
...

With default 0, GRUB automatically selects Linux normal. With default 1, it selects Linux recovery. With default 2, it selects Other operating system. Reordering the title blocks changes which entry each number identifies, so update default when necessary.

Safely reading and maintaining entries

1. Identify the boot generation and firmware mode before editing. Confirm that the system is actually using GRUB Legacy on BIOS.
2. Locate the active menu.lst or grub.conf file.
3. Back up the configuration and preserve a known-good entry.
4. Determine whether /boot is a separate filesystem.
5. Verify the GRUB disk and partition mapping, including device.map.
6. Check that the GRUB root partition contains the referenced kernel and initrd files.
7. Check that the Linux kernel's root= parameter names the actual Linux / filesystem.
8. Change one related setting at a time and test the entry before removing the known-good version.

Troubleshooting common failures

Kernel or initrd file cannot be found

• The root directive may select the wrong GRUB partition.
• The path may incorrectly include or omit /boot.
• The installed filename may differ from the filename in the entry.

Determine whether /boot is separate, inspect the selected partition's actual files, and interpret paths relative to GRUB's root partition.

The wrong disk or operating system starts

• The assumed relationship between hd0 and a Linux device such as /dev/sda may be wrong.
• Firmware order may have changed after storage devices were added, removed, or rearranged.
• device.map may not match the current layout.

Inspect the mapping, validate the target partition using zero-based GRUB notation, and do not assume that hd0 always means a particular Linux device.

The wrong entry starts automatically

Count menu entries from zero and compare that position with default. Also confirm that timeout provides enough time to select another entry manually.

Linux starts but cannot mount its root filesystem

• The kernel's root= parameter may identify the wrong Linux partition.
• The initrd may be missing, incorrect, or unable to provide required storage support.
• GRUB's root may have been confused with Linux's root=.

Compare the kernel parameter with the actual Linux / filesystem, confirm that the intended initrd is loaded, and treat the two root settings separately.

A chainloaded operating system does not start

• rootnoverify may select the wrong partition.
• The target partition boot sector may be absent or damaged.
• The target operating system's own boot loader may be broken.

Verify the partition in GRUB notation and confirm that the entry uses a chainloader handoff rather than Linux kernel directives. A successful handoff does not guarantee that the target operating system's boot loader is healthy.

The instructions do not match the installed system

The system may use GRUB 2 rather than GRUB Legacy, or it may boot through EFI/UEFI. Identify the installed GRUB generation and firmware mode before editing anything. GRUB 2 configuration syntax, generated files, tools, and disk-handling practices differ from GRUB Legacy.

GRUB Legacy versus GRUB 2

Key points

• GRUB Legacy is GRUB version 1 and is primarily a BIOS boot loader.
• menu.lst and grub.conf are common legacy configuration filenames.
• Global directives control the menu; each title block defines one boot choice.
• GRUB disk and partition numbers start at zero, while Linux names such as /dev/sda1 use one-based partition numbering.
• GRUB's root selects where GRUB reads boot files; the kernel's root= selects Linux /.
• Kernel and initrd paths are relative to GRUB's selected root partition.
• rootnoverify and chainloader commonly hand control to another operating system.
• Always verify firmware drive order, device.map, partition layout, and the active GRUB generation before editing.

Return to the GRUB Version 1 lesson