Menu.lst of grub4dos for booting iso images from usb drive - menu.lst. Not a member of Pastebin yet? Sign Up, it unlocks many cool features!

Boot Menu in grub4dos appear quite monotonous with black background and white font dominant. Users tend to change color Boot Menu to not be boring. The following article will guide you how to do this. Part 4.1 - Modifying the Grub4DOS menu Locate menu.lst on the root of your USB drive and open it in your text editor. You will see the default Grub4DOS menu, which includes a lot of options that have been commented out - feel free to delete everything prefixed with a # as we'll be adding our own entries.

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time. 4 GNU GRUB Manual 2.04 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.

Updated: December 4, 2009; November 30, 2017

Welcome to the GRUB 2 bootloader tutorial! You must have read my GRUB legacy guide. In the last two and a half years, it alone has garnered some half a million views, proving to be quite popular and useful to computer users worldwide.

I want to recreate the same success with my GRUB 2 tutorial. My goal is to provide people running any flavor of UNIX-like operating systems or multi-booting their computers and using GRUB as their bootloader with a simple, no-nonsense, step-by-step, proven and working tutorial that should allow them to quickly, easily and painlessly control the boot sequence of their systems.

In this tutorial, you will learn how to work with GRUB 2, add and remove menu entries, customize titles and boot options, dual-boot and triple-boot operating systems, combine legacy GRUB and GRUB 2, and we will even see how Windows fits into this scheme. After that, we will learn how to recover from errors and mistakes. Follow me.

Table of Contents

1. GRUB 2 introduction
2. Basic usage
3. Real life multi-boot cases
4. Additional test case scenarios
5. Customize GRUB menu
6. GRUB 2 recovery
7. Small problems observed
8. GRUB legacy versus GRUB 2
9. More reading (documents & links)

Warning

Warning! GRUB 2 is still mostly beta software. Although it already ships with Ubuntu flavors, it is not yet production quality per se. You can probably use it without any troubles, although there is a slight, remote yet possible chance of damage.

You need to be aware of this. Furthermore, whenever handling delicate tasks like the critical functions of the system, disk partitioning, boot sequence, imaging, etc, you should always be prepared for the worst. This means:

• You must have a solid, proven backup procedure for all your data.
• You must possess the tools and the knowledge to quickly recover from disasters. This includes being able to restore a previous system image, fix broken configurations, restore the bootloaders, and more.
• You must be confident in what you are doing.

Now that we know this, let us proceed cheerfully and safely. Just remember that GRUB 2 is still beta. Although the same can be claimed for Google Mail, which was beta for some six years or so, you must exercise caution. What's more, the contents and relevance of contents in this tutorial might yet change as GRUB 2 makes into the production, so stay tuned for any updates.

GRUB 2 roadmap

This is something you should consider before trying GRUB 2. When will GRUB 2 become the de facto bootloader for UNIX-like operating systems? Currently, GRUB legacy is doing fine and will continue for many more years. Given the long-term support by companies like RedHat and Novell for their server distributions, GRUB legacy is going to remain the key player for at least 5-10 years.

On desktops, the adoption rate may be faster, but do not expect any miracles too soon. Nevertheless, it does not hurt to start exploring. Be aware that you may encounter some compatibility issues down the road, especially with more conservative distributions that do not embrace new technologies too quickly.

At the time being, GRUB 2 is only used by the Ubuntu family, which makes about a third to one half of the Linux desktop market. That makes this tutorial rather relevant, as about one in every two or three Linux home users will probably be interested in learning more about GRUB 2 and its uses. Let's now move on to the actual mechanics.

GRUB 2 introduction

Before you dig in, I strongly advise you to read my original GRUB tutorial. This will help you understand this article better. GRUB 2 introduces many new changes. GRUB 2 has better portability and modularity, supports non-ASCII characters, dynamic loading of modules, real memory management, and more. All these are pretty much irrelevant for most users. What you need to know are the changes in the configuration files and the way GRUB 2 operates.

New layout

Old GRUB files were (and still are!) located under /boot/grub/, including the menu.lst file that was read during boot and which contents were displayed to the user in the form of the GRUB menu. GRUB 2 places its files in three core locations:

/boot/grub/grub.cfg - This is the main configuration file that replaces menu.lst. Unlike menu.lst, this file cannot be edited by hand! I strongly advise against trying to tamper with this file, using chattr command or anything of the sort. Let it be.

/etc/grub.d/ - This new directory contains GRUB scripts. These scripts are building blocks from which the grub.cfg file is built. When the relevant GRUB command is executed, the scripts are read in a certain sequence and grub.cfg is created.

/etc/default/grub - This file contains the GRUB menu settings that are read by the GRUB scripts and written into grub.cfg. It is the customization part of the GRUB, similar to the old menu.lst, except the actual boot entries.

This means that if you want to change the GRUB menu, you will have to edit existing scripts or create new ones, then update the menu. This is more similar to LILO than GRUB legacy, which allow editing the menu on the fly.

Sample grub.cfg file

The file is located under /boot/grub/:

This is what the grub.cfg file looks like:

