Mastering Grub – Part 1 – Introduction and Overview of Grub Boot Loader

1. Introduction to Grub

Briefly, a “boot loader” is the first software program that runs when a computer starts. It is responsible for loading and transferring control to an operating system “kernel” software (such as Linux or GNU Mach). The kernel, in turn, initializes the rest of the operating system (e.g. a GNU system).

GNU GRUB is a very powerful boot loader, which can load a wide variety of free operating systems, as well as proprietary operating systems with chain-loading. GRUB is designed to address the complexity of booting a personal computer; both the program and this manual are tightly bound to that computer platform, although porting to other platforms may be addressed in the future.

One of the important features in GRUB is flexibility; GRUB understands filesystems and kernel executable formats, so you can load an arbitrary operating system the way you like, without recording the physical position of your kernel on the disk. Thus you can load the kernel just by specifying its file name and the drive and partition where the kernel resides.

When booting with GRUB, you can use either a command-line interface , or a menu interface. Using the command-line interface, you type the drive specification and file name of the kernel manually. In the menu interface, you just select an OS using the arrow keys. The menu is based on a configuration file which you prepare beforehand . While in the menu, you can switch to the command-line mode, and vice-versa. You can even edit menu entries before using them.

1.1 History of GRUB

GRUB originated in 1995 when Erich Boleyn was trying to boot the GNU Hurd with the University of Utah’s Mach 4 microkernel (now known as GNU Mach). Erich and Brian Ford designed the Multiboot Specification, because they were determined not to add to the large number of mutually-incompatible PC boot methods.

Erich then began modifying the FreeBSD boot loader so that it would understand Multiboot. He soon realized that it would be a lot easier to write his own boot loader from scratch than to keep working on the FreeBSD boot loader, and so GRUB was born.

Erich added many features to GRUB, but other priorities prevented him from keeping up with the demands of its quickly-expanding user base. In 1999, Gordon Matzigkeit and Yoshinori K. Okuji adopted GRUB as an official GNU package, and opened its development by making the latest sources available via anonymous CVS. *Note Obtaining and Building GRUB::, for more information.

Over the next few years, GRUB was extended to meet many needs, but it quickly became clear that its design was not keeping up with the extensions being made to it, and we reached the point where it was very difficult to make any further changes without breaking existing features. Around 2002, Yoshinori K. Okuji started work on PUPA (Preliminary Universal Programming Architecture for GNU GRUB), aiming to rewrite the core of GRUB to make it cleaner, safer, more robust, and more powerful. PUPA was eventually renamed to GRUB 2, and the original version of GRUB was renamed to GRUB Legacy. Small amounts of maintenance continued to be done on GRUB Legacy, but the last release (0.97) was made in 2005 and at the time of writing it seems unlikely that there will be another.

By around 2007, GNU/Linux distributions started to use GRUB 2 to limited extents, and by the end of 2009 multiple major distributions were installing it by default.

1.2 Differences from previous versions

GRUB 2 is a rewrite of GRUB , although it shares many characteristics with the previous version, now known as GRUB Legacy. Users of GRUB Legacy may need some guidance to find their way around this new version.

  • The configuration file has a new name (‘grub.cfg’ rather than ‘menu.lst’ or ‘grub.conf’), new syntax and many new commands . The ‘grub.cfg’ is typically automatically generated by ‘grub2-mkconfig’ (*note Simple configuration::). This makes it easier to handle versioned kernel upgrades.
  • Partition numbers in GRUB device names now start at 1, not 0
  • A small amount of persistent storage is available across reboots, using the ‘save_env’ and ‘load_env’ commands in GRUB and the ‘grub2-editenv’ utility. This is not available in all configurations
  • GRUB 2 has more reliable ways to find its own files and those of target kernels on multiple-disk systems, and has commands to find devices using file system labels or Universally Unique Identifiers (UUIDs).
  •  GRUB 2 supports many more file systems , including but not limited to ext4, HFS+, and NTFS.
  •  GRUB 2 can read files directly from LVM and RAID devices.
  •  A graphical terminal and a graphical menu system are available.
  •  The image files that make up GRUB have been reorganized; Stage 1, Stage 1.5, and Stage 2 are no more.
  •  GRUB 2 puts many facilities in dynamically loaded modules, allowing the core image to be smaller, and allowing the core image to be built in more flexible ways.

