4. Booting

GRUB can load Multiboot-compliant kernels in a consistent way, but for some free operating systems you need to use some OS-specific magic.

4.1 How to boot operating systems

GRUB has two distinct boot methods. One of the two is to load an operating system directly, and the other is to chain-load another boot loader which then will load an operating system actually. Generally speaking, the former is more desirable, because you don’t need to install or maintain other boot loaders and GRUB is flexible enough to load an operating system from an arbitrary disk/partition. However, the latter is sometimes required, since GRUB doesn’t support all the existing operating systems natively.

4.1.1 How to boot an OS directly with GRUB

Multiboot (see Multiboot Specification: (multiboot)Top section ‘Motivation’ in The Multiboot Specification) is the native format supported by GRUB. For the sake of convenience, there is also support for Linux, FreeBSD, NetBSD and OpenBSD. If you want to boot other operating systems, you will have to chain-load them (see section Load another boot loader to boot unsupported operating systems).

Generally, GRUB can boot any Multiboot-compliant OS in the following steps:

1. Set GRUB’s root device to the drive where the OS images are stored with the command root (see section root).
2. Load the kernel image with the command kernel (see section kernel).
3. If you need modules, load them with the command module (see section module) or modulenounzip (see section modulenounzip).
4. Run the command boot (see section boot).

Linux, FreeBSD, NetBSD and OpenBSD can be booted in a similar manner. You load a kernel image with the command kernel and then run the command boot. If the kernel requires some parameters, just append the parameters to kernel, after the file name of the kernel. Also, please refer to Some caveats on OS-specific issues, for information on your OS-specific issues.

4.1.2 Load another boot loader to boot unsupported operating systems

If you want to boot an unsupported operating system (e.g. Windows 95), chain-load a boot loader for the operating system. Normally, the boot loader is embedded in the boot sector of the partition on which the operating system is installed.

1. Set GRUB’s root device to the partition by the command rootnoverify (see section rootnoverify):

   grub> rootnoverify (hd0,0)

2. Set the active flag in the partition using the command makeactive(6) (see section makeactive):

   grub> makeactive

3. Load the boot loader with the command chainloader (see section chainloader):

   grub> chainloader +1

   ‘+1’ indicates that GRUB should read one sector from the start of the partition. The complete description about this syntax can be found in How to specify block lists.

4. Run the command boot (see section boot).

However, DOS and Windows have some deficiencies, so you might have to use more complicated instructions. See section DOS/Windows, for more information.

4.2 Some caveats on OS-specific issues

Here, we describe some caveats on several operating systems.

4.2.1 GNU/Hurd

Since GNU/Hurd is Multiboot-compliant, it is easy to boot it; there is nothing special about it. But do not forget that you have to specify a root partition to the kernel.

1. Set GRUB’s root device to the same drive as GNU/Hurd’s. Probably the command find /boot/gnumach or similar can help you (see section find).
2. Load the kernel and the module, like this:

   grub> kernel /boot/gnumach root=hd0s1 grub> module /boot/serverboot

3. Run the command boot (see section boot).

4.2.2 GNU/Linux

It is relatively easy to boot GNU/Linux from GRUB, because it somewhat resembles to boot a Multiboot-compliant OS.

1. Set GRUB’s root device to the same drive as GNU/Linux’s. Probably the command find /vmlinuz or similar can help you (see section find).
2. Load the kernel:

   grub> kernel /vmlinuz root=/dev/hda1

   If you need to specify some kernel parameters, just append them to the command. For example, to set ‘vga’ to ‘ext’, do this:

   grub> kernel /vmlinuz root=/dev/hda1 vga=ext

   See the documentation in the Linux source tree for complete information on the available options.

3. If you use an initrd, execute the command initrd (see section initrd) after kernel:

   grub> initrd /initrd

4. Finally, run the command boot (see section boot).

Caution: If you use an initrd and specify the ‘mem=’ option to the kernel to let it use less than actual memory size, you will also have to specify the same memory size to GRUB. To let GRUB know the size, run the command uppermem before loading the kernel. See section uppermem, for more information.