It is not really interesting, because it's just a shell script. Most people will probably not want to read its contents or be able to fully understand them. This file is still worth a quick look any time you update the GRUB menu, to make sure the correct entries are included as you expected. But only if you're comfortable with scripts!

Sample /etc/grub.d/ directory

These are the contents of the directory on a fresh installation, in this case Kubuntu:

Let's review the scripts:

00_header is the script that loads GRUB settings from /etc/default/grub, including timeout, default boot entry, and others. We will talk more about these soon.

05_debian_theme defines the background, colors and themes. The name of this script is definitely going to change to when other distributions adopt GRUB 2.

10_linux loads the menu entries for the installed distribution.

20_memtest86+ loads the memtest utility.

30_os-prober is the script that will scan the hard disks for other operating systems and add them to the boot menu.

40_custom/download-ableton-live-9-lite-full-version.html. is a template that you can use to create additional entries to be added to the boot menu.

Have you noticed the numbering in the script names? Well, this is somewhat similar to the order of Start/Kill scripts used in different runlevels. The numbering defines precedence. This means that 10_linux will be executed before 20_memtest86+ and therefore placed higher in the boot menu order.

The scripts are not very interesting. Like the grub.cfg file, they are not intended to be edited, save for 40_custom. You need to very careful when working with these scripts. We will soon see what they look like and learn how to use them.

Sample /etc/default/grub

The file is located under /etc/default:

This directory contains many other files so do not assume it is just used for GRUB. The grub file is a text file that is parsed by the 00_header script. You can make your changes here, if you want. We will talk about these later, in the Customization section.

Now we know what the core files are. Let's see how we use them.

Basic usage

It's time to put our theoretical knowledge to some real action.

How GRUB 2 works?

GRUB 2 works like this: /etc/default/grub contains customization; /etc/grub.d/ scripts contain GRUB menu information and operating system boot scripts. When the update-grub command is run, it reads the contents of the grub file and the grub.d scripts and creates the grub.cfg file.

That's all. To change the grub.cfg file, you need to edit the grub file or the scripts under grub.d. Scripts are meant to be executed. This means that they have the execute bit turned on. If you turn the execute bit off, they will not run.

This means that you can place as many files as you want into the grub.d directory, as long as they are not executable shell scripts that update-grub can read. If you want to use them, you will activate the executable bit, or vice versa, turn it off. Let's examine the scripts. For instance, 00_header and 05_debian_theme:

40_custom makes a little more sense, but it still does not tell us how we can customize the scripts. Don't worry, we will soon learn everything.

Add new GRUB script

To add a new boot option, you will have to follow a basic syntax:

Create a new file that has a XX_ prefix in the name, where XX is a sequence of numbers. If you want the new entry to be placed above others, use lower numbers, if you want it to be placed below others, use higher numbers.

For example, 11_something will be placed after the default entries by the operating system, whereas 08_something will be placed before the 10_linux entries. The next step is to write the actual content. Here's a sample:

#!/bin/sh -e
echo 'Some string'
cat << EOF
menuentry 'Something' {
set root=(hdX,Y)
-- boot parameters --
}
EOF

Let's examine the file. It's a shell script, as declared in the first line.

echo 'Some string' is a string that you will see when running update-grub. If you do not want to see the echo command printed, you can redirect it to standard error or /dev/null:

echo 'Some string' > &2

Example: echo 'Adding openSUSE 11.2'

cat << EOF defines the start of the actual boot entry.

menuentry 'Something' is the name that will show in the menu. Example: Linux.

set root=(hdX,Y) - we're back to old school, setting the root device.

Critical! GRUB 2 uses PARTITION notation that starts with 1 and not 0 like GRUB legacy! This is terribly important to remember!

In other words, devices are still numbered from 0, but partitions start with 1. For example, this means that sda1 is now (hd0,1) and NOT (hd0,0) as before!

-- boot parameters -- will really change from one OS to another. In Linux, you may want to use something like:

linux /boot/vmlinuz
initrd /boot/initrd.img

But in Windows, you would probably use:

chainloader (hdX,Y)+1

Therefore, a complete script example would look something like:

#!/bin/sh -e
echo 'Adding my custom Linux to GRUB 2'
cat << EOF
menuentry 'My custom Linux' {
set root=(hd0,5)
linux /boot/vmlinuz
initrd /boot/initrd.img
}
EOF

Or for Windows, something like:

#!/bin/sh -e
echo 'Adding Windows 8 to GRUB 2 menu'
cat << EOF
menuentry 'Windows 8' {
set root=(hd0,1)
chainloader (hd0,1)+1
}
EOF

EOF ends the GRUB entry.

Now we have a file ready. But we need to make it executable.

chmod +x XX_new_os_script

GRUB 2 commands

One more thing I'd like to emphasize here is the data contained in the cat << EOF section. As we've seen just now, the cat command defines the start of the code in the script that will be added to the GRUB menu literally and NOT interpreted by the shell. In other words, anything that goes between cat << EOF and EOF are GRUB commands.