1.3 GRUB features

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

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

  • Basic functions must be straightforward for end-users.-vbbh
  • 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(1), 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 : Support a human-readable text configuration commands. You can also load another configuration and embed a preset configuration list of commands are a superset of those supported on the command-line.
  • 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 GRUB drops to the command-line.
  • Support multiple  : Support multiple explicit blocklist notation. The currently supported types are
    • “Amiga Fast “BtrFS” (including raid0, raid1, raid10, gzip and lzo)
    • “cpio” (little- and big-endian bin, odc and newc variants)
    • “Linux ext2/ext3/ext4”, “DOS FAT12/FAT16/FAT32”,
    • “exFAT”, “HFS” , “HFS+” and”ISO9660″ (including Joliet, Rock-ridge and multi-chunk “JFS”, “Minix fs” (versions 1, 2 and 3)
    • “nilfs2”, “NTFS” (including compression),
    • “ReiserFS”, “ROMFS”, “Amiga Smart and “ZFS” (including lzjb, gzip, zle, mirror, stripe, raidz1/2/3 and encryption in AES-CCM and AES-GCM).
  • Support automatic decompression : Can decompress. This function is both automatic and transparent to the user (i.e. all functions operate upon the uncompressed contents of the specified reduces a for floppies. 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 (*note Multiboot Specification: (multiboot)Top.), 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.

2. Grub Naming convention

The device syntax used in GRUB is a wee bit different from what you may have seen before in your operating system(s), and you need to know it so that you can specify a drive/partition.

Look at the following examples and explanations:

(fd0)               First of all, GRUB requires that the device name be enclosed with ‘(‘ and ‘)’. The ‘fd’ part means that it is a floppy disk. The number ‘0’ is the drive number, which is counted from _zero_. This expression means that GRUB will use the whole floppy disk.

(hd0,msdos2)   Here, ‘hd’ means it is a hard disk drive. The first integer ‘0’ indicates the drive number, that is, the first hard disk, the string ‘msdos’ indicates the partition scheme, while the second integer, ‘2’, indicates the partition number (or the PC slice number in the BSD terminology). The partition numbers are counted from _one_, not from zero (as was the case in previous versions of GRUB). This expression means the second partition of the first hard disk drive. In this case, GRUB uses one partition of the disk, instead of the whole disk.

(hd0,msdos5)    This specifies the first “extended partition” of the first hard disk drive. Note that the partition numbers for extended partitions are counted from ‘5’, regardless of the actual number of primary partitions on your hard disk.

(hd1,msdos1,bsd1)   This means the BSD ‘a’ partition on first PC slice number of the second hard disk.

Of course, to actually access the disks or partitions with GRUB, you need to use the device specification in a command, like ‘set root=(fd0)’ or ‘parttool (hd0,msdos3) hidden-‘. To help you find out which number specifies a partition you want, the GRUB command-line  options have argument completion. This means that, for example, you only need to type

set root=(  followed by a <TAB>, and GRUB will display the list of drives, partitions, or name of your target partition, even with minimal knowledge of the syntax.

Note that GRUB does _not_ distinguish IDE from SCSI – it simply counts the drive numbers from zero, regardless of their type. Normally, any IDE drive number is less than any SCSI drive number, although that is not true if you change the boot sequence by swapping IDE and SCSI drives in your BIOS. Below is an example:

(hd0,msdos1)/vmlinuz

This specifies the of the first hard disk drive. Note that the argument completion works with

3. OS-specific notes about grub tools

On OS which have device nodes similar to Unix-like OS GRUB tools use the OS name.

For GNU/Linux:

# grub2-install /dev/sda

On AROS we use another syntax. For volumes:

//:<volume name>

E.g.

//:DH0

For disks we use syntax:
//:<driver name>/unit/flags

E.g.

# grub2-install //:ata.device/0/0

On Windows we use UNC path.

For volumes it’s typically

\\?\Volume{<GUID>}
\\?\<drive letter>:

E.g.

\\?\Volume{17f34d50-cf64-4b02-800e-51d79c3aa2ff}
\\?\C:

For disks it’s

\\?\PhysicalDrive<number>

E.g.

# grub2-install \\?\PhysicalDrive0

Beware that you may need to further escape the backslashes depending on your shell.

When compiled with cygwin support then cygwin drive names are automatically when needed. Example:

# grub2-install /dev/sda

4. Installation

In order to install GRUB as your boot loader, you need to first install the GRUB system and utilities under your UNIX-like operating system . You can do this either from the source tarball, or as a package for your OS.

After you have done that, you need to install the boot loader on a drive (floppy or hard disk) by using the utility ‘grub2-install’ (*note Invoking grub2-install::) on a UNIX-like OS.
GRUB comes with boot images, which are normally put in the directory

‘/usr/lib/grub/<cpu>-<platform>’ (for BIOS-based machines ‘/usr/lib/grub/i386-pc’).

Hereafter, the directory where GRUB images are initially placed (normally ‘/usr/lib/grub/<cpu>-<platform>’) will be called the “image directory”, and the directory where the boot loader needs to find them (usually ‘/boot’) will be called the “boot directory”.

4.1 Installing GRUB using grub2-install

In order to install GRUB under a UNIX-like OS (such as GNU), invoke the program ‘grub2-install’ (*note Invoking grub2-install::) as the superuser (“root”).

The usage is basically very simple. You only need to specify one argument to the program, namely, where to install the boot loader. The argument has to be either a device under Linux the following will install GRUB into the MBR of the first IDE disk:

# grub2-install /dev/sda

Likewise, under GNU/Hurd, this has the same effect:

# grub2-install /dev/hd0

But all the above examples assume that GRUB should put images under the ‘/boot’ directory. If you want GRUB to put images under a directory other than ‘/boot’, you need to specify the option ‘–boot-directory’.

The typical usage is that you create a GRUB boot floppy :

# mke2fs /dev/fd0
# mount -t ext2 /dev/fd0 /mnt
# mkdir /mnt/boot
# grub2-install –boot-directory=/mnt/boot /dev/fd0
# umount /mnt

Some BIOSes have a bug of exposing the first partition of a USB drive as a floppy instead of exposing the USB drive as a hard disk (they call it “USB-FDD” boot). In such cases, you need to install like this:

# losetup /dev/loop0 /dev/sdb1
# mount /dev/loop0 /mnt/usb
#grub2-install –boot-directory=/mnt/usb/bugbios –force –allow-floppy /dev/loop0

This install doesn’t conflict with standard install as long as they are in separate directories.

Note that ‘grub2-install’ is actually just a shell script and the real task is done by other tools such as ‘grub2-mkimage’. Therefore, you may run those commands directly to install GRUB, without using ‘grub2-install’. Don’t do that, however, unless you are very familiar with the internals of GRUB. Installing a boot loader on a running OS may be extremely dangerous.

On EFI systems for fixed disk install you have to mount EFI System Partition. If you mount it at ‘/boot/efi’ then you don’t need any special arguments:

# grub2-install

Otherwise you need to specify where your EFI System partition is mounted:

# grub2-install –efi-directory=/mnt/efi

For removable installs you have to use ‘–removable’ and specify both ‘–boot-directory’ and ‘–efi-directory’:

# grub2-install –efi-directory=/mnt/usb –boot-directory=/mnt/usb/boot –removable

4.2 Making a GRUB bootable CD-ROM

GRUB supports the “no emulation mode” in the El Torito specification. This means that you can use the whole CD-ROM from GRUB and you don’t have to make a floppy or hard disk image

For booting from a CD-ROM, GRUB uses a special image called ‘cdboot.img’, which is concatenated with ‘core.img’. The ‘core.img’ used for this should be built with at least the ‘iso9660’ and ‘biosdisk’ modules. Your bootable CD-ROM will usually also need to include a configuration

To make a simple generic GRUB rescue CD, you can use the ‘grub2-mkrescue’ program:

$ grub2-mkrescue -o grub.iso

You will often need to include other this, first make a top directory for the bootable image, say, ‘iso’:

$ mkdir iso

Make a directory for GRUB:

$ mkdir -p iso/boot/grub

If desired, make the config, and copy any to the directory ‘iso/’. 

Finally, make the image:

$ grub2-mkrescue -o grub.iso iso

This produces a a CD (or a DVD), or written to a USB mass storage device.

The root device will be set up appropriately on entering your ‘grub.cfg’ configuration without needing to use an explicit device name. This makes it easier to produce rescue images that will work on both optical drives and USB mass storage devices.

4.3 The map between BIOS drives and OS devices

If the device map read it to map BIOS drives to OS devices. This like this:

(DEVICE)   DEVICE is a drive specified in the GRUB syntax (*note Device syntax::), and

Historically, the device map had to be used in the configuration BIOS drive numbers. The map between BIOS drives and OS devices cannot always be guessed correctly: for example, GRUB will get the order wrong if you exchange the boot sequence between IDE and SCSI in your BIOS.

Unfortunately, even OS device names are not always stable. Modern versions of the Linux kernel may probe drives in a different order from boot to boot, and the prefix (‘/dev/hd*’ versus ‘/dev/sd*’) may change depending on the driver subsystem in use. As a result, the device map

GRUB avoids this problem nowadays by using UUIDs or labels when generating ‘grub.cfg’, and we advise that you do the same for any custom menu entries you write. If the device map exist, then the GRUB utilities will assume a temporary device map on the fly. This is often good enough, particularly in the common case of single-disk systems.

However, the device map used for overriding when current environment is different from the one on boot. Most common case is if you use a partition or logical volume as a disk for virtual machine. You can put any comments in the needed, as the GRUB utilities assume that a line is just a comment if the first character is ‘#’.

4.4 BIOS installation

MBR – Master Boot Record

The partition table format traditionally used on PC BIOS platforms is called the Master Boot Record (MBR) format; this is the format that allows up to four primary partitions and additional logical partitions. With this partition table format, there are two ways to install GRUB: it can be embedded in the area between the MBR and the first partition (called by various names, such as the “boot track”, “MBR gap”, or “embedding area”, and which is usually at least 31 KiB), or the core image can be installed in a make it up can be stored in the first sector of that partition.

Each of these has different problems. There is no way to reserve space in the embedding area with complete safety, and some proprietary software is known to use it to make it difficult for users to work around licensing restrictions; and systems are sometimes partitioned without leaving enough space before the first partition. On the other hand, installing to a blocks being moved around by or even by aggressive fsck implementations, so this approach is quite fragile; and this approach can only be used if the ‘/boot’ on the same disk that the BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive numbers.

The GRUB development team generally recommends embedding GRUB before the first partition, unless you have special requirements. You must ensure that the first partition starts at least 31 KiB (63 sectors) from the start of the disk; on modern disks, it is often a performance advantage to align partitions on larger boundaries anyway, so the first partition might start 1 MiB from the start of the disk.

GPT – GUID Partition Table (GPT)

Some newer systems use the GUID Partition Table (GPT) format. This was specified as part of the Extensible Firmware Interface (EFI), but it can also be used on BIOS platforms if system software supports it; for example, GRUB and GNU/Linux can be used in this configuration. With this format, it is possible to reserve a whole partition for GRUB, called the BIOS Boot Partition. GRUB can then be embedded into that partition without the risk of being overwritten by other software and without being contained in a around.

When creating a BIOS Boot Partition on a GPT system, you should make sure that it is at least 31 KiB in size. (GPT-formatted disks are not usually particularly small, so we recommend that you make it larger than the bare minimum, such as 1 MiB, to allow plenty of room for growth.) You must also make sure that it has the proper partition type. Using GNU Parted, you can set this using a command such as the following:

# parted /dev/DISK set PARTITION-NUMBER bios_grub on

If you are using gdisk, set the partition type to ‘0xEF02’. With partitioning programs that require setting the GUID directly, it should be ‘21686148-6449-6e6f-744e656564454649’.

*Caution:* Be very careful which partition you select! When GRUB finds a BIOS Boot Partition during installation, it will automatically overwrite part of it. Make sure that the partition does not contain any other data.

5. 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.

5.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.

5.1.1 How to boot an OS directly with GRUB

1. Run the command ‘boot’ .

However, DOS and Windows have some deficiencies, so you might have to use more complicated instructions.

5.1.2 Chain-loading an OS

Operating systems that do not support Multiboot and do not have specific support in GRUB (specific support is available for Linux, FreeBSD, NetBSD and OpenBSD) must be chain-loaded, which involves loading another boot loader and jumping to it in real mode.

The ‘chainloader’ command  is used to set this up. It is normally also necessary to load some GRUB modules and set the appropriate root device. Putting this together, we get something like this, for a Windows system on the first partition of the first hard disk:

menuentry “Windows” {
insmod chain
insmod ntfs
set root=(hd0,1)
chainloader +1

}

On systems with multiple hard disks, an additional workaround may be required.

Chain-loading is only supported on PC BIOS and EFI platforms.

5.2 Loopback booting

GRUB is able to read from an image (be it one of CD or HDD) stored on any of its accessible storages . However the OS itself should be able to find its root. This usually involves running a userspace program running before the real root is discovered. This is achieved by GRUB loading a specially made small image and passing it as ramdisk to the kernel.

This is achieved by commands

  • ‘kfreebsd_module’
  • ‘knetbsd_module_elf’
  • ‘kopenbsd_ramdisk’
  • ‘initrd’
  • ‘initrd16’ 
  • ‘multiboot_module’
  • ‘multiboot2_module’ 
  • ‘xnu_ramdisk’

Note that for knetbsd the image must be put inside miniroot.kmod and the whole miniroot.kmod has to be loaded. In kopenbsd payload this is disabled by default.

Aditionally behaviour of initial ramdisk depends on command line options. Several distributors provide the image for this purpose or it’s integrated in their standard ramdisk and activated by special option. Consult your kernel and distribution manual for more details.

Other loaders like appleloader, chainloader (BIOS, EFI, coreboot), freedos, ntldr and plan9 provide no possibility of loading initial ramdisk and as far as author is aware the payloads in question don’t support either initial ramdisk or discovering loopback boot in other way and as such not bootable this way. Please consider alternative boot methods like copying all partition. Consult your OS documentation for more details

5.3 Some caveats on OS-specific issues

5.3.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. The command 

search –set=root —

2. Load the kernel and the modules, like this:

 

grub> multiboot /boot/gnumach.gz root=device:hd0s1
grub> module /hurd/ext2fs.static ext2fs –readonly \
–multiboot-command-line=’${kernel-command-line}’ \
–host-priv-port=’${host-port}’ \
–device-master-port=’${device-port}’ \
–exec-server-task=’${exec-task}’ -T typed ‘${root}’ \
‘$(task-create)’ ‘$(task-resume)’
grub> module /lib/ld.so.1 exec /hurd/exec ‘$(exec-task=task-create)’

3. Finally, run the command ‘boot’

5.3.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. The command

‘search –set=root —

2. Load the kernel using the command ‘linux’ (*note linux::):

grub> linux /vmlinuz root=/dev/sda1

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

grub> linux /vmlinuz root=/dev/sda1 acpi=off

With ‘linux’ GRUB uses 32-bit protocol. Some BIOS services like APM or EDD aren’t available with this protocol. In this case you need to use ‘linux16’

grub> linux16 /vmlinuz root=/dev/sda1 acpi=off

3. If you use an initrd, execute the command ‘initrd’
after ‘linux’:

grub> initrd /initrd

If you used ‘linux16’ you need to use ‘initrd16’:

grub> initrd16 /initrd

4. Finally, run the command ‘boot’ (*note 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. *Note uppermem::, for more information.

5.3.3 NetBSD

Booting a NetBSD kernel from GRUB is also relatively easy: first set GRUB’s root device, then load the kernel and the modules, and finally run ‘boot’.

1. Set GRUB’s root device to the partition holding the NetBSD root

the first partition (a:). In that case, and assuming that the partition is on the first hard disk, set GRUB’s root device as follows:

grub> insmod part_bsd
grub> set root=(hd0,netbsd1)

For a disk with a GUID Partition Table (GPT), and assuming that the NetBSD root partition is the third GPT partition, do this:

grub> insmod part_gpt
grub> set root=(hd0,gpt3)

2. Load the kernel using the command ‘knetbsd’:

grub> knetbsd /netbsd

Various options may be given to ‘knetbsd’. These options are, for the most part, the same as in the NetBSD boot loader. For instance, to boot the system in single-user mode and with verbose messages, do this:

grub> knetbsd /netbsd -s -v

3. If needed, load kernel modules with the command ‘knetbsd_module_elf’. A typical example is the module for the root

grub> knetbsd_module_elf /stand/amd64/6.0/modules/ffs/ffs.kmod

4. Finally, run the command ‘boot’

5.3.4 DOS/Windows

GRUB cannot boot DOS or Windows directly, so you must chain-load them (*note Chain-loading::). 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 ‘drivemap’ , like this:

drivemap -s (hd0) (hd1)

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, DOS (or Windows) will ignore the partition. If GRUB “unhides” a DOS (or Windows) partition, 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:

parttool (hd0,1) hidden-
parttool (hd0,2) hidden+
set root=(hd0,1)
chainloader +1
parttool ${root} boot+
boot

Ramdev

Ramdev

I have started unixadminschool.com ( aka gurkulindia.com) in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' unixadminschool.com. You can connect me at - https://www.linkedin.com/in/unixadminschool/

1 Response

  1. October 6, 2015

    […] Mastering Grub – Part 1 – Introduction and Overview of Grub Boot Loader […]

What is in your mind, about this post ? Leave a Reply

Close
  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us