4.2.3 FreeBSD

GRUB can load the kernel directly, either in ELF or a.out format. But this is not recommended, since FreeBSD’s bootstrap interface sometimes changes heavily, so GRUB can’t guarantee to pass kernel parameters correctly.

Thus, we’d recommend loading the very flexible loader ‘/boot/loader’ instead. See this example:

grub> root (hd0,a)
grub> kernel /boot/loader
grub> boot

4.2.4 NetBSD

GRUB can load NetBSD a.out and ELF directly, follow these steps:

1. Set GRUB’s root device with root (see section root).
2. Load the kernel with kernel (see section kernel). You should append the ugly option ‘--type=netbsd’, if you want to load an ELF kernel, like this:

   grub> kernel --type=netbsd /netbsd-elf

3. Run boot (see section boot).

For now, however, GRUB doesn’t allow you to pass kernel parameters, so it may be better to chain-load it instead. For more information, please see Load another boot loader to boot unsupported operating systems.

4.2.5 OpenBSD

The booting instruction is exactly the same as for NetBSD (see section NetBSD).

4.2.6 DOS/Windows

GRUB cannot boot DOS or Windows directly, so you must chain-load them (see section Load another boot loader to boot unsupported operating systems). However, their boot loaders have some critical deficiencies, so it may not work to just chain-load them. To overcome the problems, GRUB provides you with two helper functions.

If you have installed DOS (or Windows) on a non-first hard disk, you have to use the disk swapping technique, because that OS cannot boot from any disks but the first one. The workaround used in GRUB is the command map (see section map), like this:

grub> map (hd0) (hd1)
grub> map (hd1) (hd0)

This performs a virtual swap between your first and second hard drive.

Caution: This is effective only if DOS (or Windows) uses BIOS to access the swapped disks. If that OS uses a special driver for the disks, this probably won’t work.

Another problem arises if you installed more than one set of DOS/Windows onto one disk, because they could be confused if there are more than one primary partitions for DOS/Windows. Certainly you should avoid doing this, but there is a solution if you do want to do so. Use the partition hiding/unhiding technique.

If GRUB hides a DOS (or Windows) partition (see section hide), DOS (or Windows) will ignore the partition. If GRUB unhides a DOS (or Windows) partition (see section unhide), DOS (or Windows) will detect the partition. Thus, if you have installed DOS (or Windows) on the first and the second partition of the first hard disk, and you want to boot the copy on the first partition, do the following:

grub> unhide (hd0,0)
grub> hide (hd0,1)
grub> rootnoverify (hd0,0)
grub> chainloader +1
grub> makeactive
grub> boot

4.2.7 SCO UnixWare

It is known that the signature in the boot loader for SCO UnixWare is wrong, so you will have to specify the option ‘--force’ to chainloader (see section chainloader), like this:

grub> rootnoverify (hd1,0)
grub> chainloader --force +1
grub> makeactive
grub> boot

4.2.8 QNX

QNX seems to use a bigger boot loader, so you need to boot it up, like this:

grub> rootnoverify (hd1,1)
grub> chainloader +4
grub> boot

4.3 How to make your system robust

When you test a new kernel or a new OS, it is important to make sure that your computer can boot even if the new system is unbootable. This is crucial especially if you maintain servers or remote systems. To accomplish this goal, you need to set up two things:

1. You must maintain a system which is always bootable. For instance, if you test a new kernel, you need to keep a working kernel in a different place. And, it would sometimes be very nice to even have a complete copy of a working system in a different partition or disk.
2. You must direct GRUB to boot a working system when the new system fails. This is possible with the fallback system in GRUB.

The former requirement is very specific to each OS, so this documentation does not cover that topic. It is better to consult some backup tools.

So let’s see the GRUB part. There are two possibilities: one of them is quite simple but not very robust, and the other is a bit complex to set up but probably the best solution to make sure that your system can start as long as GRUB itself is bootable.

4.3.1 Booting once-only