We have used a number of different commands in this script. Some of these you may have seen before in GRUB legacy, some may appear new and strange. Not to worry, there's a full list, including a comparison to GRUB legacy. Some of the commands have been replaced and others added. For more details, please check GRUB 2 command list.

Update GRUB

The new script is in place, but the GRUB menu (grub.cfg) has not been updated yet. We need to run the update-grub command to make it happen.

update-grub

Here's an example from a dual-boot configuration, which we will examine more deeply later on. I've added two Kubuntu entries and one Ubuntu entry to the Ubuntu GRUB menu. I have done this in order to get rid of the default 10_linux, which is ugly and uses generic kernel names in the titles, plus it calls both Ubuntu and Kubuntu the same. But let's move slowly. Our first task is to add the new scripts. After we ascertain that they boot fine, we will get rid of the duplicates.

After rebooting, we have this - I apologize for the uncomeliness:

Once we are using the new scripts boot properly, we can then chmod -x the 10_linux and get rid of the generic 2.6.31-14 entries, keeping our menu nice and dandy.

Change script boot order by changing numbers

You can also change the numbers if you want. For instance, I changed the Kubuntu entries to 08 and 09, to make them boot first, before default entries and the custom Ubuntu script.

Replacing default entries

This is something you may want to do, just as we have shown above. In order to make sure your new scripts boot correctly, you can refer to a working example of grub.cfg to make sure you use the right linux and initrd lines. Here's an example of what I have:

And accordingly, I've created the new script:

OS Prober

OS Prober can also help you. It will find additional entries on your hard disks and add them to the menu. You can use the added information to create your own scripts. Again, refer to the grub.cfg file, os-prober section, for more data:

Reinstall GRUB

GRUB 2 can be installed even while you are booted in the OS. You do not need a live environment for that. Just execute the grub-install command against the device or the partition you desire.

grub-install <target>

<target> can be /dev/hda, /dev/sdb, /dev/sdc4, and so forth. It is important that you pay attention to the output produced by the command. If you have external disks connected at the time you run the command, it will add these disks to the list of mapped devices. There should be no big harm in that, but if some entries are incorrect, remove them.

grub-install reports incorrect devices

Here's an example of that:

You will need to open the /boot/grub/device.map file, delete the wrong entry, in our case the one pointing to /dev/sdb and rerun the grub-install command.

Grub Menu.lst

Mini summary

That's it for now. You have the tools you need to start working. Still, to make things clearer, I've prepared a short summary that concludes the introduction and basic usage sections. Here we go. GRUB 2 has three main parts:

1. /etc/default/grub - the file containing GRUB 2 menu settings.
2. /etc/grub.d/ - the directory containing GRUB 2 menu creating scripts.
3. /boot/grub/grub.cfg - the GRUB 2 configuration file, not editable.

update-grub command reads the /etc/grub.d directory and looks for executable scripts inside it. The scripts are read, in the order of their numbering, and written into the grub.cfg file, along with the menu settings read from the /etc/default/grub file.

Boot entries come from several sources - the default that comes with the distribution, other operating systems probed on the connected disks and custom scripts written by the user, following a strict syntax. The scripts are written as shell (sh).

You can add/remove entries by simply chmod-ing the scripts; no need to delete them. GRUB 2 can be reinstalled anytime you want, even while booted in the OS. Good so far? Excellent. You see, it's rather simple. Now, let's see a few real-life cases. Afterwards, we will customize GRUB 2 and learn how to recover from serious errors and misconfigurations.

Real life multi-boot cases

In this section, we will discuss several common multi-boot cases that the average user might encounter, including GRUB and GRUB 2 mix, Windows and Linux side by side, chainloading, and some others.

Some of the experiments were conducted on real physical systems, so some screenshots of boot menus come from actual photos, so they may look slightly twisted and less appealing that you would like, but this is in order to reassure you that working with GRUB 2 is as simple as any other administrative task. It just requires some patience and care.

Dual boot: two operating systems with GRUB 2

This is probably the simplest dual-boot configuration. Both operating systems use GRUB 2, so they can easily interact with one another. The two systems are Ubuntu 9.10 and Kubuntu 9.10, both formatted with Ext4.

Ubuntu was installed first, with GRUB 2 installed to the MBR of /dev/sda. Kubuntu was installed second, again to MBR, overwriting the previous instance. However, the OS probe script found and added Ubuntu successfully. If you've read my Kubuntu tutorial, you will notice that Kubuntu entries are also labeled Ubuntu, which can be confusing if you have several, different Ubuntu entries on your machine. In this section, we will:

• Learn how to edit existing entries and make them more presentable.
• Add new entries and reorder existing ones.

This will give us the initial clues into how GRUB 2 works and what users have to do to make it work. After that, we will examine bootloading GRUB 2 ready systems from the legacy GRUB and vice versa. And then, we will add Windows, too.

We have seen snippets of this testcase earlier. We have our default entries, which do not look well and want them replaced. So we refer to grub.cfg file, examine the syntax used by 10_linux and we copy the relevant bits of data into our new scripts, called 08_9_10_kubuntu and 09_9_10_kubuntu_recovery. Just like we did earlier.

After that, we need to chmod +x the scripts and update the GRUB. Very simple.

After rebooting and verifying that everything works, we can get rid of the 10_linux, having replaced its entries with the custom scripts. Job done, very easy!

Dual boot: two operating systems with GRUB legacy & GRUB 2 mix

This is a very interesting case. Let's say you have two operating systems, like Ubuntu 9.10, which uses the new GRUB 2 and boots from Ext4, and a more classic distro like openSUSE 11.2, which does use Ext4, but still boots the old GRUB.

We will learn how to:

• Boot Ubuntu from the context of the openSUSE GRUB.
• Boot openSUSE from the context of the Ubuntu GRUB.
• Edit entries in both systems to make things work.

Decision: which one is default?

This is something you need to decide. You have two bootloader options and you need to choose the default one. If you're asking me, at the time being, you should use GRUB legacy as your default bootloader, because it is production quality and has known, established support channels. Running GRUB 2 will place you in a minority. Therefore, if you are going to use GRUB legacy for booting, then you should:

• Install GRUB into the MBR when installing the distribution that ships it, like openSUSE in our example. Pay attention to these details when installing the distro!
• Install GRUB 2 into the root partition where the distribution using it is installed, in this case Ubuntu. Pay attention to these details when installing the distro.

Otherwise, if you plan on using GRUB 2 as your default, you need to do things the other way around.

If you are not really sure, review the partition table.

In our example, Ubuntu was installed first, with root under /dev/sda6 and home under /dev/sda7. openSUSE was installed next, to /dev/sda1. Since we want to use the GRUB legacy bootloader, then:

• Ubuntu bootloader needs to be installed to /dev/sda6.
• openSUSE bootloader needs to be installed to MBR (/dev/sda).

Now that this is done, let's boot and see what happens. After you install openSUSE, you will notice that the lovely green GRUB menu contains only openSUSE entries. The reason is, GRUB legacy does not know how to handle the GRUB 2 layout directly and therefore cannot find and append entries to the menu. You will have to do this manually.

Boot into openSUSE and open the menu.lst file in a text editor. Back it up first! We do not really know yet how to work with GRUB 2 entries from within GRUB legacy. So we will assume that it's the same thing like Windows. We will chainload the other operating system, passing the command to the other bootloader. Will this work? I do not know, but let's try! We're using our GRUB experience and trying to adapt to the new situation.

For those who cannot see what's in the image, we are adding the following entry to the menu.lst file:

title Ubuntu 9.10 Karmic Koala
root (hd0,5)
chainloader (hd0,5)+1

After booting, you will see the menu (once again, excuse the ugliness):

If you try to boot the Karmic Koala entry, you will hit this unwholesome GRUB error 13:

This kind of error is common for Linux users trying to boot Windows and Mac partitions. For Windows, the solution is to try to remap the partitions, hide partitions or make them active, which usually solves the problem.

Mac-wise, the problem is similar to what we are facing here. GRUB legacy that comes with openSUSE does not handle well the Ubuntu partitions + GRUB 2 mechanism. We will need a different method to get things done. For more information, check GRUB error messages.

Booting Ubuntu (with GRUB 2) from openSUSE the right way

Here's what you need to do to make things work. Go back to openSUSE and open the menu.lst file again. We need to make it look like this:

For those who cannot see what's in the image, we are adding the following entry to the menu.lst file:

title Ubuntu 9.10 Karmic Koala
root (hd0,5)
kernel /boot/grub/core.img
savedefault
boot

You may be wondering what we did here. The answer is, core.img file is a small kernel image that allows you to boot the right drivers and properly identify and initialize the real kernel. You can think of this file as a sort of a transitional initrd.img. After rebooting, you will have the GRUB 2 menu. Select the desired entry and boot.

Once inside Ubuntu, you can do a little trick if you want, that is, rerun the update-grub script. It will now pick up the installed openSUSE as well and add it to the menu. You will then have a recursive GRUB menu that calls the other that calls the other. This is not necessary, but can be fun and exercises the power of knowledge and control.

Another interesting case is Mandriva 2010 and Ubuntu 9.10 dual boot. When installing Mandriva, you have the option to manually edit the GRUB bootloader menu even before the first boot. The truth is, many distributions let you configure the boot menu to some degree. If you know what you need, you can save time by setting up the menu entries during the installation. Here's what editing the GRUB menu following Mandriva installation looks like:

Basically, we have done the exact same thing we did with openSUSE. For more details, please take a look at the review above.

Dual boot: Windows 7 and Ubuntu

This will probably interest quite a few users. In general, it's the same as before. However, to spice things up a little, I have also added another element of interest here, that of the GRUB to GRUB 2 upgrade.

Test case: a machine dual booting Windows 7 and Ubuntu Jaunty, as shown in my new dual boot guide. Jaunty uses GRUB legacy, but it can be upgraded to GRUB 2, which is what we're going to do. So, we will first go through the upgrade procedure, paying attention to important details and then, we will make sure our Ubuntu and Windows installations boot fine.