You can teach GRUB to boot an entry only at next boot time. Suppose that your have an old kernel ‘old_kernel’ and a new kernel ‘new_kernel’. You know that ‘old_kernel’ can boot your system correctly, and you want to test ‘new_kernel’.

To ensure that your system will go back to the old kernel even if the new kernel fails (e.g. it panics), you can specify that GRUB should try the new kernel only once and boot the old kernel after that.

First, modify your configuration file. Here is an example:

default saved        # This is important!!!
timeout 10

title the old kernel
root (hd0,0)
kernel /old_kernel
savedefault

title the new kernel
root (hd0,0)
kernel /new_kernel
savedefault 0         # This is important!!!

Note that this configuration file uses ‘default saved’ (see section default) at the head and ‘savedefault 0’ (see section savedefault) in the entry for the new kernel. This means that GRUB boots a saved entry by default, and booting the entry for the new kernel saves ‘0’ as the saved entry.

With this configuration file, after all, GRUB always tries to boot the old kernel after it booted the new one, because ‘0’ is the entry of the old kernel.

The next step is to tell GRUB to boot the new kernel at next boot time. For this, execute grub-set-default (see section Invoking grub-set-default):

# grub-set-default 1

This command sets the saved entry to ‘1’, that is, to the new kernel.

This method is useful, but still not very robust, because GRUB stops booting, if there is any error in the boot entry, such that the new kernel has an invalid executable format. Thus, it it even better to use the fallback mechanism of GRUB. Look at next subsection for this feature.

4.3.2 Booting fallback systems

GRUB supports a fallback mechanism of booting one or more other entries if a default boot entry fails. You can specify multiple fallback entries if you wish.

Suppose that you have three systems, ‘A’, ‘B’ and ‘C’. ‘A’ is a system which you want to boot by default. ‘B’ is a backup system which is supposed to boot safely. ‘C’ is another backup system which is used in case where ‘B’ is broken.

Then you may want GRUB to boot the first system which is bootable among ‘A’, ‘B’ and ‘C’. A configuration file can be written in this way:

default saved        # This is important!!!
timeout 10
fallback 1 2         # This is important!!!

title A
root (hd0,0)
kernel /kernel
savedefault fallback # This is important!!!

title B
root (hd1,0)
kernel /kernel
savedefault fallback # This is important!!!

title C
root (hd2,0)
kernel /kernel
savedefault

Note that ‘default saved’ (see section default), ‘fallback 1 2’ and ‘savedefault fallback’ are used. GRUB will boot a saved entry by default and save a fallback entry as next boot entry with this configuration.

When GRUB tries to boot ‘A’, GRUB saves ‘1’ as next boot entry, because the command fallback specifies that ‘1’ is the first fallback entry. The entry ‘1’ is ‘B’, so GRUB will try to boot ‘B’ at next boot time.

Likewise, when GRUB tries to boot ‘B’, GRUB saves ‘2’ as next boot entry, because fallback specifies ‘2’ as next fallback entry. This makes sure that GRUB will boot ‘C’ after booting ‘B’.

It is noteworthy that GRUB uses fallback entries both when GRUB itself fails in booting an entry and when ‘A’ or ‘B’ fails in starting up your system. So this solution ensures that your system is started even if GRUB cannot find your kernel or if your kernel panics.

However, you need to run grub-set-default (see section Invoking grub-set-default) when ‘A’ starts correctly or you fix ‘A’ after it crashes, since GRUB always sets next boot entry to a fallback entry. You should run this command in a startup script such as ‘rc.local’ to boot ‘A’ by default:

# grub-set-default 0

where ‘0’ is the number of the boot entry for the system ‘A’.

If you want to see what is current default entry, you can look at the file ‘/boot/grub/default’ (or ‘/grub/default’ in some systems). Because this file is plain-text, you can just cat this file. But it is strongly recommended not to modify this file directly, because GRUB may fail in saving a default entry in this file, if you change this file in an unintended manner. Therefore, you should use grub-set-default when you need to change the default entry.

This document was generated on January 3, 2022 using texi2html 1.82.