Upgrade from GRUB legacy to GRUB 2

The first thing is to install the GRUB 2 package:

sudo apt-get install grub2

Watch the terminal. You will soon have to answer a few prompts.

Chainload first

The first thing you will have to decide upon is whether to install GRUB2 into MBR right away or test first by installing to the root partition where Ubuntu is installed and chainloading from GRUB legacy. We have done this earlier, by calling on the core.img file, so we know how to do this. For the sake of elegance, we won't skip this step.

The next step is to verify the command-line parameters. Most people won't need to make any change here.

GRUB 2 is now installed:

Before we reboot, make sure the grub.cfg has been built correctly and that it contains the right entries, pointing to the right devices and partitions. Use fdisk if you need to verify that everything is in order. Ubuntu entry:

Windows entry:

It's time to reboot and test. Your GRUB menu should be changed now and include a Chainload entry for GRUB 2 at the top of the menu.

Possible errors

You may encounter GRUB Error 11 or GRUB Error 15 when you try to boot into GRUB 2.

For instance, GRUB Error 11 means the wrong root device is selected or that you're booting devices by ID rather than numbers, in which case you will have to change one of the strings to make it work.

To remedy the issue, you will have to highlight the Chainload entry, press e to edit, then change the root line to reflect your real selection. Don't forget you're working with GRUB legacy still, so partitions are numbered from 0. In the worst case, cycle through root (hdX,Y) until you nail the right one. Change the root entry, hit Enter, press b to boot.

Alternatively, if your GRUB uses strange, long string called device IDs rather than numbers, you will have to replace the string root with uuid and then you should be able to boot your kernel just fine. HowtoForge has a great example, with screenshots. Eventually, you should see the GRUB 2 menu:

As you can see, we have Ubuntu entries and we have Vista loader (Windows 7) entries. All seems well. Now, boot both Ubuntu and Windows 7 to make sure everything works properly. Once you're satisfied, boot into Ubuntu and complete the migration process. You can now write GRUB 2 into MBR and make it the default bootloader.

sudo upgrade-from-grub-legacy

Pay attention to the device mapping and change accordingly. But that's it. We're done. We have now learned both how to upgrade GRUB, handle some boot errors and successfully boot a dual boot configuration including Windows and Linux.

Additional test case scenarios

Triple boot

From here on, it's damn easy. Use whatever you want. If you're running GRUB legacy as your bootloader, then you will use Windows entries like we did in the original article, plus an entry with /boot/grub/core.img for GRUB 2 entries.

And if you're using GRUB 2, then use OS Prober to find other operating systems. And if you don't like the titles, create custom entries based on the existing selection. The world is your banana, now.

Customize GRUB menu

Let's say we want to edit the GRUB 2 menu a little, including the default selection, the timeout and other options.

Edit /etc/default/grub

This file contains a few interesting options you may want to change, including the default selected entry, the default timeout and additional options.

GRUB_DEFAULT=0 specifies the default entry. It counts from 0, like any geeky menu. Change to anything you like. If you set the entry to GRUB_DEFAULT=saved, it will boot the last selected option from the previous boot.

GRUB_TIMEOUT='10' specifies the default timeout. Change to anything you want. Very small values are not recommended. Setting to -1 will make GRUB wait indefinitely until you manually select an entry and hit Enter.

There are many other options, as you can see, I will not go through all of them. It's important that you remember that they exist and where they can be found. Do not blindly make changes. Consult the official documentation and always backup the file before tampering. One more thing that may interest you is the removal of recovery entries.

Remove recovery entries from the menu

The last line in the /etc/default/grub file allows you to disable the recovery mod menu entries. Simply uncomment the line and update GRUB:

GRUB_DISABLE_LINUX_RECOVERY='true'

Remove memtest from the menu

If you do not want to have the memtest entries included, simply chmod -x the 20_memtest script. It will no longer be executable and won't be read into the grub.cfg file the next time you update GRUB.

sudo chmod -x 20_memtest86+

Change titles in menu entries

Instead of using the replacement tweaks I've suggested earlier, by recreating the default Linux entries and removing (chmod-ing -x) the 10_linux script, you can edit the actual script to behave differently and report information in a more human format. This is some really geeky stuff, take at look at Ubuntu install title tweaks.

Change theme (boot image)

You may want to use a beautiful image during boot rather than the boring blue one. No worries, this can be easily done, by editing the 05_debian_theme script.

The first thing is to find a number of images you want. Pay attention to image detail, as you want to achieve the right contrast between the entries and the background, so you can still read the menu. I will show you my own example - learn from it.

Next, you need a directory to store the images. By default, GRUB 2 takes images from /usr/share/images/desktop-base. This can be a good location - or if you want your own, create one. For instance, /usr/share/images/grub, just as shown on Ubuntu blog.

Copy your images there, mind the extension. By default, GRUB 2 works with .png and .tga files. You can also use .jpg images if you want. The next step is to edit the 05_debian_theme script and change the relevant entry to point to your own:

What I did was comment out the original for loop that reads the image(s) and created my own. If you're not really comfortable doing this, then you should probably postpone any theme tweaking until a later date. My file is located: /usr/share/images/grub/dark.png. Once the file has been changed, run update-grub to update the grub.cfg file. If you've done everything correctly, you should see Found Debian background message in the terminal.

Please note that the GRUB menu will not use background images unless these are enabled. To do that, you will have to change the line use_bg=false in theme script and change it to use_bg=true. Reboot and test:

As you can see, my choice of background image was bad! You cannot see the text! Therefore, choose carefully what kind of background image you want to use. A theme with a few soft gradients seems like the best idea. For more details, take a look at the official Wiki documentation.

GRUB 2 recovery

Recover from failed boots

What happens if you ruin your GRUB 2? There must be a way to reinstall it and save the day? Well, as always, there's the easy way and the hard way.

Easy way: Super Grub Disk

This great tool works with GRUB 2, so no worries, place it into the CD/DVD tray, boot and restore the mangled GRUB. You should keep an image handy and ready, just in case.

Hard way: Manual fix from live CD

You will need a live CD that ships with GRUB 2, like Ubuntu or Kubuntu. Boot into the live session, mount the hard disk and install GRUB 2 to the MBR. This is the sequence of commands you require (assuming disk = /dev/sda). You will need to mount the partition of your installed distribution (e.g. Ubuntu) containing the /boot directory. It may also be a separate partition on your system, depending on your setup. After it is mounted, you will have to rerun the grub-install command.

mount /dev/sda1 /mnt/
grub-install --root-directory=/mnt /dev/sda

If this does not work, you will have to go through a much longer, more complicated procedure, as explained in the official GRUB 2 Ubuntu Wiki documentation.

Use fdisk to locate the right root device, then mount it as before. For the sake of this section, let's assume that /dev/sda1 is a dedicated /boot partition and /dev/sda2 is the root partition of your distro.

sudo mount /dev/sda2 /mnt

If you have a separate /boot partition, you will have to mount it too:

sudo mount /dev/sda1 /mnt/boot

Next, remount the rest of your devices using --bind option. For more details about how the mount command works, please consult the man page.

sudo mount --bind /dev /mnt/dev

Effectively, you now have a root system under mount. You can now change the root from your real one (/) to /mnt. This is done using the chroot command.

sudo chroot /mnt

This means that command executed in this terminal will refer to /mnt/. Now, reconfigure the GRUB package:

dpkg-reconfigure grub-pc

You will have to tell GRUB which device to use. You can change the selection using Spacebar. The devices shown will reflect that in the device.map file, so if you only have one, there should be no issues. Once this step is done, you can exit from the chroot environment. This is done by pressing Ctrl + D keys. After that, unmount the devices, first the /dev, then the rest:

sudo umount /mnt/dev
sudo umount /mnt

Now you can reboot. GRUB 2 should be in place.

Small problems observed

This might be beta or just new features, but I must comment on a number of items I have observed, which could also help you troubleshoot problems in the future more easily.

Kernel crash dump mechanism

GRUB 2 includes a section that checks if a kernel crash dump mechanism like Kdump is installed configured and appends a section to the kernel line. This is not a good idea, because the script does not check the offset where it can place the crash kernel. Furthermore, the memory allocation should be done by the admin and not arbitrarily, because we do not know how big or small the crash kernel should be.

Command names

The two major commands, grub-install and update-grub do not align well. Either both should begin with a grub prefix or both should have a grub suffix.

GRUB legacy versus GRUB 2

Now the big question, why one should you (not) use?

GRUB legacy

It is older and no longer developed, but works great and has proven its worth many times over. Editing the GRUB menu is a very simple thing and require little skill on the behalf of the user, save for making sure the right syntax is followed.

GRUB 2

GRUB 2 is beta software at the moment, although version 1.97 could easily become the official one. This makes it a less likely candidate for production systems. Additionally, GRUB 2 is more difficult to work with, because a) it requires shell skill, which is not something everyone can do b) changes to the GRUB menu are more difficult to implement and require three separate steps rather than one as before c) the changes are not automatic and have to be 'compiled' into the menu every time, similar to what LILO used to do.

GRUB 2 is currently supported by a very small number of distributions, thus you are less likely to receive support and find answers online, including official and unofficial circles. What more, there's a chance you will encounter problems when using GRUB 2 in a mixed environment.

Verdict

I have shown in both GRUB tutorials that even difficult tasks can be achieved relatively easily. It is possible to enjoy both GRUB legacy and GRUB 2, as my detailed examples clearly show. At the moment, though, you are probably better off with GRUB legacy, especially if you are a less knowledgeable user. If you're running Ubuntu, then you can stick with GRUB 2, as it comes as default, just make sure you follow my instructions for a happy and care-free grubbing.

More reading (documents & links)

You are most advised to take a look at the following articles, reviews and howtos:

Official

Other useful GRUB 2 resources

GRUB bootloader - Full tutorial (my article)

Herman's GRUB pages (excellent collection of howtos)

GRUB 2 title tweaks (advanced stuff)

GRUB 2 on archlinux Wiki (advanced stuff)

Conclusion

That's it. You now have a step-by-step guide for installing, configuring and troubleshooting GRUB 2, including the overview of the layout and basic functions, numerous real-life examples like dual boot scenarios with GRUB legacy, GRUB 2 and Windows mixed together, as well as tools and instructions how to troubleshoot problems. This guide should be very handy for you, whether you're a beginner user, a recent Windows convert or a Linux veteran.

Compared to GRUB legacy, GRUB 2 is somewhat harder to use, as it requires familiarity and confidence working with shell, which is outside the realm of most users. Furthermore, it does not easily permit changes and the boot configuration has to be rebuilt every time one is introduced. The true power of GRUB 2 is yet to be revealed.

I hope you are going to like this tutorial as much as the original. I will update it periodically if certain core functions in GRUB change toward production release, as well as write any important tip or trick that comes up. Have fun and spread the word!

Updates

All and any updates regarding GRUB 2 will be listed here, including new features, bug fixes and additional test cases, as well as any other useful material, tips and tricks you find and recommend. I suggest you occasionally check this section.

December 2009, update:

Several question asked by my readers:

What if I use Ext3 filesystem? Can my GRUB boot partitions formatted with Ext4?

The answer is: maybe. If your distro supports Ext4, then yes, if it does not, probably not, because it won't be able to read anything from Ext4-formatted partitions. The easiest way to overcome filesystem compatibility issues is to use a dedicated /boot partition formatted with Ext3. This way, all modern Linux distros will support it.

I have two disks. Ubuntu Karmic is on the second disk. Do I have to use core.img file in my GRUB or can I chainload the usual way?

The answer is: if you have a bootloader installed to the root of the second disk, then you can probably use the traditional chainloading method. But if you're using a single bootloader, then you must resort to core.img file.

Why there's a difference between the 40_custom and your custom scripts?

The answer is: 40_custom script is already configured to be used within the context of other scripts when building the GRUB configuration file, at the end. Custom scripts that you write can go anywhere. Hence, the exec tail -n +3 $0 in the script that you need not use in your own scripts.

Will the custom scripts be updated if my other operating systems get kernel updates?

The answer is: Not automatically, and you'll have to rewrite them to point to relevant kernels. A way of solving this is to create a symbolic link to the latest kernel and the initrd image using vmlinuz and initrd generic names, respectively. This is what openSUSE does, allowing you to keep your GRUB menu static. The only change that needs to be done is to update the symbolic links following kernel updates, without touching the GRUB.

I can't get my custom backgrounds used in the GRUB menu anywhere!

See the use_bg section in the debian_theme script and make sure it's set to true.

June 2010, update:

Grub4dos Menu.lst

GRUB 2 is currently at version 1.98 and this is considered a stable release. There are some small changes in the overall functionality, but 99% of what you see above still applies.

GRUB 2 rescue CD

If you're not using Super Grub Disk (SGD) or have a live CD of a Linux distribution supporting GRUB 2 available, then you may want to consider creating a GRUB 2 rescue CD of your own. Another advantage of this procedure is that the rescue CD will contain your custom GRUB menu.

This is done by using the grub-mkrescue command, which has a slightly different usage syntax for Lucid Lynx, which uses GRUB2-1.98-1ubuntu5 and Karmic and earlier, which use beta versions of the bootloader. Now, here's how to do it. Ubuntu 10.04:

grub-mkrescue --output=<name>.iso /boot/grub

You can use any name you want. Ubuntu 9.10 and earlier:

grub-mkrescue --overlay=/boot/grub <name>.iso

After creating the ISO image, you should burn it and then test it, preferably on another machine, to make sure the GRUB is booted from the CD and not the local disk. If you use a filename without a full path, the ISO image will be created in the current directory.

On the target (test) host, configured to boot from CD, the rescue CD should boot into GRUB commandline. To make sure that the CD works as expected and contains your GRUB menu, please run the following command:

configfile /grub.cfg

This should output your menu. Once satisfied with the change, keep the disc in standby for emergencies. Remember to create a new ISO any time you update the GRUB menu.

You should use the rescue CD to boot into desired operating system and then repair the GRUB using grub-install command, as we've seen earlier. The rescue CD will not work if you delete the operating system or partitions containing them. References:

There are also discussion threads available at Ubuntu forums and wilderssecurity.com, but they most revolve around the usage of these commands and the variations for different Ubuntu releases. Thanks to Ocky for this tip!

December 2010, update:

A few more changes yet. Here's the brief overview and update.

Notation

Once again, the notation has changed. On MS-DOS type partitions, which represents the absolute majority of partition out there, GRUB2 in Maverick uses a new naming convention. Instead of the generic hd(X,Y), now you have hd(X,msdosY), which could be a little confusing. You must take this into account when creating complex multi-boot setups. For more details, please take a look at my Maverick review.

Additional reading

You're also welcome to take a look at the official Ubuntu forums thread on GRUB2.

December 2011, update:

Several more changes. GRUB is officially at version 1.99 and comes with a few more changes. The important cosmetic fix is that additional, older versions of the kernel are all listed under a single directory-like entry, making the menu easier to read. Moreover, Ubuntu comes with a high-resolution menu and smaller font size. Now, let's examine several other things.

Booting Xen kernels in a multi-boot configuration governed by GRUB2

You have seen this example in my Xen intro tutorial. Specifically. Please note that if you're chainloading openSUSE with GRUB2, then you will need to create a special entry for the Xen kernel, which might not be automatically added by the OS probe script. The entry looks different from standard boot stanzas.

multiboot /boot/xen.gz
module /boot/vmlinuz-xen <options>
module /boot/initrd-xen

Of course, adjust the exact paths to match your installations, devices, etc. Here's a screenshot of what it looks like on my test machine:

Fedora 16 Verne support

Grub4dos Menu Lst Manuals Pdf

Fedora 16 also comes with GRUB2. Some of the settings are a little different from Debian-based systems. In fact, you may find Fedora a little tricky to navigate after you've used GRUB2 on Ubuntu and family. Fedora GRUB2 support is still very early and rather buggy, with some of the functionality not yet implemented well.

How to update the GRUB menu

The update command is as follows:

Grub4dos Menu Lst Manuals Downloads

grub2-mkconfig -o /boot/grub2/grub.cfg

This will recreate the grub.cfg file based on your scripts under /etc/grub.d.

Edit header defaults (entry and timeout)

Changing the default entry and the timeout in Ubuntu is fairly trivial. This is not so in Fedora. Editing the 00_header file is more complicated. You must actually change the script functionality to get what you need.

The timeout is defined by make_timeout() function. The function accepts two input parameters, GRUB_TIMEOUT and GRUB_TIMEOUT_BUTTON, which are declared at the beginning of the 00_header script.

However, the variables will get different values based on a variety of environmental settings and configurations. If you find it too hard tracking down the execution, you may want to brute-force the change.

In the make_timeout() function, you can edit the declaration set timeout=${2} to a static value. The script will then ignore the input parameter and use whatever you choose. For example, you may want to increase the timeout from 5 seconds to 20 seconds.

In that case, change the script as follows:

#set timeout=${2}
set timeout=20

Make necessary backups first! And there's no need to delete anything, just comment out the lines you do not want to use. This way, you will be able to revert back to the original state if needed.

After editing the file, you must recreate the grub.cfg file. Once the file is recreated, you can verify that your change has been configured properly by grepping the timeout value in the configuration file.

And here we are booting; notice the timeout counter.

More reading

You may also want to consult the following online pages:

If you feel a separate Fedora & GRUB2 tutorial is needed, we can arrange that too.

June 2012, update:

GRUB 2.00 has been officially released. It comes with all kinds of goodies. We will be seeing GRUB 2 in its major release version coming to various distributions later this year. For the end user, the changes should be transparent. Just use this tutorial and have massive fun.

You might also want to look at my GRUB article in the 117th issue of the Linux User & Developer magazine released in October 2012. It's basically a multi-boot tutorial with focus on the GRUB 2.00 release. Enjoy.

January 2014, update:

A small update on how to update the GRUB configuration file on openSUSE. This is very similar to the exercise we have conducted on Fedora above. The grub.cfg file needs to be created using the grub2-mkconfig command, with the output file flag.

grub2-mkconfig -o /boot/grub2/grub.cfg

You can then create test files and compare before committing changes.

May 2014, update:

You might also be interested to learn about an Asus Ultrabook setup that includes UEFI, Secure Boot, GPT partition table rather than MS-DOS, and a dual-boot configuration of Windows 8.1 and Ubuntu. The GRUB2 configuration is entirely transparent, because of the built-in support in the Ubuntu image. But as a use case, it is quite interesting, especially given the rather complex default layout of the laptop in question.

April 2015, GRUB2 & EFI recovery:

If you need to recover GRUB on systems with UEFI and GPT, then I have a complete separate guide for this. The procedure is a bit long and it warrants its own article, that's why I'm splitting from this already very long and detailed howto.

June 2015, GRUB2 & UEFI:

Furthermore, a reader named Phil has some additional interesting pointers. Namely, the location of the grub.cfg file is different on systems that use UEFI. You can locate the correct path on your system using the find command:

find /boot -name 'grub.cfg'

For instance, you may get /boot/efi/EFI/centos/grub.cfg. Therefore, if you need to update the configuration file, and you want to do it explicitly, without using the GRUB update command, you will need to specify the correct file as the output:

grub2-mkconfig -o /boot/efi/EFI/<os>/grub.cfg

February 2017, GRUB2 & UEFI errors:

I have published two additional tutorials that help address several new boot problem scenarios, including a corrupt EFI partition after an installation of a Linux distribution, and not being able to boot other operating systems in a multi-boot setup governed by a Red Hat based distro bootloader on UEFI systems due to missing EFI modules with linuxefi and initrdefi commands.

error: can't find command 'linux'
error: can't find command 'initrd'

More to come .. P.S. If you find this article useful, please support Dedoimedo.

Cheers for now, stay tuned for updates.