GRUB 2: A Guide for Users

[Qqmike]

This is a re-post of topic:
GRUB 2 A Guide for Users
http://kubuntuforums.net/forums/inde...opic=3106368.0
Post by: Qqmike on September 11, 2009, 03:38:49 pm

See:
Lost Information
http://kubuntuforums.net/forums/inde...opic=3117115.0
Kubuntuforums SQL table corruption
http://kubuntuforums.net/forums/inde...opic=3117108.0
-----------------------------------------------------------------------------------------

GRUB 2 A Guide for Users

Updated: 9/11/09, 9/12/09, 9/20/09, 9/22/09, 9/23/09, 10/04/09, 10/6/09, 10/7/09, 10/9/09, 10/12/09 (Dual booting, drivemap in Reply #1), 12/4/09 (edited References), 6/8/11 (Re-posted the how to; made changes)

Bugs and Questions: See REFERENCES at the end.

GRUB 2 Practical Reminders (a cheat sheet for those who know what they are doing)
See end of SECTION 4 Special Topics.

NEW comment (10-0-09)
update-grub vs grub-mkconfig
It appears that update-grub has been replaced by grub-mkconfig.
HOWEVER, it appears that update-grub works fine, at least in 9.10 Karmic.
update-grub is usually easier to use.

I have made the switch throughout the how-to (in the first post of this thread).
Note: update-grub
The command update-grub generates a new grub.cfg file and replaces the existing grub.cfg with the newly generated grub.cfg (by default).
But, as explained next, you must specify the output file when using grub-mkconfig:
Note that
sudo grub-mkconfig
prints its output to the screen (default = stdout).
To print to the grub.cfg, use
sudo grub-mkconfig -o /boot/grub/grub.cfg
or
sudo grub-mkconfig --output=/boot/grub/grub.cfg
- - - - - - - - - -

TABLE of CONTENTS

SECTION 1
Introduction
History: GRUB Legacy, GRUB 2
Differences between GRUB Legacy and GRUB 2
GRUB 2 commands
Notes about some of the new GRUB 2 commands: See Reply #1

SECTION 2
Key Facts About the Boot menu, grub.cfg
Quick version -- Overview -- Details
/etc/grub/default --> /etc/grub.d --> /boot/grub/grub.cfg
Rules for editing grub.cfg, /etc/default/grub, and the script files in /etc/grub.d
GRUB 2 device numbering is different: Partitions start at 1
Details

SECTION 3 Fixing Things
A checklist of things to try to fix a broken system
A Troubleshooting Outline
Ctrl+Alt+Del will reboot your PC
Super Grub Disk: Very Important
Key commands: grub-mkconfig and sudo grub-install
Timeout & Default OS, changing
Kernel options, changing
To see or to hide the boot menu
Missing OS entry in the boot menu
Editing the boot menu during booting: "e" key
The GRUB prompt grub> -- What to do with it
=> Getting information and booting an OS
Re-installing GRUB 2 using Live CD: Key Rescue Method
Using a Live CD to edit files in your OS

SECTION 4
Special Topics
Installing GRUB 2 to your PC
grub-install The most useful command
The various types of command modes.
"c," grub>, Konsole BASH, edit "e", emu
TAB Completion
How to get information about your drives and devices
At Konsole : sudo fdisk -lu
At the GRUB 2 prompt: grub> ls
Boot menu: Adding or removing an OS entry
Boot menu: Create a custom boot entry
Boot menu: Making your own custom grub.cfg
Boot menu: Changing resolution, text colors, setting background image
4 ways to boot an OS: configfile, symlinks, direct booting, chainloader
Boot menu: Background image editing tip for those with widescreen monitors
Dedicated GRUB 2 partition: How to build it
GRUB 2 Flashdrive: How to build it
Use of the term "root"
GRUB's Root Device, the Linux statement: root=UUID=,
--root-directory=DIR INSTALL_DEVICE
Dual booting: See Reply #1
Booting XP on a non-first hard drive (drivemap): See Reply #1

Cheat sheet: GRUB 2 Practical Reminders

Appendix: Techniques
--- Installing Kubuntu--GRUB 2 placement
--- Working as root, editing a file
--- Permissions: read, write, execute; change the execute bit
--- Chroot -- how to

References and Tutorials
- - - - - - - - - -

REPLY #1
See also REPLY #1 below this post for these GRUB 2 topics:

Notes about some of the new GRUB 2 commands
Included: chainloader, ls, grub-emu, grub-mkconfig (many tips!), root, rootnoverify (is gone), grub-setup
grub-install: See SECTION 4 above.
drivemap: See Reply #?? below; See Reply #1
loopback: See Boot From ISO (below)

Dual booting: How to set it up
Installing two or more Linux operating systems
RECOMMENDED METHOD
PROBLEMS
Messing up the booting -- fixing GRUB without re-installing Kubuntu
Windows topics
Installing XP (or 7? or Vista?) & Kubuntu:
How to set up dual booting (recommended outline)
Re-installed XP and now can't boot Kubuntu
XP on a non-first hard drive: (hdx,y), x > 1

Booting XP on a non-first hard drive
The drivemap command in GRUB 2

Boot From ISO -- use of GRUB 2 loopback
Boot your Kubuntu Live CD ISO from your flashdrive

GPT: GUID Partition Table
... for Kubuntu 9.10 and GRUB 2
=> Overcoming the "2 TB disk size limit"associated with the conventional MBR
=> Testing GRUB 2 on your GPT-partitioned flash drive


= = = = = = = = = = = = = = = = = = = =
SECTION 1
Introduction
History: GRUB Legacy, GRUB 2
Differences between GRUB Legacy and GRUB 2
GRUB 2 commands
Notes about some of the new GRUB 2 commands: See Reply #1


History: GRUB Legacy, GRUB 2
"Briefly, boot loader is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the operating system kernel software (such as the Hurd or the Linux). The kernel, in turn, initializes the rest of the operating system (e.g. GNU)." (gnu.org)

The original GRUB (GRand Unified Bootloader) was developed by Erich Stefan Boleyn, from which came the GRUB most of us know, GRUB version 0.9x, and that is now referred to as GRUB Legacy (or even GRUB 1 by some writers). GRUB 2 replaces GRUB Legacy. (GRUB 2 is actually the end result of versions GRUB 1.xx; e.g., 1,96, 1.97, ...)

For the history of GRUB and some interesting links, see
http://www.gnu.org/software/grub/

GRUB 2 is cleaner, more efficient, powerful, and more elegant, in many ways it is simpler to use than GRUB Legacy.
GRUB 2: http://www.gnu.org/software/grub/grub-2.en.html
Its mailing list for development,
GRUB-devel: http://lists.gnu.org/mailman/listinfo/grub-devel
And the Wiki: http://grub.enbug.org/

GRUB 2 is the default bootloader in 9.10
https://lists.ubuntu.com/archives/ub...ne/000573.html


Differences between GRUB Legacy and GRUB 2

From the user's view, the biggest difference between the two versions of GRUB concerns the boot menu configuration file.
GRUB 2: /boot/grub/grub.cfg
GRUB Legacy: /boot/grub/menu.lst
The configuration file is used to generate the boot menu you see at boot time.
In GRUB Legacy, you can edit menu.lst directly and in any way you wish.
In GRUB 2, you should not edit grub.cfg directly. Instead, you edit the file /etc/default/grub (which contains some default settings); this file feeds data to scripts in the folder /etc/grub.d. And you may edit the scripts (text files) in the folder /etc/grub.d; these scripts are used to generate the configuration file /boot/grub/grub.cfg. When you need a new grub.cfg, simply do sudo grub-mkconfig -o /boot/grub/grub.cfg.

It is conceptually simple in GRUB 2:
You can edit the file /etc/default/grub and you can edit the scripts in /etc/grub.d, then run the command sudo grub-mkconfig -o /boot/grub/grub.cfg, and the file grub.cfg is automatically generated.

The configuration file in GRUB 2 grub.cfg looks different than the GRUB Legacy menu.lst. For example, in GRUB legacy, you use
default 0
timeout 5
In GRUB 2, default and timeout are variables, and it is
set default=0
set timeout=5

A boot entry in GRUB Legacy menu.lst might look like this:
title Ubuntu 8.04.3 LTS, kernel 2.6.24-24-generic
root (hd1,2)
kernel /boot/vmlinuz-2.6.24-24-generic root=UUID=0df17bc5-0056-4ef7-bfca-251194b6eb44 ro quiet splash
initrd /boot/initrd.img-2.6.24-24-generic

In GRUB 2 grub.cfg, it would look like this:

### BEGIN /etc/grub.d/10_Linux ###
menuentry "Ubuntu 8.04.3 LTS, kernel 2.6.24-24-generic" {
set root=(hd1,2)
linux /boot/vmlinuz-2.6.24-24-generic root=UUID=0df17bc5-0056-4ef7-bfca-251194b6eb44 ro quiet splash
initrd /boot/initrd.img-2.6.24-24-generic
}
### END /etc/grub.d/10_Linux ###

Note how the title line is changed in GRUB 2: Use menuentry instead, put the text in quotes, and start the boot entry with a left brace {, ending it with a right brace }. Instead of kernel, the word linux is used; initrd is the same. Instead of root=, in GRUB 2 it is set root= (in GRUB 2, root is a variable).

sudo grub does not get you a GRUB 2 shell at Konsole
In GRUB Legacy, the user may open a GRUB shell by typing sudo grub, and then use it to install/re-install GRUB (root-setup-quit) to a Master Boot Record or to a partition boot sector. In GRUB 2, there is no such option. Instead, the key command is the Konsole (BASH) command grub-install. At Konsole, as root, you will use sudo grub-install to install/re-install GRUB 2 to a Master Boot Record or to a partition boot sector.

Device names have changed. In GRUB Legacy, the numbering of both hard drives and partitions start at zero. (hd0,0) is the first hard drive (hd0), the first partition (partition zero). In GRUB 2, the numbering of hard drives also starts at zero: hd0 is the first hard drive. But partition numbering starts at 1: (hd0,1) is the first hard drive, the first partition (partition one).

In GRUB Legacy, we use the find command; e.g., grub>find /boot/grub/menu.lst. In GRUB 2, the search command replaces the find command: grub>search /boot/grub/grub.cfg.

In GRUB Legacy, the geometry command (at the grub> prompt) is very useful for listing devices as GRUB sees them on your PC. It is not used in GRUB 2. Instead the list command ls (at the grub> prompt) replaces the geometry command.

GRUB Legacy uses stages: stage_1, stage_1.5, and stage_2. Those are replaced in GRUB 2 by boot.img (a 512-byte file that corresponds to stage_1 and is installed to a MBR); there is no stage_1.5 in GRUB 2; and core.img in GRUB 2 takes the place of stage_2 (or, perhaps, of both stage 1.5 and stage_2). Details: See Section 4 the subsection "grub-install: A key command."


GRUB 2 Commands -- compared to GRUB Legacy
Comparison chart:
http://grub.enbug.org/CommandList
Key useful items to note:

GRUB Legacy <--> GRUB 2

find is replaced with search
geometry is gone and replaced by ls
kernel (in menu.lst) is replaced by linux (and other terms for different OSs)
title (in menu.lst) is replaced by menuentry (in grub.cfg)
root is still used but is now a variable
setup is gone; the work is done by grub-install
map is replaced by drivemap
device is replaced by loopback (makes a drive out of a file)
set is a GRUB 2 term used to set a variable

Notes about some of the new GRUB 2 commands: See Reply #1

= = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = =
SECTION 2 Key Facts About the Boot menu, grub.cfg

Quick version -- Overview -- Details
/etc/grub/default --> /etc/grub.d --> /boot/grub/grub.cfg
Rules for editing grub.cfg, /etc/default/grub, and the script files in /etc/grub.d
GRUB 2 device numbering is different: Partitions start at 1
Details

Quick version:
/etc/grub/default --> /etc/grub.d --> /boot/grub/grub.cfg
Rules:
-- The file /boot/grub/grub.cfg generates the boot menu.
-- Do not directly edit /boot/grub/grub.cfg.
-- You may edit (as root) /etc/default/grub.
(timeout, default OS, kernel options, resolution of the boot menu)
-- You may edit (as root) the scripts in /etc/grub.d.
-- Together, /etc/default/grub and the scripts in /etc/grub.d generate /boot/grub/grub.cfg.
-- To create a script, start with a text file as root: kdesudo kate
-- To make filename executable: sudo chmod 744 /etc/grub.d/filename
or, sudo chmod +x /etc/grub.d/filename
-- To remove execute permission from filename: sudo chmod -x /etc/grub.d/filename
-- To open Konqueror (Dolphin) as root: kdesudo konqueror
-- Generate a new configuration file /boot/grub/grub.cfg after editing /etc/default/grub and after editing, creating, or deleting scripts in /etc/grub.d, as follows:
sudo grub-mkconfig -o /boot/grub/grub.cfg

Examples of grub.cfg
http://svn.savannah.gnu.org/viewvc/t...ub&view=markup
Or: /usr/share/doc/grub-pc/examples/grub.cfg.
Also: http://grub.enbug.org/grub.cfg
Also: GRUB 2 Basics http://ubuntuforums.org/showthread.php?t=1195275


GRUB 2 device numbering is new: Partitions y start at 1
In GRUB 2 (as in GRUB Legacy), hard drives start at zero: hd0 is the first hard drive. In GRUB 2 (unlike GRUB Legacy), partition numbering starts at 1: (hd0,1) is the first partition in the first hard drive; (hd0,2) is the second partition in the first hard drive; (hd1,2) is the second partition in the second hard drive.

Linux device notation is the same as in GRUB Legacy
sda is the first hard drive; sdb is the second hard drive; sdc is the third; etc.
sda1 is the first partition of the first hard drive; sda2 is the second partition of the first hard drive; etc.


Details
The configuration file is called /boot/grub/grub.cfg, and it generates the boot menu you see on your screen when you boot your PC (and so, /boot/grub/grub.cfg can be called the boot menu configuration file). You are NOT supposed to edit it (it is read-only). It is generated from a folder of scripts called /etc/grub.d. Another key file is /etc/grub/default and it feeds default data to the scripts in /etc/grub.d. You may edit /etc/grub/default (as root). You may also edit the scripts in /etc/grub.d (as root). If you create a new file in /etc/grub.d, you must make it executable if you want the entry included in the configuration file grub.cfg. If you do not want a script to execute (and so remove that entry from grub.cfg), you must remove the execute bit (i.e., remove the execute permission).

>>> Key reminder:
Generate a new grub.cfg after changing anything in /etc/default/grub or /etc/grub.d by:
grub-mkconfig -o /boot/grub/grub.cfg


Experts: Editing grub.cfg
The file is read-only, so change permission to include Write:
sudo chmod +w /boot/grub/grub.cfg
Then do the edits as root and Save. When grub-mkconfig is run, the file returns to read-only (chmod 444 or 400), AND your edits may be overwritten (and therefore gone).
Optional: After editing, restore permissions to disallow writing:
sudo chmod -w /boot/grub/grub.cfg or
sudo chmod 444 /boot/grub/grub.cfg

The default settings file /etc/grub/default
This file feeds data to the scripts in /etc/grub.d. It contains the Default operating system, the Timeout, kernel options, resolution of the graphical boot menu, and other default settings. You may edit this file with root privileges.

The folder of scripts /etc/grub.d
These scripts generate /boot/grub/grub.cfg when the grub-mkconfig command is run (as root). The order of the entries in grub.cfg corresponds to the order of the files in /etc/grub.d, starting with 00_header, then 01_scriptname, etc., through all files starting with NN_ where NN is a 2-digit number and _ is the underscore (Shift+(minus sign)); then comes scripts whose names start with a letter (e.g., a_anotherscript).

You may edit the script files (as root) or create new ones. To create a new entry in grub.cfg, you simply create a new script file: a text file that you make executable (like a program). To remove an entry from grub.cfg, remove the execute permission from the corresponding script file in /etc/grub.d. (If the entry corresponds to a custom script you wrote, you may also delete that script file from /etc/grub.d).
See SECTION 4 Special Topics -- Create a custom boot entry.

Editing the script files in /etc/grub.d:
Do your work as root.
To make the file /etc/grub.d/filename executable:
sudo chmod 744 /etc/grub.d/filename
To remove the execute bit from the file filename:
sudo chmod -x /etc/grub.d/filename
When done, run
sudo grub-mkconfig -o /boot/grub/grub.cfg
to generate a new boot menu configuration file /boot/grub/grub.cfg.
GUI: How to set permissions
Open Konqueror or Dolphin as root (e.g., kdesudo konqueror).
Open the file.
Right-click > Properties > Permissions, Advanced Permissions

Tip: To open a file in /etc/grub.d (as root)
The files in /etc/grub.d are scripts. So, as root, if you click on one, it will want to execute or run like a program. Instead, to open a script for editing/viewing, right-click on the script file, Open With Kate or Kwrite. That opens the file as a text file. Now you can read it or edit it.
Details:
GUI, working as root: Open Konqueror (Dolphin) as root and work from there:
kdesudo konqueror
CLI, working as root: kdesudo kate /etc/grub.d/script_name


Quick reference
The (standard) files in /etc/grub.d (each is a script) are:
00_header
05_debian_theme: Set background, text colors, themes
10_hurd Locates Hurd kernels
10_linux Locates Linux kernels based on results of the lsb_release command.
The target are kernels located on the same partition as the root partition
of the current OS you are in (where this grub.cfg is located).
In contrast to: 30_os-prober (see below)
20_memtest86+: If the file /boot/memtest86+.bin exists, it is included in the boot menu.
30_os-prober: Searches for Linux and other OS's on all partitions; includes them in the boot menu.
40_custom: A template for adding custom boot menu entries.

See Appendix: permissions, working as root, making a file executable, Konsole, and other topics.


= = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = =
SECTION 3 Fixing Things
A checklist of things to try to fix a broken system
A Troubleshooting Outline
Ctrl+Alt+Del will reboot your PC
Super Grub Disk: Very Important
Key commands: grub-mkconfig and sudo grub-install
Timeout & Default OS, changing
Kernel options, changing
To see or to hide the boot menu
Missing OS entry in the boot menu
Editing the boot menu during booting: "e" key
The GRUB prompt grub> -- What to do with it
=> Getting information and booting an OS
Re-installing GRUB 2 using Live CD: A Key rescure method
Using a Live CD to edit files in your OS


Troubleshooting Outline

When you can't boot into your OS, there are two possible causes:
the boot menu is flawed, and/or
the GRUB 2 installation is flawed.

To fix it, you have two choices:
boot into the OS somehow and fix it;
or
fix it from outside the OS (e.g., live CD, another OS, or live flash drive).

Before looking at these two choices, note two important things:
> To fix the boot menu means to fix its configuration file /boot/grub/grub.cfg. You can sometimes do that temporarily using the edit-on-the-fly "e" key (see subsection below). To fix it permanently, you do NOT edit grub.cfg directly; but rather you edit the file /etc/default/grub and/or you edit the script(s) in /etc/grub.d, and then you use the command grub-mkconfig to generate a new grub.cfg.
> To fix the GRUB 2 installation, that usually means re-installing GRUB 2 using, at Konsole, the command grub-install. You can do this from inside the OS (if you can boot into it somehow), or from a Live Kubuntu CD or from another Linux OS on your hard drive. You cannot do it from the GRUB 2 prompt (grub>) when booting the PC. (In GRUB Legacy, you could do it by getting the grub> prompt and using the root and setup commands.)

Now let's look at each of your two choices for fixing the problem.

--> How to boot into your OS when you can't seem to boot into your OS:
(1) SGD, or (2) use the grub>, or (3) use the "e" key.
Some tips and details:

> Use Super Grub Disk to boot into it. You may have SGD fix the boot (under GNU/Linux options), or simply use SGD to boot the OS so you can get into it. If you use SGD to fix the boot, it will re-install GRUB to your drive, so make sure that's what you want; also, it may do so using either GRUB Legacy or GRUB 2, depending on the SGD CD version you are using. Of course, if you can get booted into the OS, then you can fix anything and everything, so maybe you won't be feeling too picky at this point.
Note: Along these lines, you can also use your own GRUB 2 disk/flashdrive to boot your OS, if you built one.

> Boot into your OS yourself, manually, using the GRUB 2 prompt, grub>, ASSUMING you can get the prompt! (Sometimes, you can't.) See the Subsection below titled "The GRUB prompt grub> -- What to do with it."

> Boot into your OS yourself by fixing the boot menu (editing it "on-the-fly" using the "e" key when you see it on the screen). But sometimes, you don't see the boot menu. See the Subsection below titled "Editing the boot menu during booting: 'e' key" If you are successful, since these "e" edits are only temporary, after booting into the OS, you must make the changes permanent (by editing /etc/default/grub or the script(s) in /etc/grub.d and then generate a new grub.cfg using grub-mkconfig -o /boot/grub/grub.cfg.


--> How to fix the problem from outside the OS:
(1) Use a Live CD, or (2) Fix it from another OS.
Some details:

> Use a Live CD.
From a Live Kubuntu CD (or most any live Linux CD), you can re-install GRUB and/or perform edits on files (/etc/default/grub or the script(s) in /etc/grub.d). See the subsections below: "Re-installing GRUB 2 using Live CD: Key Rescue Method" and "Using a Live CD to edit files in your OS."

> Fix the problem from another Linux OS, ASSUMING you are able to boot into one!
From there, you can edit files in your broken OS and/or re-install GRUB 2 using grub-install.

(NOTE: From the second OS, or even from a Live CD, you'd have to mount the broken OS partition; or perhaps looking in your file manager you'd see it is automatically mounted for you.)

[End of Troubleshooting Outline]


Ctrl+Alt+Del will reboot your PC
If your PC freezes up during the experiments/testing/troubleshooting of your bootloader, use Ctrl+Alt+Del to re-boot the PC. Be prepared to do something, though!
Examples of what to do:
-- Before using Ctrl+Alt+Del, put the Super Grub Disk CD in the CD tray so you can re-boot to it and rescue your OS.
-- Be prepared to press the key required to enter your BIOS setup. That will buy you some time, or give you a chance to change hard drive booting order, or put a live CD or SGD in the CD tray, or get your notes ready, etc.
-- If you have been getting a boot menu, let the PC reboot into it, then enter Edit mode (pressing the "e" key) or enter the GRUB 2 CLI (pressing the key "c"), then try to fix things from there.


Super Grub Disk: Very Important
Whether you think you need it or not, get it now, free, as a bootable CD which will get you booted into your operating system in case you can't. SGD can be downloaded here: http://www.supergrubdisk.org/ . Look for a CD ROM iso version, download it, burn it as an iso image to a CD (using K3b), test it briefly (by running it and stepping through a few menus but not choosing anything; then Quit; or, use it to boot into your OS).

Tip (using SGD to boot into your broken OS)
Choose GNU/Linux > Fix Boot, then select the broken partition.
Should you decide to simply Quit the SGD (without doing anything), do so, select reboot, enter your BIOS setup, remove the SGD CD, exit BIOS, and continue rebooting.


Key commands: sudo grub-mkconfig and sudo grub-install
Use these two commands to "freshen up" your GRUB 2 installation.
grub-mkconfig: builds a new boot menu configuration file boot/grub/grub.cfg.
grub-install: builds a complete, fresh GRUB 2 installation, including /boot/grub/grub.cfg.

grub-mkconfig
will generate a new boot menu /boot/grub/grub.cfg. To do so, it uses /etc/default/grub and the scripts in /etc/grub.d. You should run this command after editing the default file or the scripts:
sudo grub-mkconfig -o /boot/grub/grub.cfg
or
sudo grub-mkconfig --output= /boot/grub/grub.cfg
See Reply #1 (to this post): Notes about some of the new GRUB 2 commands

sudo grub-install [INSTALL_ DEVICE]
installs or re-installs GRUB 2 to INSTALL_DEVICE.

See SECTION 4: grub-install: A key command
For now, here's some highlights.

sudo grub-install /dev/sda
installs GRUB 2 to the Master Boot Record of drive sda. And
sudo grub-install /dev/sda1
installs GRUB 2 to the boot sector of the partition sda1.
In doing so, grub-install does a complete job of setting up everything.
Here's what it does: It builds the directory /boot/grub (if it doesn't already exit), copies GRUB 2 files to it from the "master" image directory /usr/lib/grub/i386-pc, probes your drives and devices and partition table, makes a new device.map, builds and installs boot.img (to MBR) and core.img, and builds /boot/grub/grub.cfg.

> Man page: (8)GRUB-INSTALL - Install GRUB on your drive.
http://grub.enbug.org/FranklinPiat/grub-install.manpage

Troubleshooting
-- After running grub-mkconfig, make sure that the line set default=(hdx,y) is correct (i.e., that the order of the menuentries did not change the default OS position).
-- sudo grub-install --recheck [INSTALL_DEVICE]
=> If you get an error running sudo grub-install, try it again with sudo grub-install --recheck [INSTALL_DEVICE].


Timeout and Default OS, changing
The timeout is the length of time in seconds before the (highlighted) default OS is automatically booted (if you do not intervene by touching a key). To change these values, open the file /etc/default/grub as root, make the changes, Save, exit, then generate a new /boot/grub/grub.cfg by running sudo grub-mkconfig -o /boot/grub/grub.cfg.

Opening /etc/default/grub as root
If your file manager supports it, open the file manager, navigate to /etc/default/grub, right-click on the file, Actions, Edit as Root. Otherwise:
Open the file manager as root and work from there:
kdesudo konqueror
kdesudo dolphin
Or, open the file as root using Kate or Kwrite:
kdesudo kate /etc/default/grub

Example
GRUB_DEFAULT=0
GRUB_TIMEOUT=5

GRUB_DEFAULT=0 selects boot entry #0 (i.e., the first entry) as the default OS to be booted automatically. Boot entries can be seen in your /boot/grub/grub.cfg file; they start with a line
menuentry "some descriptive text" {
and end with
}

Boot entries are counted from zero; so the first menuentry is boot entry #0, the second menuentry is boot entry #1, etc.

Troubleshooting Tip: Check default OS setting after grub-mkconfig
If you recently added/removed a boot entry (by editing a /etc/grub.d script) and ran grub-mkconfig to generate a new boot menu, you might have to check and edit the line "GRUB_DEFAULT= " (in /etc/default/grub) if the default sequence number changed.

(TO DO: Check also: sudo grub-set-default N.)


Kernel options, changing
To change these values, open the file /etc/default/grub as root, make the changes, Save, exit. (See Timeout and Default OS above for editing tips.) The line in /etc/default/grub looks like this (or similar):
GRUB_CMDLINE_LINUX="quiet splash"


To see or to hide the boot menu
Look for this line in the file /etc/default/grub:
# GRUB_HIDDEN_TIMEOUT=0

With the # sign present, you will see the boot menu upon booting your PC.
With the # removed, you will not see the boot menu.

For a detailed explanation of the other ways this works, see
GRUB 2 Basics drs305
http://ubuntuforums.org/showthread.php?t=1195275


Missing OS entry in the boot menu
If you run grub-mkconfig, and there is a missing entry in your boot menu, you can add that entry as a custom entry. See SECTION 4 below, Special Topics Boot menu: Create a custom boot entry.


Editing the boot menu during booting using the "e" key
When you boot/re-boot your PC, the boot menu appears. If you select an entry (an OS to boot into) and get an error, and if you are able to return to the boot menu (or re-boot again to get it), you may be able to fix things or to experiment with your boot menu to see if something will work. See the help tips at the bottom of the boot menu. At the boot menu, highlight an entry, press the "e" key, and you'll see the menuentry statements for that OS. See the help tips at the bottom of that menu. If you highlight a line, press the "e" key, that line will be displayed so you can edit it (using arrow keys, delete, etc.). Pressing ESC returns you to the previous screen.

The edits you make to the boot menu are "on-the-fly" edits and are not permanent. To make them permanent, you'll have to edit /etc/default/grub and/or the script files in /etc/grub.d, perhaps even making a custom boot entry if necessary (SECTION 4 Special Topics Boot menu: Create a custom boot entry), then generate a new /boot/grub/grub.cfg file using grub-mkconfig.


The GRUB prompt grub> -- What to do with it
=> Getting information and booting an OS

You may get the GRUB prompt grub> in three ways:

> "c" key: You re-boot and upon seeing the boot menu, press the "c" key to get the grub>. (Or Control+c at the Edit mode menu.) (By pressing the ESC key, you get back to the boot menu.)
Or:
> No boot menu! Perhaps, you re-booted your PC and didn't see any boot menu but instead got dropped to the GRUB 2 prompt: grub>.
Or:
> You get a grub> when re-booting using your own GRUB 2 flash drive (which is what is usually supposed to happen!).

From the grub> prompt, you may be able to issue commands to
help you gather information about your drives
or
boot your computer.

Use these resources:
SECTION 4 Special Topics, the subsection
"4 ways to boot an OS" -- direct booting configfile, symlinks, chainloader
SECTION 4 Special Topics, the subsection
"How to get information about your drives and devices"
=> In particular, take special note of the ls command and the use of TAB completion.

Example Booting using symlinks; and using the ls command

grub>
Use the ls command to see how GRUB 2 sees your drives and partitions:
grub>ls
From the output, you may decide to use ls again, this time listing files in certain directories.
For example, to investigate (hd0,8), you can list the files under the root directory of (hd0,8), like this:
grub>set root=(hd0,8)
grub>ls /
And then to see the kernel(s) under /boot,
grub>ls /boot
Or, if you do
grub>ls (hd0,8)
you'll get the filesystem type and UUID.
Another way to see what's under the root:
grub> ls (hd0,8)/
(note the slash, no spaces)

Suppose you see or confirm that the OS you want to boot is on (hd0,8) (= sda8).
Then, you might try to boot that OS using symlinks like this:
grub>set root=(hd0,8)
grub>linux /vmlinuz root=/dev/sda8 ro quiet splash
grub>initrd /initrd.img
grub>boot

But what if you can't remember the kernel options ro quiet splash ?
Then this way will also work:
grub>set root=(hd0,8)
grub>linux /vmlinuz root=/dev/sda8
grub>initrd /initrd.img
grub>boot

(The read-only option, ro, is important, but it is a default option if not specified directly. Thanks goes to dibl for this information.)

Example If you need to re-boot or shut down the PC
To reboot, get the GRUB 2 prompt by pressing "c" key, and then
grub>reboot
To shut down
grub>halt

Example Chainloader
Suppose you had previously installed GRUB 2 to the boot sector of the (hd0,8) partition containing your OS. (You would have done that using sudo grub-install /dev/sda8) Then you may boot that OS using chainloader as follows:

grub>set root=(hd0,8)
grub>chainloader +1
grub>boot

Or,
grub>chainloader (hd0,8)+1
grub>boot

(NOTE about using the boot command When booting at the grub> prompt, you must use the boot command to make it go. However, in the configuration file /boot/grub/grub.cfg, you do NOT need to use the boot command--it is implied there.)



Re-installing GRUB 2 using Live CD: Key Rescue Method

There are two main ways of doing this: By chrooting into the broken partition and by not chrooting. For the chrooting way, see GRUB 2 Live CD Install Guide: http://grub.enbug.org/Grub2LiveCdInstallGuide For details about chrooting, see the Appendix in the first post (above).
For "my" way, I'll call "Method 1," of re-installing GRUB2 from a live CD, read on.

Method 1: Installing or re-installing GRUB 2 using a Live CD

Your Kubuntu Live CD contains GRUB 2 files; specifically, in a live session, you will find the master GRUB 2 "image" files in /usr/lib/grub/i386-pc. Thus, they can be used to install or re-install GRUB 2. Here's how ...

Start your Kubuntu Live CD.
Choose the option to try Kubuntu without installing.
Open Konsole (Terminal): K-Menu > System > Konsole
Explore your partitions using
sudo fdisk -lu
Determine your root partition. In this example, ours is sda2.
Make a mount point (directory) for partition sda2:
sudo mkdir /media/sda2
Mount sda2 on the mount point:
sudo mount /dev/sda2 /media/sda2
Make a mount point (directory) for /dev:
sudo mkdir /media/dev
Mount the devices in your Live CD session:
sudo mount --bind /dev /media/dev
Install (or re-install) GRUB 2 (into the MBR of drive sda) using the GRUB 2 files in sda2:
sudo grub-install --root-directory=/media/sda2 /dev/sda

You may get this error:
grub-probe: error: Cannot find a GRUB drive for /dev/sda2. Check your device.map.
Auto-detection of a filesystem module failed.
Please specify the module with the option `--modules' explicitly.

If so, try this:
sudo grub-install --recheck --root-directory=/media/sda2 /dev/sda
Maybe you'll get lucky and see this:
Installation finished. No error reported.
This is the contents of the device map /media/sda2/boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
(hd0) /dev/sda

(=> and so this was successful)

Then, unmount both filesystems:
sudo umount /dev/sda2 /media/sda2
sudo umount /dev /media/dev
Leave Konsole:
exit
Test it:
Exit out of the Live CD, reboot, see if you fixed your booting problem (by booting into the broken partition).

[End of Method 1]
- - - - - - - - - -


Using a Live CD to edit files in your OS
This is done as you would normally do it. Of course, if you wish, you may use Super Grub Disk to boot into your OS and do the editing from there. Here is an outline of a standard way to use your Kubuntu Live CD.

Boot the Live Kubuntu CD, open Konsole, then as root make a directory, mount the filesystem containing the file you need to edit, open that file (possibly as root), edit it, save, quit, unmount the filesystem, exit.
Example
If the file you need to edit is called file_name and is on sdb3 (=(hd1,3)), start a Live CD Kubuntu session, open Konsole:
sudo fdisk -lu # to see/check your partitions, if necessary
Make a directory called /media/sdb3:
sudo mkdir /media/sdb3
Mount device sdb3 on directory /media/sdb3:
sudo mount /dev/sdb3 /media/sdb3
Change to that directory:
cd /media/sdb3
Then you may proceed in various ways:
Open Konqueror/Dolphin as root, then open the file_name:
in 8.10 or later: kdesudo konqueror (or dolphin)
in 8.04: kdesu konqueror (dolphin)
Make your edits, then File > Save, File > Quit.
Or, open file_name as root using Kate, then do the edits:
in 8.10 or later: kdesudo kate /path_to file_name
in 8.04: kdesu kate /path_to file_name
Make your edits, then File > Save, File > Quit
Unmount the directory; note the spelling of umount:
sudo umount /media/sdb3



= = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = =
SECTION 4
Special Topics
Installing GRUB 2 to your PC
grub-install The most useful command
The various types of command modes.
"c," grub>, Konsole BASH, edit "e", emu
TAB Completion
How to get information about your drives and devices
At Konsole : sudo fdisk -lu
At the GRUB 2 prompt: grub> ls
Boot menu: Adding or removing an OS entry
Boot menu: Create a custom boot entry
Boot menu: Making your own custom grub.cfg
4 ways to boot an OS: configfile, symlinks, direct booting, chainloader
Dedicated GRUB 2 partition: How to build it
GRUB 2 Flashdrive: How to build it
Use of the term "root"
GRUB's Root Device, the Linux statement: root=UUID=,
--root-directory=DIR INSTALL_DEVICE
Dual booting: How to set it up
Booting XP on a non-first hard drive: The drivemap command in GRUB 2

Cheat sheet: GRUB 2 Practical Reminders
- - - - -

Installing GRUB 2 To Your PC

To install GRUB 2 to your PC so it boots your PC into your OSs, two steps are required.

1 You need to get the GRUB 2 files installed to your PC, somewhere in the Kubuntu filesystem.
2 Then use those GRUB 2 files to install GRUB 2 to your PC's drives or devices so it can serve as a bootloader to boot your PC into your Kubuntu and your other OSs.

Step 1: Get the GRUB 2 files
Install the GRUB 2 package in your Kubuntu OS using your package manager. Or, at Konsole, issue the following command:
sudo apt-get install grub-pc

Check it: Open your file manager (Konqueror or Dolphin or other), and see the GRUB 2 files under
/usr/lib/grub/i386-pc (called the GRUB 2 image directory, and contains a set of "master" GRUB files).

Step 2: Install the GRUB 2 files so they serve as a bootloader
Suppose your first BIOS boot drive is sda (as seen in Kubuntu using at Konsole the command sudo fdisk -lu). Then, install GRUB 2 to the Master Boot Record of sda:
sudo grub-install /dev/sda

This also copies the GRUB 2 files into /boot/grub.
Then to generate a fresh boot menu configuration file (/boot/grub/grub.cfg), run
sudo grub-mkconfig -o /boot/grub/grub.cfg.

More Details About This

CAUTION, fair warning:
Have a bootable Super Grub Disk CD handy in case this messes up booting your PC.

To install GRUB 2 files to your PC, open Konsole and run the commands
sudo apt-get update
sudo apt-cache search grub-pc
(returns: grub-pc - GRand Unified Bootloader, version 2 (PC/BIOS version))
sudo apt-get install grub-pc
Then, install GRUB 2 to the Master Boot Record of your first BIOS boot drive. For example, if that MBR is sda, the command would be
sudo grub-install /dev/sda
And then update grub.cfg:
sudo grub-mkconfig -o /boot/grub/grub.cfg
Reboot to see what happens.
The old GRUB may also still be there (in which case you saw an entry on the boot menu to chainload into GRUB 2), in which case you may run
sudo update-from-grub-legacy
to replace GRUB Legacy with GRUB 2 IF YOU WISH TO DO SO.

Troubleshooting
Installing GRUB 2 to the MBR: using --recheck
Example
sudo grub-install /dev/sda
grub-probe: error: cannot find a GRUB drive for /dev/sda.
Auto-detection of a filesystem module failed.
Please specify the module with the option `--modules' explicitly.
So, try this:
sudo grub-install --recheck /dev/sda
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
(hd0) /dev/sda


- - - - -
[Start subsection]

grub-install The most useful command

Full form: grub-install [OPTION] INSTALL_DEVICE

Two very important options are
--recheck
Probe a device map even if it already exists
--root-directory=DIR
Install GRUB images under the directory DIR instead of the root directory
(See discussion below.)

Examples:
INSTALL_DEVICE may be /dev/sda, /dev/sda1, hd0, hd1, etc.
grub-install /dev/sda installs GRUB 2 to the MBR of drive sda.
grub-install /dev/sda1 installs GRUB 2 to the boot sector of partition sda1.
grub-install hd0 installs GRUB 2 to the MBR of drive hd0.
grub-install --root-directory=/media/sdb1 /dev/sda
sets up GRUB 2 files in the mounted partition /media/sdb1
and then installs GRUB 2 to the MBR of drive sda using /media/sdb1/boot/grub files.
(If there is no /boot/grub directory in sdb1, it will be created and filled with GRUB 2 files.)
grub-install --recheck --root-directory=/media/sdb1 /dev/sda
Do it again, and probe the /boot/grub/device.map (again).

Use the command sudo grub-install for these purposes:
to refresh the entire GRUB 2 installation; or when you are re-installing GRUB 2 to fix a problem; or when you are installing GRUB 2 to another place or to a dedicated GRUB 2 partition or to a USB (flash) drive.

A master script
grub-install is a master script, called a utility, that invokes many other utilities (scripts) to help do its work. You issue this command at Konsole (Terminal) as root (using sudo). It does everything for you; it's a master fix-it-all command.

/usr/lib/grub/i386-pc
The master set of GRUB 2 files in your OS are kept in the GRUB 2 image directory /usr/lib/grub/i386-pc. They get there when you install GRUB 2 to your PC (or OS) using your package manager or using (sudo) apt-get install grub-pc.

grub-install does the following for you:

> The command sudo grub-install copies the GRUB 2 files from /usr/lib/grub/i386-pc to the directory /boot/grub. If /boot/grub does not yet exist, it is created.
> It probes your partition type and partitions (using grub-probe).
> It builds a custom version of core.img for your setup, one of two very important files (along with boot.img). (In GRUB LEGACY terms,, boot.img corresponds to stage_1 and core.img to stage_2.)
> Finally it installs GRUB 2 to your PC so it can boot some OS(s) for you. (It uses grub-setup to do this, setting boot.img in the MBR of your first BIOS boot drive and installs core.img either after the MBR or to a file system (e.g., your OS partition boot sector). See the note below for a few details.)

Two useful options
--recheck
Probe a device map even if it already exists
--root-directory=DIR
Install GRUB images under the directory DIR instead of the root directory

--recheck
If your grub-install command fails, complaining about a filesystem or not finding something, try it again with the option --recheck; like this example:
sudo grub-install --recheck --root-directory=/media/sdb1 /dev/sda

--root-directory=DIR
Very useful. Instead of setting up your GRUB files in /boot/grub under the root directory of your OS, you can use this option to build a /boot/grub directory anywhere, and then use those GRUB 2 files to install GRUB 2 to a hard drive MBR, or to a partition boot sector, or elsewhere (e.g., USB drive or dedicated GRUB 2 partition).
DIR is a directory, and so it is mounted. Thus, if using partition sdb1, for example, you must mount it, as say, /media/sdb1, and then it would be: --root-directory=/media/sdb1.

Dedicated GRUB 2 partition
Suppose your OS is on some partition on one of your hard drives. And suppose you wish to build a dedicated GRUB 2 partition in sdb1, and that your first BIOS boot drive is sda, and that you wish to setup GRUB 2 files in sdb1 and use those to install GRUB to the MBR of sda. Here's the command:
sudo grub-install --root-directory=/media/sdb1 /dev/sda
Note that sdb1 is mounted as /media/sdb1; also that sda is specified as a device: /dev/sda (not just sda).
See the subsection below titled "Dedicated GRUB 2 partition: How to build it"

USB flash drive
Suppose your flash drive is seen in Kubuntu as /dev/sdc and it is mounted as /media/flashdrive. Then the command to setup and install GRUB 2 to it is:
sudo grub-install --root-directory=/media/flashdrive /dev/sdc
See the subsection below titled "GRUB 2 Flashdrive: How to build it"

More details at:
grub-install
http://grub.enbug.org/FranklinPiat/grub-install.manpage
grub-setup (You will probably never use this by itself; you will use grub-install and let it do the work for you.)
http://grub.enbug.org/FranklinPiat/grub-setup.manpage

A few details about installing boot.img and core.img
GRUB Legacy uses stages: stage_1, stage_1.5, and stage_2. Those are replaced in GRUB 2 by boot.img (a 512-byte file that corresponds to stage_1 and is installed to a MBR); there is no stage_1.5 in GRUB 2; and core.img in GRUB 2 takes the place of stage_2 (or, perhaps, of both stage 1.5 and stage_2); it is built specific to your PC setup. The boot.img points at core.img; core.img is embedded in some fixed location (on a disk), but usually that location is in the same "cylinder" as the MBR that contains boot.img. (Details: the MBR goes into sector 1 and is 512 bytes, and that's where boot.img goes. This first cylinder has 63 sectors, so that leaves 62 sectors or 31,744 bytes (=62*512) where core.img may be embedded. This first cylinder (of 63 sectors containing boot.img and core.img) precedes the start of the first partition on that disk, which would start at sector 63 (counting of sectors (in LBA) starts at zero, so 63 sectors take us to the end of sector 62 = the start of sector 63). You will see this if you run as root fdisk -lu.)

[End of subsection: grub-install The most useful command]
- - - - -


The various types of command modes
"c," grub>, Konsole BASH, edit "e", emu

When working with GRUB, you must work with root privileges and so you must use sudo and kdesudo. For example, sudo grub-install /dev/sda, kdesudo konqueror, etc.
The command modes you may use in GRUB 2 are the following.
-- Konsole (BASH), in Kubuntu, at your regular prompt (as root), ~#:
-- GRUB 2 emu (from Konsole, issue sudo grub-emu [OPTION]; this gives you a grub> prompt)
=>TODO: More on this later.
-- GRUB 2 command line interface (CLI), grub>.
When you re-boot your PC, get the boot menu, and press the "c" key, you get a GRUB 2 prompt, grub>. That is the GRUB 2 CLI. You will also get "grub>" upon re-booting if you don't have a boot menu, grub.cfg, or if your boot menu is broken. (See SECTION 3, the subsection titled "The GRUB prompt grub> -- What to do with it")
-- Edit mode. Editing on the fly: when you re-boot and see your GRUB 2 boot menu, you can use the "e" key to edit your boot menu on a temporary basis (the edits are not permanent unless you later make them so). (See SECTION 3 -- Editing the boot menu during booting: "e" key.)

=> In all cases, help is nearby, and the commands are generally the same (or nearly so) in all modes, with a few differences.

Help
Konsole BASH CLI:
Appending --help to a command in CLI; for example: grub-mkconfig --help.
GRUB CLI (grub>):
At the GRUB 2 prompt simply type help and press Enter.
To get help with a command, type help <command name>.
Example: grub>help ls tells you about the command ls.
Edit mode:
The key tips are at the bottom of the screen after your press "e"
to enter the edit mode from your on-screen boot menu.
Also, at that point, you can press Control+c to get a grub>,
then type help and/or use TAB completion.

TAB completion (grub>)
While typing after the grub>, try pressing the TAB key and see what happens: in many cases, GRUB will try to help you complete the line with something meaningful or with choices. So type as much as you can recall or type a guess, then press TAB, then you may have to type another guess and press TAB again, and so on until you complete the line the way you want it.

GRUB 2 device numbering is different
(hdx,y): hard drive x, partition y
Hard drives start at zero (x=0), same as for GRUB Legacy.
Partitions start at 1 (y=1); in GRUB Legacy, partitions start at zero.


- - - - -
How to get information about your drives, devices, and files
Key: at Konsole sudo fdisk -lu; and grub> ls
We'll look at two cases: At the command line in Kubuntu (Konsole); and at the grub> prompt.

Konsole (BASH) command line

Exploring your hard drive(s): sudo fdisk -lu
=> sudo fdisk -lu is very useful, very important.
GRUB version number: grub-install -v
Drive space: df -h -T
UUIDs (see NOTE below):
blkid (or try sudo blkid); also:
ls /dev/disk/by-uuid/ -alh
grub.cfg, to see it: cat /boot/grub/grub.cfg
fstab (filesystem table), to see it: cat /etc/fstab
Mounting, how filesystems are mounted: cat /etc/mtab or: mount
Boot directory /boot, to find it: df /boot
Kernel version and gcc version (gcc=the GNU compiler used to build the kernel):
cat /proc/version
Kernel version: uname -r
Linux version/name: lsb_release -a
(hold the Shift key and the minus sign key to get _ . LSB = Linux Standard Base)
KDE version (KDE=K Desktop Environment)
for KDE 3.5: kde-config –version and for KDE 4: kde4-config --version

NOTE: UUID = Universally Unique Identifier
Starting with Kubuntu version 8.10, UUIDs are used to identify partitions. A UUID is a 16-byte number (= 128 bits). In canonical form, a UUID consists of 32 hexidecimal digits, displayed in 5 groups separated by hyphens.

At a GRUB prompt, grub>

Exploring your hard drive(s): grub> ls
=> Very useful, very important.
(in GRUB Legacy, the geometry command is used instead of ls)

The ls command is very useful
grub>ls
gives you a list of your hard drives and partitions as GRUB sees them, in (hdx,y) GRUB 2 device notation.
grub>ls /
shows you the files under the current GRUB 2 root device. You can set that device using set root=. For example:
grub>set root=(hd0,8)
grub>ls /
shows you all files under root. Or: grub>ls (hd0,8)/ .
grub>ls /boot
shows you all files--including kernels--under /boot.

UUIDs and filesystem type
grub>ls (hd0,8)
shows you information about the partition (hd0,8) including its filesystem type and its UUID.

The contents of a directory: grub>ls -l /directory
Example
grub>ls -l /boot
shows you the kernel and initrd files.
(The option -l indicates "long form" and gives more information. To see all files, including hidden files, use the option -a: grub>ls -a -l /boot; or grub>ls -al /boot)

GRUB 2 emulation sudo grub-emu
At Konsole, to get a grub> prompt, type sudo grub-emu.
To exit emu and return to Konsole, type exit.
>>> IMPORTANT sudo grub-emu and then grub>ls
While you are working at Konsole in Kubuntu, you may need to know how GRUB sees your drives and partitions, the (hdx,y)'s. You can switch into emulation made (sudo grub-emu)) and issue the list (ls) command at the GRUB prompt (grub>ls) to see your drives and GRUB devices. Type exit to return to BASH mode in Konsole.

Using search and cat
GRUB files, what partitions they are in: grub>search /boot/grub/boot.img
Boot menu, what partition(s) it is in: grub>search /boot/grub/grub.cfg
Kernel, where it is: grub>search /vmlinuz
Boot menu, to see it: grub>cat (hdx,y)/boot/grub/grub.cfg
fstab, to see it: grub>cat (hdx,y)/etc/fstab
Device.map, to see it: grub>cat (hdx,y)/boot/grub/device.map

(NOTE: In GRUB Legacy, the find command is used instead of search.)

Restart (reboot), or shutdown (halt) your PC at a command line
At Konsole:
sudo shutdown -r now (re-boots the PC)
sudo shutdown -h now (shuts down the PC)
In GRUB:
grub>reboot (re-boots the PC)
grub>halt (shuts down the PC)
- - - - -


Boot menu: Adding or removing an OS entry to grub.cfg
Rule: You do NOT edit grub.cfg directly. Instead, you work with script files in the folder /etc/grub.d or with settings in /etc/default/grub.

-- Linux operating systems, added automatically
Look at your grub.cfg. The section
### BEGIN /etc/grub.d/10_linux ###
### END /etc/grub.d/10_linux ###
contains Linux operating systems that were automatically detected by GRUB 2 using the script file /etc/grub.d/10_linux. Most of your Linux OSs should be detected this way and included in the boot menu grub.cfg. If not, you can create a custom boot entry (see below, "Boot menu: Create a custom boot entry").

-- Windows and other OSs added automatically
This is done by the script /etc/grub.d/30_os-prober.

-- Adding or removing OSs from your PC. After doing so,
generate a new grub.cfg: sudo grub-mkconfig -o /boot/grub/grub.cfg.

-- Add a boot menu entry by making your own custom boot entry, then run:
sudo grub-mkconfig -o /boot/grub/grub.cfg
to generate a new grub.cfg.
(See subsection below: "Boot menu: Create a custom boot entry")

-- Removing a boot entry from grub.cfg:
Two choices.
(1) Simply remove the execute bit from the script file in /etc/grub.d that corresponds to (i.e., generates) the boot entry.
Example: If that file is named 43_MyOS-1, then run the Konsole commands
sudo chmod -x /etc/grub.d/43_MyOS-1
sudo grub-mkconfig -o /boot/grub/grub.cfg
(2) Or, remove the script file (for the boot entry) from the folder /etc/grub.d. Then run
sudo grub-mkconfig -o /boot/grub/grub.cfg to generate the new grub.cfg file.
NOTE: If a custom file contains more than one boot entry, you may remove any number of them, leaving the rest. Then use grub-mkconfig to generate your new boot menu, grub.cfg.


Boot menu: Custom boot entry
This is easy, usually.
-- There are 4 ways to make a boot entry (see "4 Ways To Boot an OS").
-- There is a custom template at /etc/grub.d/40_custom.
-- After you write the script file for your custom boot entry, make it executable.
-- Then generate a new grub.cfg by running sudo grub-mkconfig -o /boot/grub/grub.cfg.

Troubleshooting: Sometimes when you run grub-install or grub-mkconfig, it will fail to detect one of your OSs and excludes it from the boot menu grub.cfg. In that case, you could make a custom entry for it (as a script file in /etc/grub.d).

Direct booting To get a model for some of the entries, you have two choices: (1) Get it from your old boot menu (/boot/grub/menu.lst) from GRUB Legacy (if that is available on your PC). Or, it may also be here, made by GRUB 2: menu.lst_backup_by_grub2_postinst. (2) Go into the operating system itself (the one you wish to include), or perhaps access its filesystem using a live CD, and get the information from its own boot menu.

Example
Making a custom entry for sidux. Method: Direct booting.
It helps if you have a model for some of the entries. In the old boot menu (/boot/grub/menu.lst) from my GRUB Legacy, I had this boot entry for sidux:

title Debian GNU/Linux, sidux kernel 2.6.28-5.slh.3-sidux-686
root (hd0,2)
kernel /boot/vmlinuz-2.6.28-5.slh.3-sidux-686 root=UUID=306d94a5-107b-4c9e-ae03-a159e18dc1c7 ro quiet vga=791
initrd /boot/initrd.img-2.6.28-5.slh.3-sidux-686

Using a template (e.g., /etc/grub.d/40_custom), create an executable file for the sidux boot entry:
Open an empty text document (as root)
kdesudo kate
Save the new file as, say, /etc/grub.d/41_sidux_sda3
Copy the kernel & initrd lines from menu.lst, change “kernel” to “linux,” adjust the sidux partition number to conform to GRUB 2 convention:
Legacy GRUB: (hd0,2)
GRUB 2: (hd0,3)
Also, double check the UUID for sda3 by running sudo blkid.
Result:
The file /etc/grub.d/41_sidux_sda3 looks like this:

#!/bin/sh

echo "Adding sidux" >&2
cat << EOF
menuentry "sidux on sda3" {
set root=(hd0,3)
linux /boot/vmlinuz-2.6.28-5.slh.3-sidux-686 root=UUID=306d94a5-107b-4c9e-ae03
a159e18dc1c7 ro quiet vga=791
initrd /boot/initrd.img-2.6.28-5.slh.3-sidux-686
}
EOF

The echo statement causes a line to be printed to the screen after executing grub-mkconfig that says “sidux on sda3” so you can see it got done (i.e., that sidux got incorporated into the grub.cfg).

Make the file executable (it is a script, a type of program):
sudo chmod 744 /etc/grub.d/ 41_sidux_sda3
Or,
sudo chmod +x /etc/grub.d/ 41_sidux_sda3
Or, in GUI,
As root, open Konqueror (kdesudo konqueror), access /etc/grub.d, right click on 41_sidux_sda3, Properties, and check the “Executable” box; check Advanced Permission while you are at it.

To incorporate the sidux file 41_sidux_sda3 as a boot entry in the boot menu configuration file /boot/grub/grub.cfg, run
sudo grub-mkconfig -o /boot/grub/grub.cfg
Check that sidux is in your boot menu by opening /boot/grub/grub.cfg.


Boot menu: Making your own custom grub.cfg
This is easy. (For another example, see the subsection below "Dedicated GRUB 2 partition: How to build it.")
Taken directly from drs305 excellent, detailed guide, GRUB 2 Basics:
http://ubuntuforums.org/showthread.php?t=1195275

Building a Totally Customized Menu: Ok, admit you are a control freak and you want to see only what you build yourself - customized titles, no "memtest86+" and no extra kernels. Here is how you do it:
-- Run sudo update-grub [or use grub-mkconfig] to get the current available kernels.
-- Copy the desired "menuentry" listings from /boot/grub/grub.cfg to /etc/grub.d/40_custom The entry begins with the line starting with "menuentry" and ends with a line containing "}".
-- Add any other "menuentry" items you wish to see on the boot menu.
-- Edit the titles of the "menuentry" line if desired (between the quotation symbols). Do not change the lines following the "menuentry" line. Each entry should start with a "menuentry" line and end with a "}" on the last line.
-- Remove the executable bit from /etc/grub.d/10_linux, /etc/grub.d/20_memtest86+ and /etc/grub.d/30_os-prober
Removing the executable bit from any file in /etc/grub.d will exclude the file from being included in GRUB updates. To do it:
sudo chmod -x /etc/grub.d/grub.d/10_linux /etc/grub.d/20_memtest86+ /etc/grub.d/30_os-prober
-- Run "sudo update-grub" [sudo grub-mkconfig -o /boot/grub/grub.cfg]
-- The updated /boot/grub/grub.cfg file should now contain only sections for "00_header", "05_debian_theme" and "40_custom".
-- The grub.cfg file will not be updated with the addition of a new kernel. To add a new kernel, make
"10_linux" executable, run "sudo update-grub" [sudo grub-mkconfig -o /boot/grub/grub.cfg] to refresh the available kernels, and repeat these instructions.


4 Ways To Boot an OS
configfile, symlinks, direct booting, chainloader

You can use these methods
-- in a boot menu
-- at a grub> prompt (at the GRUB CLI)
to boot OSs. If you use them at the GRUB CLI, you must type the command boot at the end to make the methods symlinks, direct booting and chainloader work. You do not need the command boot in a configfile menu. You do not need the boot command in grub.cfg (it is implied there).

NOTE: These are done the same as in GRUB Legacy but with a new format.
But see the note on configfile below.

NOTE: Each boot entry starts with a line
menuentry "...some text..." {
and ends with
}

>>> Configfile booting
This is easy and flexible; however, there's a caveat:
Both OSs must use the same version of GRUB--both the OS you are working in (where the main boot menu is kept) and the OS you are booting.

For example, consider these two statements in a menuentry:
set root=(hd1,2)
configfile /boot/grub/grub.cfg

An equivalent way of doing it is this:
configfile (hd1,2)/boot/grub/grub.cfg

That tells your GRUB 2 to access partition (hd1,2), find the file /boot/grub/grub.cfg, show you that file so you can make a choice of which OS to boot, then boot the OS you choose. The GRUB doing the work is your native GRUB, the one you are using, not the GRUB in (hd1,2). Your native GRUB must be able to interpret the commands it finds in the grub.cfg of the OS you wish to boot.

When to avoid configfile
When there is a mixture of GRUB versions on your PC, it is best to avoid using configfile.
Instead, use chainloader or symlinks.

Example (Taken from a grub.cfg. The # sign indicates a comment.)

# Kubuntu 8.04.3 on sdb2, by configfile
menuentry “Kubuntu 8.04.3 on sdb2, by configfile” {
set root=(hd1,2)
configfile /boot/grub/grub.cfg
}


>>> Symlinks used in a boot entry
Symlinks are like shortcuts, and they direct control from the link to the file they point at. Symlinks for the kernel and initrd files are already set up for you. Look for yourself. List all files (-a) in long or detailed form (-l) under your root partition (/) by issuing the following command at Konsole:

ls -a -l /
lrwxrwxrwx 1 root root 33 2009-08-02 11:01 initrd.img -> boot/initrd.img-2.6.24-24-generic
lrwxrwxrwx 1 root root 33 2009-04-19 17:14 initrd.img.old -> boot/initrd.img-2.6.24-23-generic
lrwxrwxrwx 1 root root 30 2009-08-02 11:01 vmlinuz -> boot/vmlinuz-2.6.24-2 4-generic
lrwxrwxrwx 1 root root 30 2009-04-19 17:14 vmlinuz.old -> boot/vmlinuz-2.6.24-23-generic

The symlink for the kernel is vmlinuz, and vmlinuz points at the NEWEST kernel.
The symlink for the initrd is initrd.img, and initrd.img points at the NEWEST initrd.

NOTE: The "l" at the left indicates "link." Note how the links point at their target files following the symbol ->. Note that the symlinks are stored in your OS at the root level.

NOTE: If you wish to make a boot entry for the older kernel and initrd, you must use the symlinks for them, vmlinuz.old and initrd.img.old.

If you use direct booting, you have to write out the exact kernel and initrd names:
linux /boot/vmlinuz-2.6.24-24-generic root=UUID= vb687f89-ggjd-6ach-7755-77241i4b4fk3 ro quiet splash
initrd /boot/initrd.img-2.6.24-24-generic

With symlinks, vmlinuz starts at root and points at vmlinuz-2.6.24-24-generic and initrd.img starts at root and points at initrd.img-2.6.24-24-generic, so you can write more simply,
linux /vmlinuz root=UUID= vb687f89-ggjd-6ach-7755-77241i4b4fk3 ro quiet splash
initrd /initrd.img

However, to simplify this when you are in an emergency trying to boot at the GRUB prompt (grub>), do it this way:
Suppose this OS is Kubuntu 9.10 in (hd0,8) = sda8. Then you'd have

menuentry “Kubuntu 9.10 on sda8, by symlinks” {
set root=(hd0,8)
linux /vmlinuz root=/dev/sda8 ro quiet splash
initrd /initrd.img
}

or even simpler, when you can't remember the kernel options "ro quiet splash":

menuentry “Kubuntu 9.10 on sda8, by symlinks” {
set root=(hd0,8)
linux /vmlinuz root=/dev/sda8
initrd /initrd.img
}

(ro = Read-Only and is the default. Thanks to dibl for this information.)

NOTE about the paths
Notice the paths to the symlinks start at root / (since the symlinks are stored under root /); whereas the paths to the actual kernel & initrd files start at /boot (since the kernel and initrd are stored under /boot)

Another Example

# Kubuntu 9.10 on sdb7 symlinks, normal mode
menuentry “Kubuntu 9.10 on sdb7, by symlinks” {
set root=(hd1,7)
linux /vmlinuz root=/dev/sdb7 ro quiet splash
initrd /initrd.img
}

This is normal mode. If you want recovery mode (single user),
replace the kernel options “ro quiet splash” with “ro single” (without quotes)


>>> Direct booting
In direct booting, you use the actual kernel and initrd file names in the boot menuentry.
NOTE
If you use direct booting at the GRUB CLI, ie., at grub> prompt, you may use TAB completion to make your job easier.
For example,
grub>linux /boot/<Press TAB key now>
and you will get some choices, such as vmlinuz-2.6.24-24-generic

Example

# Kubuntu 8.04 on sdb3, direct booting
menuentry "Kubuntu 8.04 on sdb3, direct booting" {
set root=(hd1,3)
linux /boot/vmlinuz-2.6.24-24-generic root=UUID=db287e84-cbdd-4ca1-8745-85241a3b3fe2 ro quiet splash
initrd /boot/initrd.img-2.6.24-24-generic
}


>>> Chainloader booting
When you boot an OS by chainloading, you use the chainloader command to pass control of the booting from your native GRUB to some other bootloader located in the MBR of a disk somewhere or in the
boot sector of a partition.

NOTE: For this to work, a bootloader must first be installed to the target MBR or a partition boot sector.

A Linux example

menuentry “Kubuntu 9.10 on sdb7, by chainloader” {
set root=(hd1,7)
chainloader +1
}

"chainloader +1" says to go to sector 1 (of (hd1,7)) and turn control over to the bootloader found there.

For this example to work, a bootloader (e.g., GRUB 2) must be installed to the partition (hd1,7).
To install GRUB 2 to the boot sector of partition sdb7 (=(hd1,7)):
sudo grub-install /dev/sdb7

This is another way to write the same boot entry:
menuentry “Kubuntu 9.10 on sdb7, by chainloader” {
chainloader (hd1,7)+1
}

Another Linux example

menuentry “Drive sdc = hd2 by chainloader” {
chainloader (hd2)+1
}

If a bootloader (e.g., GRUB 2) has been installed to the Master Boot Record of drive sdc (= hd2), the menuentry will boot that hard drive by turning control over to the bootloader in its MBR.

For this example to work, a bootloader (e.g., GRUB 2) must be installed to the Master Boot Record of drive sdc (= hd2). To install GRUB 2 to the Master Boot Record of drive sdc:
sudo grub-install /dev/sdc

Example

Windows XP on sda1
menuentry “Windows XP on sda1, by chainloader” {
set root=(hd0,1)
chainloader +1
}



Dedicated GRUB 2 Partition: How To Build It
Again, this is straightforward, much easier than in GRUB Legacy.

1 Create the GRUB 2 partition.
Create a partition to be used as your dedicated GRUB 2 partition and format it. I use GParted Live CD to do this. At that time, you may if you wish, again using GParted, set a Label on your partition; e.g., “GRUB2” (without the quotation marks) (in GParted, use Partition > Labels).
(Check the size of the /boot/grub folder to determine how big to make the partition. GRUB 2 files use just 572 KB (96 files, including 12 old ones) on my installation.)

2 Create grub.cfg.
In your home directory, create a text file called grub.cfg and build your custom boot menu for the dedicated GRUB 2 partition. (For a sample, see below.)
(To create the text file, two ways: (1) Right-click on your Desktop, Create New > Text File; or (2) open text editor Kate to an empty document by typing at Konsole kate and save it under the name grub.cfg in your home directory only! To do this as root, use kdesudo kate, but that is not necessary at this point.)
Caution: You may want to completely build your boot menu now and have it ready to go. To make your boot entries in your grub.cfg, see the subsection above "4 Ways To Boot an OS."

3 Install GRUB 2 to the MBR.
From your Kubuntu OS, install GRUB 2 to the Master Boot Record (of your first BIOS boot drive) using GRUB 2 files set up in your dedicated GRUB 2 partition.
Example
Suppose sdb1 is your dedicated GRUB 2 partition, and assume it is mounted as /media/sdb1 (or, if you set the label GRUB2 on sdb1, this might be /media/GRUB2). And suppose you wish to install GRUB 2 to the MBR of sda which is set in BIOS to be your first boot drive.
Do it this way:
sudo grub-install –root-directory=/media/sdb1 /dev/sda
See: http://grub.enbug.org/FranklinPiat/grub-install.manpage
(That will also build the directory /boot/grub for you in your GRUB 2 partition.)

4 As root, copy your grub.cfg from your home directory to the GRUB 2 partition under the folder /boot/grub. (To do this in GUI, open your file manager as root and work from there; e.g., kdesudo konqueror or kdesudo dolphin.)

5 Set the boot flag on your dedicated GRUB 2 partition and re-boot to test it.

Set the boot flag on the dedicated GRUB 2 partition:
Do that using GParted either from your OS (K > System > Partition editor) or from the GParted Live CD. If you do it using the GParted Live CD, you might go this way now:
After completing Step 4 (copying the grub.cfg file into the partition), put the GParted Live CD in the CD tray, let it be recognized, re-boot into GParted Live, set the boot flag on your dedicated GRUB 2 partition (Partition > Manage Flags), GParted > Quit, then double click GParted (large menu at top) to quit and re-boot, when prompted remove the GParted Live CD, and let the PC re-boot (and it will now be using your dedicated GRUB 2 partition), and see if it works.

CAUTION: Remember to keep Super Grub Disk live CD handy.

IMPORTANT NOTE ABOUT KERNEL UPDATES:
Using this method of building a dedicated GRUB 2 partition, YOU are in charge of the boot configuration file /boot/grub/grub.cfg that is located in the GRUB 2 partition. The stuff we talked about above--/etc/default/grub and the scripts /etc/grub.d and grub-mkconfig--does not apply. You must keep these two "shows" separate. Edit the dedicated GRUB 2 file grub.cfg manually. If there ever is a problem, you may have to manually re-install GRUB 2 to the MBR (of the first BIOS boot drive) from the dedicated GRUB 2 partition.

Example Here's my dedicated GRUB 2 /boot/grub/grub.cfg:

# grub.cfg
# This is my custom boot menu, called /boot/grub/grub.cfg, located in my dedicated Grub 2 partition sda1.

# Set the timeout
set timeout=10

# Set the default boot entry.
set default=0

# Kubuntu 9.10 on sda8 by chainload
menuentry "Kubuntu 9.10 on sda8, by chainload" {
chainloader (hd0,8)+1
}

# Kubuntu 9.10 on sda8 by configfile
menuentry "Kubuntu 9.10 on sda8, by configfile" {
configfile (hd0,8)/boot/grub/cfg
}

# Kubuntu 9.10 on sda8 by symlink
menuentry "Kubuntu 9.10 on sda8, by symlink" {
set root=(hd0,8)
linux /vmlinuz root=/dev/sda8 ro quiet splash
initrd /initrd.img
}

# Kubuntu 8.04.3 on sda2, by configfile
menuentry "Kubuntu 8.04.3 on sda2, by configfile" {
configfile (hd0,2)/boot/grub.cfg
}

# sidux on sda3, by direct booting
menuentry "sidux on sda3" {
set root=(hd0,3)
linux /boot/vmlinuz-2.6.28-5.slh.3-sidux-686 root=UUID=306d94a5-107b-4c9e-ae03-a159e18dc1c7 ro quiet vga=791
initrd /boot/initrd.img-2.6.28-5.slh.3-sidux-686
}



GRUB 2 Flashdrive (USB flash drive)

For the principles of installing GRUB 2, see the discussion under "Installing GRUB 2" and "The grub-install Command."

Example

I used a 1 GB Kingston; the GRUB 2 files used just 51 MB.
Partition and format the flash drive as ext2 (using GParted Partition Editor). (You could also use FAT32 or ext3 or some other filesystem.)
Set the boot flag on the newly created partition (use GParted to do that: Partition > Manage Flags).
Exit GParted. Unplug the flashdrive, then plug it in.

In Kubuntu, to see how it is named, at Konsole run
sudo fdisk -lu
Output:
Disk /dev/sdb: 1031 MB, 1031798784 bytes
255 heads, 63 sectors/track, 125 cylinders, total 2015232 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x000f0fe1
Device Boot Start End Blocks Id System
/dev/sdb1 63 2008124 1004031 83 Linux

Konqueror (or Dolphin) indicated it is mounted as /media/disk.

=> So it is seen as sdb with the partition sdb1 mounted as /media/disk.

Install GRUB 2 to the flash drive. At Konsole:
sudo grub-install --root-directory=/media/disk /dev/sdb
Output:
Installation finished. No error reported.
This is the contents of the device map /media/disk/boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
(hd0) /dev/sda
(hd1) /dev/sdb

(This is the device.map on the flash drive, /boot/grub/device.map. I will ignore this! Doesn't matter too much. You could edit it as root to read
(hd0) /dev/sda
as seen from the point of view of the flash drive when it is used as a boot drive.)
Let's move on, now ...

Check to see that /boot/grub is created and filled with GRUB 2 files.
Reboot, setting BIOS to boot from the flash drive (USB booting).
The next thing I saw on the screen was:
grub>

I used the GRUB 2 command ls to see my drives and partitions (on the PC):
grub>ls

Since the PC booted from the flash drive, it was seen as hd0 with partition (hd0,1). (The drive that the PC actually boots from is always seen during its booting session as hd0--this is a general fact.)

My regular HDD, normally seen as hd0 was now seen as hd1 and my Kubuntu 9.10 was in (hd1,8).
So, to boot into Kubuntu, I did
grub>chainloader (hd1,8)+1
grub>boot
NOTE:
Previously I had already installed GRUB 2 to the partition boot sector of Kubuntu in case I ever needed to chainload into it. (I used at Konsole in Kubuntu, sudo grub-install /dev/sda8, where sda8 is my Kubuntu partition when there is no other drive attached to the PC.) Had I not already done this, I could could NOT chainload into Kubuntu and would have to boot into Kubuntu in some other way, for example using symlinks:
grub>ls
would show me that Kubuntu is on (hd1,8) when booting from my GRUB 2 flash drive, and so to boot it, I'd do:
grub>set root=(hd1,8)
grub>linux /vmlinuz root=/dev/sda8
grub>initrd /initrd.img
grub>boot
Or, you could do this (if you remembered how!):
grub>set root=(hd1,8)
grub>linux /vmlinuz root=/dev/sda8 ro quite splash
grub>initrd /initrd.img
grub>boot

Thus, I booted into Kubuntu using the GRUB 2 flash drive.

Building a boot menu for the flash drive:
You can create a text file /boot/grub/grub.cfg for the flash drive exactly as demonstrated under building a Dedicated GRUB 2 Partition.

Technical Note: To do so, you will probably have to work as root, say by opening Konqueror or Dolphin as root (kdesudo konqueror), or by opening Kate as root (kdesudo kate). However, you do not necessarily need a grub.cfg on the flash drive. You can simply use it as I did to explore your drives and then boot into an OS. If you do build a grub.cfg for it, you might include the OS(s) on your hard drive(s), and use the GRUB 2 flash drive to boot in emergencies, as you would use Super Grub Disk. Just remember that from the point of view of the grub.cfg on your flash drive, the other drives in your PC are shifted by 1 since upon booting the flash drive, it will be seen as hd0. If adrian15 builds Super Grub Disk for GRUB 2 and includes his usbshift function, then the story changes--for the principle of "USB drive shifting," see my how on building a GRUB flash drive:
-- How To Make GRUB Thumb Drive
http://kubuntuforums.net/forums/inde...opic=3081748.0

[End of the flashdrive subsection]



Use of the Term "root"
GRUB's Root Device, the Linux statement, root=UUID=, --root-directory=DIR INSTALL_DEVICE

Example
Consider this menuentry:
### BEGIN /etc/grub.d/10_Linux ###
menuentry "Ubuntu 8.04.3 LTS, kernel 2.6.24-24-generic" {
set root=(hd1,2)
linux /boot/vmlinuz-2.6.24-24-generic root=UUID=0df17bc5-0056-4ef7-bfca-251194b6eb44 ro quiet splash
initrd /boot/initrd.img-2.6.24-24-generic
}

The line
set root=(hd1,2)
sets the GRUB root device. The GRUB root device is the partition containing the kernel vmlinuz and initrd files. Thus, it is the partition containing the directory /boot. Also, since the GRUB boot files are contained in /boot/grub, the GRUB files are in that same /boot partition. Note this part of the linux line: root=UUID=0df17bc5-0056-4ef7-bfca-251194b6eb44. The UUID corresponds to the partition containing the root filesystem (/) of the OS (in this case, Ubuntu 8.04.3 LTS, kernel 2.6.24-24-generic) That partition (identified by its UUID) is passed to the Linux kernel using root=UUID=0df17bc5-0056-4ef7-bfca-251194b6eb44 in the linux line.
So, the line "set root=(hd1,2)" is a message to GRUB 2; and "root=UUID=0df17bc5-0056-4ef7-bfca-251194b6eb44" is a message to the Linux kernel.

Normally, for most users, the GRUB root partition (location of the kernel & initrd files) is the same as the root partition of the OS. In this case, the GRUB root device (partition) (hd1,2) would be the same as the root of the Kubuntu filesystem (and thus the UUID would be that of (hd1,2)). However, this need not be the case. If you have a separate /boot partition (separate from the root filesystem of the OS), then the
set root=(hdx,y)
statement and the
root=UUID=xxx
statement in the linux line will correspond to two different partitions.


Another use of the word "root" and setting a "root" for GRUB occurs in the statement
sudo grub-install --root-directory=DIR INSTALL_DEVICE; for example
sudo grub-install --root-directory=/media/sdb1 /dev/sda
where DIR is /media/sdb1 and INSTALL_DEVICE is /dev/sda (i.e., the MBR of drive sda). This directs GRUB to install GRUB images to INSTALL_DEVICE (using the files in the GRUB image directory /usr/lib/grub/i386-pc/ of the Kubuntu OS you are working in) under the directory DIR (instead of the root directory (/) of the OS) and then to install GRUB 2 to the MBR of drive sda using GRUB 2 files in /media/sdb1/boot/grub. The directory DIR specified in --root-directory=DIR becomes the GRUB root directory of this specific GRUB installation.



- - - - - - - - - - - - - - - - - - - -

Cheat Sheet
GRUB 2 Practical Reminders -- for those who know what they are doing

Files image: /usr/lib/grub/i386-pc/
boot/grub/grub.cfg Configuration file for the boot menu. Do NOT edit.
/etc/default/grub Default settings file (Timeout, Default OS, kernel options)
/etc/grub.d Folder of boot menu scripts:
00_header; 05_debian_theme: Background, text colors, themes
10_hurd Locates Hurd kernels; 10_linux Locates Linux kernels; 20_memtest86+
30_os-prober: Searches for Linux and other OS's on all partitions
40_custom: Template for custom boot menu entries
More: /boot/grub/device.map, boot.img (MBR), core.img

Fixing Things, Rescue
Ctrl+Alt+Del reboot PC; Super Grub Disk
New grub.cfg: sudo grub-mkconfig -o /boot/grub/grub.cfg
Install, re-install GRUB 2: sudo grub-install [INSTALL_DEVICE]
to MBR: sudo grub-install /dev/sdx; partition: sudo grub-install /dev/sdxn
If error: grub-install --recheck /dev/sdx; sudo grub-install --recheck /dev/sdxn
Install GRUB 2 to MBR of sda using GRUB 2 in /dev/sdb1/boot/grub:
sudo grub-install –root-directory=/media/sdb1 /dev/sda
Install GRUB 2 to PC (/usr/lib/grub/i386-pc/): sudo apt-get install grub-pc

Live CD rescue: Re-install GRUB 2
sudo mkdir /media/sda2 /media/dev
sudo mount /dev/sda2 /media/sda2
sudo mount --bind /dev /media/dev
Install GRUB 2 to MBR of sdb [or to partition sda2] using GRUB 2 files in sda2:
sudo grub-install --root-directory=/media/sda2 /dev/sdb [or /dev/sda2]
umount /media/sda2 /media/dev

Drives, partitions, information sudo fdisk -lu & grub>ls
Naming: (hdx,y) or sdzy: drive x starts at 0; partitions y start at 1
Konsole: sudo fdisk -lu; df -hT; mounting: cat /etc/mtab; or: mount
UUIDs: sudo blkid; ls /dev/disk/by-uuid/ -alh
Kernel ver: uname -r; cat /proc/version; Linux ver: lsb_release -a
sudo grub-emu and then grub>ls
GRUB devices/drives: grub>ls; grub>ls -al directory
UUID of (hdx,y): grub>ls (hdx,y)
Finding: grub>search /boot/grub/grub.cfg; grub>search /boot/grub/boot.img

Syntax, booting choices
configfile: set root=(hdx,y) and configfile /boot/grub/grub.cfg; or:
configfile (hdx,y)/boot/grub/grub.cfg
symlinks: linux /vmlinuz root=UUID= xxx ro quiet splash; initrd /initrd.img
symlinks: linux /vmlinuz root=/dev/sdxn ro quiet splash
chainload: set root=(hdx,y) and chainloader +1; chainloader (hdx,y)+1
chainload a MBR: chainloader (hdx)+1

Permissions
Executable: sudo chmod 744 /etc/grub.d/file; Remove: sudo chmod -x /etc/grub.d/file
Read only, everyone: sudo chmod 444 /etc/grub.d/file
GUI: kdesudo konqueror (dolphin), rt-click on file, Properties, Permissions
grub.cfg: sudo chmod +w /boot/grub/grub.cfg; sudo chmod -w /boot/grub/grub.cfg

Create a script called /etc/grub.d/NN_myscript
Empty text doc: kdesudo kate; File > Save As /etc/grub.d/NN_myscript
Type it (see template below).
Make executable: sudo chmod 744 /etc/grub.d/NN_myscript
or, sudo chmod +x /etc/grub.d/NN_myscript
GUI: kdesudo konqueror (dolphin), rt-click, Properties, Permissions
Make new grub.cfg: sudo grub-mkconfig -o /boot/grub/grub.cfg

> Template, custom boot entry for file /etc/grub.d/NN_name
#!/bin/sh
echo "Adding name" >&2
cat << EOF
menuentry "name of OS boot entry" {
set root=(hdx,y)
linux /boot/vmlinuz-xyz root=UUID=xxx
initrd /boot/initrd.img-xyz
}
EOF

Edit a script
GUI, kdesudo konqueror, rt-click on script file, Open With Kate/Kwrite.
CLI, kdesudo kate /etc/grub.d/script_name
Edit the file, File>Save, Exit. New grub.cfg: sudo up-date grub; sudo grub-mkconfig

Flash drive /dev/sdc, sdc1 mounted at /media/disk; set boot flag; install GRUB 2:
sudo grub-install --root-directory=/media/disk /dev/sdc

Separate GRUB 2 partition: mounted at /media/sdb1; sda=MBR of 1st BIOS drive
sudo grub-install –root-directory=/media/sdb1 /dev/sda

Working as root (8.10+: kdesudo; 8.04: kdesu)
kdesudo kate /path-to-file; kdesudo konqueror (or dolphin)
Terminal as root: sudo –i; sudo su
GUI file manager, navigate to file, right-click on file, Actions, Edit as Root.
sudo [COMMAND]; sudo grub-install [INSTALL_DEVICE];
sudo grub-mkconfig -o /boot/grub/grub.cfg

[End of GRUB 2 Practical Reminders]


= = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = =
Appendix: Techniques

--- Installing Kubuntu--GRUB 2 placement
--- Working as root
--- Permissions: read, write, execute; change the execute bit
--- Chroot -- how to
See Part 3 of Commands at Konsole: Beginners: 3 parts
http://kubuntuforums.net/forums/inde...opic=3091607.0

= = = = = = = = = = = = = = = = = = = =
Installing Kubuntu--GRUB 2 placement
Live CD method

The Live CD method of installing Kubuntu is easy, fast, and convenient because afterwards, you then have a Live CD to use for rescue and repair of your system.

Installing GRUB 2 files

GRUB 2 is standard on Kubuntu starting with 9.10. During its installation from the Live CD, you can specify if you want GRUB 2installed, and if so, where to put it. Here's how:

Start the Live CD installer.
Step: Disk Setup
"Specify Partitions Manually"
Step: Summary
Advanced button at lower right
Check or un-check to install GRUB 2 bootloader
Choose from the drop-down list where to install GRUB 2
sda = the MBR of drive sda
sda1 = the first partition of drive sda
sdb = the MBR of drive sdb
etc.

Caution:

> If you install GRUB to a MBR (sda, sdb, sdc, etc.), it will overwrite any other bootloader already installed to that MBR, and the GRUB 2 from the OS you are currently installing will then control the boot menu you see when you boot up your PC. That is OK, just so you know.

> If you install GRUB 2 to the partition boot sector where you are currently installing the OS (e.g., sdan, for some n=1,2,3,4...), when you re-boot your PC, you will have to manually boot into your new OS you just installed. Do so using chainloader, as follows:
-- Re-boot
-- If you get some boot menu (from a prior Linux OS installation), press the "c" key to get a GRUB prompt, grub>. If you don't get a boot menu but only the GRUB prompt grub>, then that's OK, too.
-- Let's say your new Kubuntu OS was installed to sda9. That is the same as (hd0,9). Then
grub>chainloader (hd0,9)+1
grub>boot
and you will boot into your new OS.

Building new boot menus

> In your new OS, you can build a full boot menu simply by doing sudo grub-mkconfig -o /boot/grub/grub.cfg.

> In your existing OSs, you can re-build boot menus to include the new OS the same way:
Konsole
sudo grub-mkconfig -o /boot/grub/grub.cfg

> Worst case, if for some reason that doesn't work, you can make a custom boot entry to include your new OS. See SECTION 4. To get the details of the menuentry for the new OS for the existing grub.cfg, you might have to boot into the new OS and copy details from its grub.cfg. Or, simply boot your new OS using symlinks or chainloader (from another OS's boot menu), for which you do not need any details specific to the new OS. See SECTION 4, "4 Ways to boot an OS."

= = = = = = = = = = = = = = = = = = = =
Working as root

Opening a text editor (e.g., Kate, Kwrite, etc.) to see the file and/or to edit it:
kdesudo kate path-to-file
Example: kdesudo kate /etc/fstab

Opening an empty text document as root:
kdesudo kate
(then File > Save As)

Opening a file manager as root:
in 8.10 and after: kdesudo konqueror (or dolphin)
in 8.04: kdesu konqueror (dolphin)

Opening a terminal as root:
sudo –i (to get a “root” terminal)
or:
sudo su

Your file manager may support this feature:
Open the file manager, navigate to the file, right-click on the file, Actions, Edit as Root.

At Konsole (BASH) command line: Use sudo.
Example: sudo fdisk -lu
To open a graphical application (a text editor, a file manager), use either kdesudo or kdesu (see above).


= = = = = = = = = = = = = = = = = = = =
Permissions: read, write, execute; change the execute bit

See Part 2 of
Commands at Konsole: Beginners: 3 parts
http://kubuntuforums.net/forums/inde...opic=3091607.0
Ownership and Permissions Use ls -l to see them; chown & chmod to change them.
See tuxfiles
http://www.tuxfiles.org/linuxhelp/filepermissions.html
(symbolic mode)
Here's a brief reminder sheet for those who know this stuff:

Setting ownership and permissions in GUI
Open Konqueror or Dolphin as root (kdesudo konqueror), navigate to the file or directory, right-click, Properties, Permission, make changes, OK. In Konqueror/Dolphin, click the Advanced Permissions button to see all choices: owner, group, others and read, write, execute.

CLI
owner--group--others
For each class: read, write, execute
ls -l: list files, use a long listing format => shows ownership and permissions

Permissions – numerical mode
There are 8 possibilities (2*2*2) for read (on or off) - write (on or off) - execute (on or off) permissions on a file or directory (2*2*2 = 8 ). The octal equivalents for these binary numbers are:

0: ---; 1: --x; 2: -w-; 3: -wx; 4: r--; 5: r-x; 6: rw-: 7: rwx

744: Owner can do anything, Group can only read, Others can only read

Permissions – symbolic mode
Suppose the file xyzfile is owned by root.
To make it executable for ALL users
sudo chmod +x xyzfile
To remove the execute permission from all users
sudo chmod -x xyzfile

= = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = =

References and Tutorials

Note: Ubuntu versus Kubuntu tutorials
A GRUB 2 tutorial written for Ubuntu applies to Kubuntu. Watch for obvious differences in a few commands and OS tools. In Ubuntu you will see
gksudo gedit /boot/grub/grub.cfg
used for opening grub.cfg as root using text editor gedit.
In Kubuntu, you would use
kdesudo kate /boot/grub/grub.cfg.
In Kubuntu, you will probably use Konqueror or Dolphin as your file manager. Also, there are different package managers used in each OS, even within the same OS at times! I think you'll be able to sort it out, and you can always post questions under one of the regular Kubuntu forums.
>>> The GRUB commands are the same in both Ubuntu and Kubuntu and other Linus OSs.

- - - - -
GRUB 2 Bugs and Questions

“grub2” package in Ubuntu
https://launchpad.net/ubuntu/+source/grub2
Bugs:
https://bugs.launchpad.net/ubuntu/+s...tatus:list=NEW
Questions, Open Questions
https://answers.launchpad.net/ubuntu...ld.status=OPEN
- - - - -
- - - - -

GRUB Legacy
-- How To GRUB Methods - Toolkit
http://kubuntuforums.net/forums/inde...opic=3081671.0
--- Link to be repaired ---


The Grub 2 Guide
(formerly Grub 2 Basics)
by drs305
http://ubuntuforums.org/showthread.php?t=1195275
Absolutely excellent treatment of editing the boot menu and some basic key concepts of Grub 2.

Grub 2 Title Tweaks, by drs305
http://ubuntuforums.org/showthread.php?t=1287602
Customizing the boot menu. Also by drs305. Editing grub.d scripts.

Grub 2 Manual
http://grub.enbug.org/Manual
We hope this will be all you need, along with the man pages.

GNU GRUB 1.96/2
http://members.iinet.net/%7Eherman546/p20.html
Looks like an encyclopedic, comprehensive coverage.

GRUB 2 now default for new installations
https://lists.ubuntu.com/archives/ub...ne/000573.html

Grub 2 now default for Ubuntu 9.10
http://www.ubuntugeek.com/grub-2-now...mic-koala.html

GRUB 2 -- Ubuntu Wiki -- FrontPage
http://grub.enbug.org/

GRUB 2 -- Ubuntu Wiki
https://wiki.ubuntu.com/Grub2

FranklinPiat, Wiki -- good stuff
Grub v2 manual, Manpages
http://grub.enbug.org/FranklinPiat/GrubManual

GRUB 2, official site
http://www.gnu.org/software/grub/grub-2.en.html

GNU GRUB, main site, Legacy GRUB
http://www.gnu.org/software/grub/

GRUB Wiki: grub.cfg
http://grub.enbug.org/grub.cfg

GRUB 2 Commands, GRUB Wiki
http://grub.enbug.org/CommandList
Compares GRUB Legacy to GRUB 2 commands.

GRUB 2: Live CD Install Guide
http://grub.enbug.org/Grub2LiveCdInstallGuide

StartUp-Manager
https://help.ubuntu.com/community/StartUpManager

GRUB & GRUB 2 Boot Process
http://www.pixelbeat.org/docs/disk/

Bootloader
http://en.wikipedia.org/wiki/Boot_loader

GNU GRUB
http://en.wikipedia.org/wiki/GRUB

Boot Options
https://help.ubuntu.com/community/BootOptions

Kernel Parameters
http://www.kernel.org/doc/Documentat...parameters.txt

Grub Legacy
-- How To GRUB Methods - Toolkit
http://kubuntuforums.net/forums/inde...opic=3081671.0
--- Link to be repaired ---

GParted Live CD
http://gparted.sourceforge.net/livecd.php
For partitioning, formatting your hard drive.

Super Grub Disk
http://www.supergrubdisk.org/
Will boot you into your OS when you can't do it alone.

Arch Linux, ArchWiki GRUB 2
http://wiki.archlinux.org/index.php/GRUB2

Experiences in the Community, Jaunty and GRUB2
http://flossexperiences.wordpress.co...nty-and-grub2/

GRUB 2 installation
http://www.techenclave.com/guides-an...ion-92883.html

GRUB2 Theming
http://ubuntuforums.org/showthread.php?t=1182436

KernelTeam/Grub2Testing
https://wiki.ubuntu.com/KernelTeam/Grub2Testing

Using UUID
https://help.ubuntu.com/community/UsingUUID

BIOS Boot Partition, and what does GRUB use it for?
http://grub.enbug.org/BIOS_Boot_Partition

GUID Partition Table
http://en.wikipedia.org/wiki/GUID_Partition_Table

Technical Note TN2166, Secrets of the GPT
http://developer.apple.com/mac/libra...06/tn2166.html

HOWTO: Booting LiveCD ISOs from USB flash drive with Grub2, by JustRon.
http://ubuntuforums.org/showthread.php?t=1288604

Booting LiveCD from HD ISO
http://ubuntuforums.org/showthread.php?t=1295506

Boot an iso via Grub 2
http://michael-prokop.at/blog/2009/0...iso-via-grub2/

MultiBoot USB with Grub2 (boot directly from iso files)
http://www.panticz.de/MultiBootUSB

GRUB Graphical Menu Development Journal
http://grub.gibibit.com/Journal

Debian Wiki, GRUB, grub.cfg
http://wiki.debian.org/Grub/grub.cfg.manpage
As of 9-9-09, it doesn't exist.

Tweaking GRUB 2
http://www.drlock.com/blog/2008/07/11/tweaking-grub-2/

GRUB 2 configuration, shirish
http://www.techenclave.com/guides-an...ion-93512.html

How To Install GRUB 2 On Ubuntu 9.04
http://www.linuxtoday.com/news_story...05-35-OS-HL-SM

[Qqmike]

Re: GRUB 2: A Guide for Users


This post is a continuation of the GRUB 2 Guide (in the first post above).
SECTION numbers refer to the original (first) post above.

CONTENTS, brief:
-- Notes about some of the new GRUB 2 commands
-- Dual booting: How to set it up
-- PROBLEMS -- booting
-- Windows Topics -- booting
--> drivemap command: XP on a non-first hard drive
-- Boot From ISO -- use of GRUB 2 loopback
-- GPT: GUID Partition Table

CONTENTS, expanded:

Notes about some of the new GRUB 2 commands
Included here: chainloader, ls, grub-emu, grub-mkconfig (many tips!), root, rootnoverify (is gone), grub-setup
grub-install: See SECTION 4 above.
drivemap replaces map
See Section 4 above: Booting XP on a non-first hard drive: The drivemap command
See Reply #17 (below) in this thread.
loopback
See below: Boot From ISO -- use of GRUB 2 loopback

Dual booting: How to set it up
Installing two or more Linux operating systems
RECOMMENDED METHOD
Subsection:
PROBLEMS -- booting
Messing up the booting -- fixing GRUB without re-installing Kubuntu


Windows Topics -- booting
Installing XP (or 7? or Vista?) & Kubuntu:
How to set up dual booting (recommended outline)
Re-installed XP and now can't boot Kubuntu
XP on a non-first hard drive: (hdx,y), x > 1
Subsection:
Booting XP on a non-first hard drive
The drivemap command in GRUB 2
--Lots of technical notes here--

Boot From ISO -- use of GRUB 2 loopback
Boot your Kubuntu Live CD ISO from your flashdrive

GPT: GUID Partition Table
... for Kubuntu 9.10 and GRUB 2

=> Overcoming the "2 TB disk size limit" associated with the conventional MBR
=> Get rid of the Extended partition with its linked list of Logical partitions
(Have as many partitions as you want)
=> Testing GRUB 2 on your GPT-partitioned flash drive

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Notes about some of the new GRUB 2 commands
Included here:
chainloader, ls, grub-emu, grub-mkconfig (many tips!), root, rootnoverify (is gone), grub-setup
grub-install: See SECTION 4 of the first post above.
drivemap replaces map
See Section 4 above: Booting XP on a non-first hard drive: The drivemap command
See Reply #2 (below) in this thread.


chainloader --force
is used to skip the check for the end-of-file (EOF) boot sector signature 0xaa55.
For valid bootsectors, it shoudn't be needed; e.g. it shouldn't be needed with a valid windows bootsector.


The ls command
geometry is gone and replaced by ls
The ls command is very useful: See Section 4:
How to get information about your drives and devices
Key commands:
At Konsole : sudo fdisk -lu
At the GRUB 2 prompt: grub> ls


grub-emu
sudo grub-emu will get you into a GRUB 2 emulator (withing your Kubuntu).
To get out, type
exit
Tip:
It's useful to use sudo grub-emu then use ls to see how GRUB 2 is seeing your drives and partitions.


grub-mkconfig: Tips about using it

grub-mkconfig
is a GRUB 2 command for generating a new boot configuration file /boot/grub/grub.cfg
An earlier version was called update-grub. The command update-grub has been replaced by grub-mkconfig (mkconfig = "make configuration file").
If you run
update-grub --help
or
grub-mkconfig --help
you will get the same output based on the command file
/usr/sbin/grub-mkconfig

Note: update-grub
The command update-grub generates a new grub.cfg file and replaces the existing grub.cfg with the newly generated grub.cfg (by default).
But, as explained next, you must specify the output file when using grub-mkconfig.

Using grub-mkconfig correctly: -o option, or --output=FILE
grub-mkconfig --help
tells you.

Note that
sudo grub-mkconfig
prints its output to the screen (default = stdout).
To print to the grub.cfg, use
sudo grub-mkconfig -o /boot/grub/grub.cfg
or
sudo grub-mkconfig --output=/boot/grub/grub.cfg

grub-mkconfig Detecting other OSs
grub-mkconfig automatically runs os-prober to detect other OSs on your PC (assuming os-prober is installed, which it will be in any normal installation).

grub-mkconfig: Is grub.cfg in sync with core.img?
=> Run first: grub-install
To be sure you get the best and the correct grub.cfg file, especially if there's been a change/update to core.img, it would be safe to run
sudo grub-install
before running
sudo grub-mkconfig -o /boot/grub/grub.cfg



root is still used but is now a variable
In GRUB 2, you assign a value to a variable using the set statement; e.g.:
set root=(hd2,3)
and you may reference the variable root by ${root}:
configfile ${root}/boot/grub/grub.cfg


rootnoverify (was a GRUB Legacy command)
isn't needed anymore in GRUB 2 because root is now a variable
and not a command. (So, "rootnoverify" is default behavior now.)


grub-setup
is an advanced tool and should not be used manually.
You should only have to use
grub-install
for your work. grub-install automatically calls grub-setup for you.


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Dual booting: How to set it up

Installing two or more Linux operating systems
> Recommended method
> Problems – messing up the booting; fixing GRUB without re-installing Kubuntu
> This applies to using one or more hard drives
> If your situation involves Windows, see “Windows topics” below

An important, key fact:
The GRUB from the last OS you install overwrites any existing GRUB you already have installed.

=> When you have an existing Linux OS already installed, call it Linux1, and then install a second Linux OS, call it Linux2, the GRUB from Linux2 will overwrite the GRUB from Linux1 that is installed in the MBR of the first BIOS boot drive (hd0). If that happens, then the booting will be controlled not by the GRUB and boot menu from Linux1, but from the GRUB and boot menu (/boot/grub/grub.cfg) of Linux2. Knowing this, you can decide how you want to control things. For example, you can ensure that the GRUB from Linux2 does NOT overwrite the GRUB from Linux1.

Telling the installer where to install GRUB
See Appendix topic: Installing Kubuntu--GRUB 2 placement
>>> Other distros may have their own facilities for installing GRUB.


RECOMMENDED METHOD
Setting up a dual boot between two Linux OSs
I will outline one (of many) methods for setting up a dual boot between two Linux OSs, call them Linux1 and Linux2.

Set up BIOS boot drives
Start you PC, enter BIOS setup, and set BIOS to boot FIRST from the CD drive; second from your first BIOS boot drive (the one you prefer to use for such).

Step 1 Partitioning your hard drive(s) for both OSs
Decide how to partition your hard drive(s) for the two OSs.
Partitioning—how to, Rog131:
http://kubuntuforums.net/forums/inde...opic=3090704.0

Then do the partitioning using GParted Live CD (a very handy tool):
http://gparted.sourceforge.net/livecd.php
Or ...
You can do it using the Live Kubuntu CD: Run the CD as a Live CD (without installing anything yet).
Check whether gparted is already available: K > System > Partition Editor (if so, open it).
If not, install it in your live session using K > System > [your package manager: synaptic, KPackageKit, etc.] Then open it and use it (K > System > [Partition Editor]).

Step 2 Explore your hard drive(s)
Before running the installer, but while in a Live Kubuntu CD session, explore your hard drives to determine how GRUB sees the partitions you set up in Step 1.
See "How to get information about your drives and devices" in SECTION 4 using sudo fdisk -lu and the GRUB 2 ls command. (Note: To use ls, get a GRUB prompt: sudo grub-emu, then grub>ls)
Write down the key partitions you will use for root, home, swap.
=> Identify in both Linux notation (sdXN's) and GRUB notation (hd(x,y)'s) where everything goes--the Kubuntu root filesystem (/), swap, (and /home, if you wish to have a separate partition for /home).
Swap: You only need to reserve one partition for swap, even if you have more than one Linux OS.

Step 3 Run the Kubuntu installer to install the first OS
Install Linux1. Let the installer put GRUB in (hd0) – that is usually the default location.
Thus, your PC will boot from hd0 using GRUB from Linux1 installed to the MBR and the boot menu (/boot/grub/grub.cfg) from Linux1.

Step 4 Run the Kubuntu installer to install the second OS
... and Install GRUB carefully
Install Linux2. But be careful where you install GRUB.
See the Appendix to the original post (above): "Installing Kubuntu--GRUB 2 placement"
> If you want the GRUB (and boot menu) from Linux1 to continue to control the booting, then * be careful * to NOT install GRUB to (hd0). Instead, install GRUB to the root partition of Linux2; or, to the MBR of some other drive, like (hd1) or (hd2)--assuming you feel it is safe to do so.
> If you want GRUB (and the boot menu) from Linux2 to control the booting, then install GRUB to (hd0); in that case, the GRUB from Linux2 will overwrite GRUB from Linux1 in the MBR.

Step 5 Configure GRUB
> If the Linux1 GRUB is to control the booting (and so you did NOT have the Linux2 installer put GRUB in (hd0)), then you want the boot menu (/boot/grub/grub.cfg) in Linux1 to include a boot stanza entry for Linux2. Boot into Linux1, open Konsole, issue this command:
sudo grub-mkconfig /boot/grub/grub.cfg
Check /boot/grub/grub.cfg to see that it now includes a boot entry for Linux2. If it does not, then try to re-install GRUB to the MBR of hd0 using the GRUB 2 from Linux1--See SECTION 3 (also note the use of --recheck if you get an error). Check /boot/grub/grub.cfg to see that it now includes a boot entry for Linux2. If it does not, then see SECTION 4: "Boot menu: Create a custom boot entry" and "4 ways to boot an OS: configfile, symlinks, direct booting, chainloader."
> If the Linux2 GRUB is to control the booting (and so you DID have the Linux2 installer put GRUB in (hd0)), then you should not have to do any further configuring of GRUB--the new Linux2 boot menu (/boot/grub/grub.cfg in Linux2) should already have an entry in it for booting Linux1. If not, boot into Linux2 and issue, at Konsole, command:
sudo grub-mkconfig /boot/grub/grub.cfg
If the /boot/grub/grub.cfg in Linux2 still does not include an entry for Linux1, then try grub-install (possibly with --recheck, see SECTION 3). If the /boot/grub/grub.cfg in Linux2 still does not include an entry for Linux1 see SECTION 4: "Boot menu: Create a custom boot entry" and "4 ways to boot an OS: configfile, symlinks, direct booting, chainloader."

- - - - - - - - - -
PROBLEMS -- booting
Messing up the booting -- fixing GRUB without re-installing Kubuntu

If you make a mistake with GRUB while installing the OSs, you can fix it without re-installing the OS.
See SECTION 3 ("Re-installing GRUB 2").

Example: Re-setting Linux1 to control the booting
Suppose in setting up the dual boot with Linux1 and Linux2 that you mistakenly overwrote the MBR with the GRUB from Linux2. To restore the Linux1 GRUB to the MBR of hd0 (the first BIOS boot drive), simply re-install GRUB 2 using the GRUB files in Linux1 (see SECTION 3). Then, as above, configure /boot/grub/grub.cfg (in Linux1) so it includes a boot entry for Linux2.
> Let's assume Linux1 is in partition sdxn. Also, suppose the BIOS boot drive hd0 is sdz. Then re-install GRUB to the MBR of hd0 using the GRUB in Linux1 as follows:
Use "Re-installing GRUB 2 using Live CD: Key Rescue Method" of SECTION 3.
Or
Use Super Grub Disk to boot into Linux1 to fix the problem
(reinstall GRUB 2: sudo grub-install)
Or (also see SECTION 3, "sudo grub-install"):
Boot into Linux2, see how sdxn is mounted (check your file manager; e.g., Dolphin or Konqueror); suppose it is /media/sdxn. Open Konsole, issue:
sudo grub-install --root-directory=/media/sdxn /dev/sdz
If that fails, try
sudo grub-install --recheck --root-directory=/media/sdxn /dev/sdz
You should now be able to re-boot into Linux1 to check that its /boot/grub/grub.cfg includes a boot entry for Linux2. If not, see Step 5: Configure GRUB.

Example: Re-setting Linux2 to control the booting
Or, if you wanted the GRUB from Linux2 (and its /boot/grub/grub.cfg) to control the booting, but you did not have its GRUB installed to the MBR of the first BIOS boot drive, (hd0), then reinstall GRUB from Linux2 (to the MBR (hd0)) and configure the Linux2 grub.cfg to include a boot entry for Linux1.
> Let's assume Linux2 is in partition sdxn. Also, suppose the BIOS boot drive hd0 is sdz. Then re-install GRUB to the MBR of hd0 using the GRUB in Linux2 as follows:
Use "Re-installing GRUB 2 using Live CD: Key Rescue Method" of SECTION 3.
Or
Use Super Grub Disk to boot into Linux2 to fix the problem
(reinstall GRUB 2: sudo grub-install)
Or (also see SECTION 3, "sudo grub-install"):
Boot into Linux1, see how sdxn is mounted (check your file manager; e.g., Dolphin or Konqueror); suppose it is /media/sdxn. Open Konsole, issue:
sudo grub-install --root-directory=/media/sdxn /dev/sdz
If that fails, try
sudo grub-install --recheck --root-directory=/media/sdxn /dev/sdz
You should now be able to re-boot into Linux2 to check that its /boot/grub/grub.cfg includes a boot entry for Linux1. If not, see Step 5: Configure GRUB.


Windows topics -- booting

Dual-booting Kubuntu with Windows: I will cover a basic case here.
In the following how-to for GRUB Legacy, I covered dual-booting principles for Windows and Kubuntu:
HOW TO: GRUB Methods - Toolkit
http://kubuntuforums.net/forums/inde...opic=3081671.0
It applies to GRUB 2.
Also, I will defer to the following reference for comprehensive treatment of dual-booting with Windows:
Vista, dual-booting with XP and/or Kubuntu/Linux, see this definitive guide:
http://apcmag.com/dualboot

Basically, SECTION 6 Windows topics of the "HOW TO: GRUB Methods - Toolkit" applies similarly to GRUB 2, and I will outline those topics now:
XP (and it should also apply pretty much to 7 and Vista)
Installing XP & Kubuntu: How to set up dual booting
Re-installed XP and now can't boot Kubuntu
When XP is on a non-first hard drive

Installing XP (or 7? or Vista?) & Kubuntu: How to set up dual booting (recommended outline)

1 Install XP first, and install it to the first partition of your hard drive.
2 Decide how you want to partition for Kubuntu:
Partitioning—how to, Rog131:
http://kubuntuforums.net/forums/inde...opic=3090704.0
3 Prepare the partitions for Kubuntu using GParted live CD from here:
GParted: http://gparted.sourceforge.net/
Or, do it using gparted from the Live Kubuntu CD.
4 Install Kubuntu
The Kubuntu installer will install GRUB to the MBR of the HD, and thus it overwrites the XP bootloader that XP installed in the MBR of that HD. If you do not want that to happen, you will have to use XP's bootloader to load Linux.
5 When you re-boot your PC, you will see the GRUB boot menu offering you the choice to boot into either XP or Kubuntu.

Re-installed XP and now can't boot Kubuntu
Suppose you had a dual boot set up with XP and Kubuntu, but then you re-installed XP, XP's bootloader overwrote GRUB in the MBR, and now you can't boot into Kubuntu. To fix this, simply re-install GRUB (using the GRUB files in Kubuntu) to the MBR of the first BIOS boot drive (hd0). See SECTION 3 (Reinstalling GRUB) above.


XP on a non-first hard drive: (hdx,y), x > 0
Suppose Kubuntu is on your first BIOS boot drive hd0, and GRUB (from Kubuntu) is installed to the MBR (hd0); thus, your PC boots from hd0 using GRUB. Later, you wish to install Windows on a second hard drive, (hd1), and you wish to set things up so GRUB controls the booting through its boot menu. (Or, perhaps Windows was there first, then you install Kubuntu, but you want the PC to boot first from the Kubuntu HD.) Thus Windows will be on a non-first hard drive (a hard drive other than the first BIOS boot drive). Windows does not like booting from a non-first hard drive. Worse than that, so I've read, the real problems occur when Windows is updated in certain ways; if it is on a non-first HD, the booting may get messed up. Nonetheless, you can perform a virtual switch of hard drives using the GRUB drivemap command in the boot entry for Windows. No physical change is made to the hard drives or to the operating systems.

See the following subsection titled "Booting XP on a non-first hard drive: The drivemap command in GRUB 2."

=> => Fact is, you might be able to use the GRUB 2 utility grub-mkconfig or grub-install to do this work for you: they might detect Windows properly and adjust for Windows being on a non-first HD (by implementing the drivemap commands automatically). (For the commands grub-mkconfig and grub-install, see Notes about some of the new GRUB 2 commands (in Reply #1 above); also see SECTION 3: Fixing Things)

Subsection:
Booting XP on a non-first hard drive
The drivemap command in GRUB 2

The Quick-and-Dirty Solution

Method 1
To boot Windows XP installed to (hd1,1), use the following menuentry (in a script you write as a text file (and make executable) in the folder /etc/grub.d):

# Method 1 -- a safe, sure way to do it
# This method applies to Windows and to FreeDOS
# Windows XP on sdb1 (= (hd1,1)
menuentry “Windows XP on sdb1, by chainloader” {
drivemap (hd0) (hd1)
drivemap (hd1) (hd0)
set root=(hd0)
chainloader (hd1,1)+1
}

=> The drivemap command in GRUB 2 replaces the map command in GRUB Legacy.
=> That's all you need to know to make your grub.cfg work.

=> => Fact is, you might be able to use the GRUB 2 utility grub-mkconfig or grub-install to do this work for you: they might detect Windows properly and adjust for Windows being on a non-first HD (by implementing the drivemap commands automatically).

- - - - -
Method 2 applies to booting Windows on a non-first hard drive; it does not apply to FreeDOS:

# Method 2
# This method applies to Windows
# This method does NOT apply to FreeDOS
# Windows XP on sdb1 (= (hd1,1)
menuentry “Windows XP on sdb1, by chainloader” {
drivemap (hd1) (hd0)
set root=(hd1,1)
chainloader +1
}

IMPORTANT:
The line
drivemap (hd1) (hd0)
is my idea; in the grub-devel correspondence, it was the opposite:
drivemap (hd0) (hd1)

What this means for you
> You can stick with the safe method, Method 1.
> If you choose to use the more compact Method 2, doing it my way or their way, and if your PC hangs up, not able to boot into Windows, press the re-set button on your PC to re-boot, then boot into your Kubuntu 9.10 and fix your grub.cfg so it tries another way (e.g., switch from drivemap (hd1) (hd0) to drivemap (hd0) (hd1) or vice versa). Or, re-boot using re-set button, then experiment at the GRUB CLI by pressing the "c" key and manually trying another way to see what will work (at the grub>, don't forget to use the boot command as your last command: grub>boot).

Technical notes

-- The drivemap command in GRUB 2 replaces the map command in GRUB Legacy.

-- You should use an up-to-date version of GRUB 2 (1.97xx). You can get it from 9.10 Karmic.

-- The switch -s should also work:

# Method 1 -- a safe, sure way to do it
# This method applies to Windows and to FreeDOS
menuentry “Windows XP on sdb1, by chainloader” {
drivemap -s (hd0) (hd1)
set root=(hd0)
chainloader (hd1,1)+1
}

where the line
drivemap -s (hd0) (hd1)
means:
drivemap (hd0) (hd1)
drivemap (hd1) (hd0)

-- If doing this at the GRUB CLI (grub>), you must (always) issue the boot command as your last command, in this case after the chainloader command:
drivemap -s (hd0) (hd1)
set root=(hd0)
chainloader (hd1,1)+1
grub>boot

- - - - - - - - - - - - - - - - - - - -

More Technical Notes

--- The command drivemap (hdn) (hdm)
The command maps the BIOS drive hdm to the OS drive hdn.
(The BIOS drive will be the same as the GRUB drive.)

Very important: The drivemap command doesn't act until the boot command is issued. (In a grub.cfg boot menu, the boot command is implied at the end of a menuentry; at the GRUB CLI, the boot command is issued manually as grub>boot.)

This sometimes gets confusing (from a user's view). I have found the following point of view to be helpful (a tentative opinion, pending more guidance from the devs in an official Manual).

The command
drivemap (hdn) (hdm)
associates the BIOS drive hdm with the OS drive hdn.
That is, when the OS tried to use drive hdn, the device request to BIOS (Int13) will be interrupted by drivemap, drivemap will perform the switch (replacing hdn with hdm), drivemap will return control to the BIOS controller (Int13), and the OS will actually get the switched result hdm.

--- BIOS drives, DL register, chainloader, drivemap, the boot sequence

BIOS maintains a list of hard drives, starting at 0x80 for the first BIOS drive, then 0x81 for the second BIOS drive, etc.
When BIOS loads a boot sector (from a MBR or from a OS partition boot sector), the number of the boot disk (where the boot sector is located) is stored in the DL register (an so can be used by the boot loader or the OS being loaded by the bootloader).
The chainloader command
set root=(hdn,p)
chainloader +1
causes the boot sector (sector 1) of partition (hdn,p) to be loaded into memory, and then chainloader transfers control to the bootloader in that boot sector. The drive hdn is then set as the BIOS boot drive in the DL register. The boot sector bootloader then loads the OS into memory and transfers control to the OS.
Then when the boot command is issued (after the chainloader command is executed):
The drivemap command kicks in, it takes over the Int13 role, performing the drive mapping and switching, returns control to the BIOS Int13 handler, and then the OS sees the drives as they have been mapped/switched by drivemap.
Important: drivemap does not change the real (live) drive mapping as seen by GRUB 2; the changes performed by drivemap only affect the booted OS.

--- Comment on Method 1: the set root=(hd0) statement
This has been described as a faux GRUB root statement. You can use what has been said here to reason why it is needed in the menuentry of Method 1:
The chainloader command will load (hd1,1) into memory, transfer control to the Windows boot sector in (hd1,1), the Windows boot sector will access the DL register containing hd0 (because set root=(hd0) was issued prior to chainloader), (and remember, Windows likes to boot from the first BIOS boot drive hd0), then the boot statement is issued and so drivemap is effective and hd0 corresponds to BIOS drive hd1 (since hd0 and hd1 were switched in the BIOS drive list), and Windows will boot itself from hd1 (although it thinks it is booting from hd0). If we omit the statement set root=(hd0) in Method 1, then Windows bootloader will get hd1 in the DL register, the boot command causes drivemap to switch that to hd0, and Windows will not boot.

-- Logic for using the more compact Method 2: Why Windows works but FreeDOS will not
# Method 2
# Windows XP on sdb1 (= (hd1,1)
menuentry “Windows XP on sdb1, by chainloader” {
drivemap (hd1) (hd0)
set root=(hd1,1)
chainloader +1

The boot sector of (hd1,1) is loaded into memory by BIOS, control is transfered to the Windows bootloader in that boot sector, it may try to load/boot Windows from hd0, but because drivemap is executed after chainloader, hd0 will result in hd1 being switched in, and Windows loads and runs. Windows MAY then have a drive list that is switched around (because of drivemap and DL possibly containing hd1). But since Windows uses its own drivers for disk control and management, it will use those to fix everything correctly back to normal. This same reasoning applies to any OS that uses its own disk drivers. However, since FreeDOS does not use its own disk drivers, you must use Method 1 for chainloading FreeDOS when it is on a non-first hard drive; otherwise, if you use Method 2, FreeDOS may boot but then will have lost hard drive hd0.



- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Boot From ISO -- use of GRUB 2 loopback
Boot your Kubuntu Live CD ISO from your flashdrive

GRUB 2 includes a new command, loopback. Use loopback to make a device from a file.

Example Flash drive boot from ISO
We'll put the Kubuntu Live CD iso file on a USB flash drive and boot the live OS from the iso on the flash drive. So, when done, you will boot your PC from the USB flash drive, get a boot menu, select an option corresponding to your Kubuntu Live CD iso file (which will be located on your flash drive), and you will then be booted into a Live Kubuntu session (corresponding to that iso).

Do this work in your Kubuntu 9.10 OS.

Steps:
-- Prepare the flash drive (partition and format)
-- Install GRUB to the flash drive and make a grub.cfg
-- Copy the Kubuntu iso file to the flash drive
-- Reboot to test it

As follows:

-- Prepare the flash drive
Use GParted Live CD (or use gparted from your Kubuntu OS) to partition and format the flash drive. Make two partitions:
Partition #1: ext3, 30 MB Label = GRUB2
Partition #2: ext3, 850 MB Label = Kubuntu910Live
(Make the second partition big enough to hold your iso file.)

Notes
1 To set a Label on a partition in GParted: Partition > Label.
2 If your flash drive doesn't have a standard partition table on it, use GParted to set one up: Device > Partition Table, and choose the default MSDOS type.
3 If you wish to clean up a flash drive before using it, write zeros to the entire thing. Use sudo fdisk -lu to see how it is named (e.g., sda, sdb, etc.), then use dd. Example: if it is named sdc, then open Konsole,
sudo dd if=/dev/zero of=/dev/sdc
will write zeros to every bit on the flash drive. It may take awhile, just let it run until it prints out the result.

-- Install GRUB 2 In partition 1, set up GRUB 2 files and install GRUB 2 to the Master Boot Record of the flash drive using the GRUB 2 files in partition 1, and then make a boot menu /boot/grub/grub.cfg.

At Konsole, use
sudo fdisk -lu
to find out how the flash drive is named. In our example, we assume it is sdc, with partitions sdc1 and sdc2.

The following command sets up the GRUB 2 files in sdc1 assuming the first partition (/dev/sdc1) is mounted as /media/GRUB2 (in your Kubuntu OS) and then installs GRUB2 bootloader code to the MBR of sdc:
sudo grub-install --root-directory=/media/GRUB2 /dev/sdc
Note that the command will first make the directories /boot and /boot/grub in sdc1 (assuming they are not already set up in sdc1), and then it fills /boot/grub with GRUB 2 files.

Boot menu: /boot/grub/grub.cfg
Make the text file grub.cfg and copy it to /boot/grub.
Your grub.cfg will be the following:

set timeout=5
set default=0

menuentry "Kubuntu 9.10 Live from ISO on flash drive" {
loopback loop (hd0,2)/kubuntu-9.10-desktop-i386.iso
set root=(loop)
linux /casper/vmlinuz boot=casper iso-scan/filename=/kubuntu-9.10-desktop-i386.iso
initrd /casper/initrd.lz
}

Notes
> Flash drive partitions sdc1 and sdc2. sdc1 = GRUB2 and contains /boot/grub. sdc2 = K910Live and contains kubuntu-9.10-desktop-i386.iso. When the PC boots from the flash drive, the partition sdc2 (where the iso file is) will be seen by BIOS and by GRUB 2 as (hd0,2). Before the loopback statement is executed, the path of the iso file is (hd0,2)/kubuntu-9.10-desktop-i386.iso. After the loopback statement (and the iso file is mounted as a device), the root directory is / (=(hd0,2)/), and the iso file is directly under /; so the kernel sees the path as /kubuntu-9.10-desktop-i386.iso.
> Using the loopback command, you do not need to unpack and extract the kernel (vmlinuz) and the initrd (initrd.lz) files. Everything is handled automatically.


-- Copy the iso file to the second partition
In our case, we copy the iso file kubuntu-9.10-desktop-i386.iso to sdc2 (labeled as Kubuntu910Live).

-- Reboot to test it
Leave the flash drive plugged in (but Safely Remove it), close out your Kubuntu programs, re-boot, enter BIOS setup, configure your BIOS to boot from USB and place the flash drive at the top of the boot list, save these changes to BIOS and exit, and let your PC re-boot from the flash drive and start your Kubuntu Live session from the iso file (kubuntu-9.10-desktop-i386.iso).

You're done.


Extensions, Tips

1 Include more iso files on the flash drive
You can add more iso files to partition 2; of course, you'll need enough room on your flash drive to do so. For each live CD you wish to boot from its iso file, make a boot menu entry and include it in the grub.cfg you already built for "Kubuntu 9.10 Live from ISO on flash drive."
The trick is the linux line and the initrd file: sometimes you need more kernel parameters in the linux line (and you get them by googling, asking, experimenting, and copying); and you need to know the name of the initrd file (initrd.lz in our example) ...

Peek into the iso file without burning a CD ...
You can look at the files contained in an iso file without burning the iso to a CD. For this, see another how-to:
Commands at Konsole: Beginners
http://kubuntuforums.net/forums/inde...opic=3091607.0
Part 3
-- Extract files from an .iso without burning the CD
(You will not extract anything for our purposes here--just have a look at what's inside the iso, specifically, the kernel, initrd, and perhaps the isolinux.cfg file to see if you can find any linux kernel boot parameters).
--- This link may be broken --- To be fixed! ---

2 Use the method to boot a Live OS from its iso located on a hard drive (e.g., the iso might be located in your regular Kubuntu /boot directory, or on another partition). Here, you would boot your PC as usual, letting your normal boot menu appear, then you'd select a menuentry corresponding to an iso file located on one of your partitions, and you'd boot the Live OS from that iso.


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

GPT: GUID Partition Table

... for Kubuntu 9.10 and GRUB 2

=> Overcoming the "2 TB disk size limit" associated with the conventional MBR
=> Get rid of the Extended partition with its linked list of Logical partitions
(Have as many partitions as you want)

Caution
This is all very experimental! Be careful using this stuff on your main/production system.


CONTENTS

The PC: BIOS, booting, the MBR, the bootloader
MBR: Limitations, problems, the "2 TB limit" issue
GPT -- GUID Partition Table -- and EFI
GPT layout, features, and the Protective MBR for your bootloader
Maximum disk size in GPT systems: 9.44 billion terabytes (9.44 zettabytes (ZB))
Requirements for using a GPT (kernel, bootloader, utilities, BIOS Boot Partition)
=> Testing GRUB 2 on your GPT-partitioned flash drive
Troubleshooting

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The PC: BIOS, booting, the MBR, the bootloader

The Master Boot Record (MBR) is an area of a disk (a hard drive, a flash drive) that contains key data used by the BIOS of the PC to start--to "boot up"--the PC. It has been around a long time through the evolution of the original IBM PC and IBM compatible PCs, dating back to 1981, and starting with x86 CPU PC architecture in 1978.

For this chronology and references, see
x86 (CPU: central processing unit)
http://en.wikipedia.org/wiki/X86
IBM PC:
http://en.wikipedia.org/wiki/IBM_PC#Longevity
IBM Compatible PC:
http://en.wikipedia.org/wiki/IBM_PC_...mpatible_today
And for BIOS (Basic Input Output System, a term also going back to the beginning of PCs), see
http://en.wikipedia.org/wiki/BIOS


The MBR plays a key role in the booting process

In a (detailed) nutshell: You turn on your PC. The x86 CPU executes an instruction at the address 0xFFFF0 which then transfers control to the start of a program called BIOS, a program (a set of instructions called firmware) stored in a special type of ROM (EEPROM: electronically erasable programmable read-only memory) located on a chipset that is part of the motherboard of the PC. The BIOS runs the POST (power-on self test) checking and initializing installed devices and memory. BIOS then checks the boot devices (hard drives, CDs, flash drives, floppy drives) in a certain order (that you configure in BIOS setup under the boot device sequence) until it finds a bootable device (i.e., a device it can read and that contains a two-byte boot signature (AA 55, or in hexadecimal 0xAA55) at the end of the first sector (1 sector = 512 bytes, 1 byte = 8 bits). This first sector (of a device) is called the boot sector. In the case of a hard drive (or flash drive, or external USB drive), the first sector of the device, the boot sector, is called the Master Boot Record. BIOS then transfers control to the bootloader code (e.g., GRUB) it finds in the first 446 bytes of the MBR (this bootloader code is often referred to as Stage 1 code). The bootloader looks at the partition table (located in the next 64 bytes of the MBR); it locates a bootable partition (one that has the active flag or boot flag set); it loads the boot sector of the bootable partition into RAM (random accesses memory--the "main" memory of the PC); it then transfers control to its Stage 2 bootloader code (located somewhere beyond the MBR; e.g., immediately following the MBR or elsewhere, e.g., in the operating system's filesystem). Now, the Stage 2 bootloader code takes over and loads the operating system (OS) into memory (into RAM: random access memory), and then the OS runs in RAM and takes over from there.

NOTE 1 Note the size of the MBR: 446 bytes for the bootloader Stage 1 code PLUS 64 bytes for the partition table PLUS the 2-byte ending boot signature (AA 55) = 512 bytes = the first sector of the disk.)
NOTE 2 Note that there are two types of boot sectors on a disk: (1) the boot sector of the disk (the first sector on the disk; e.g., the MBR of a hard drive); and (2) the boot sector of a partition (the first sector of the partition).
NOTE 3 Note that two things are sequentially loaded into RAM: first the bootloader code (in the MBR) loads the boot sector of the bootable partition into RAM; second, the bootloader code (Stage 2) loads the OS into RAM.

Summary So, if speaking to someone you run into on the street, we might put it this way:
You turn on the PC; the CPU starts the BIOS, the BIOS finds a bootable device and checks the MBR of that bootable device for bootloader code Stage 1 and turns control over to Stage 1; Stage 1 bootloader code looks at the partition table (in the MBR), finds a bootable partition, loads the boot sector of that bootable partition into RAM, and passes control to Stage 2 bootloader code, which in turn loads the OS into RAM and passes control to the OS (which runs in RAM).


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MBR: Limitations, problems, the "2 TB limit" issue

The MBR is easily damaged (as many people learn and then find themselves visiting TestDisk to recover it). It is limited to four primary partitions, or more if you make one primary partition an extended partition and put logical partitions "inside" the extended partition (but then, because the logical partitions are connected as a linked data structure, if you change or damage one of them, it may mess up access to others; furthermore, this arrangement is somewhat clumsy and inconvenient).

And then there's the so-called 2 TB limit which is a function of the MBR itself (irrespective of hardware or OS issues). To understand this, consider what the MBR looks like. In fact, have a look at yours, print it to the screen in hexadecimal characters as follows (at Konsole):

sudo dd if=/dev/sda count=1 | hexdump -C

where sda is the hard drive containing the MBR you wish to see (each hard drive has an MBR). If you see a bunch of ***** here and there, they indicate blocks of zeros. If you see on the right things like GRUB .Geom.Hard Disk.Read. Error., ignore it, it's OK, not a problem. You can also see the boot signature 55 AA at the end, indicating end-of-file and indicates it is a boot record. If you want to know how to read this output and everything else about the MBR and partitions, see Starman's excellent, definitive work:

MBR/EBR Partition Tables, Copyright © by Daniel B. Sedory
http://mirror.href.com/thestarman/as...PartTables.htm

But for what we need here, it's easy enough to summarize the organization of the MBR, as follows:

-- The MBR occupies the first sector of your hard drive (or flash drive); since a sector is 512 bytes, the MBR is the first 512 bytes of your hard drive.
-- The first 446 bytes of the MBR is occupied mainly by the bootloader code (e.g. Stage 1 of GRUB Legacy or boot.img of GRUB 2).
-- The next 64 bytes is the partition table.
-- The final 2 bytes is the boot sector signature (or end-of-file) 55h AAh (or, in hexadecimal, 0xAA55. (The "0x" introduces it as hexadecimal; and hexadecimal reverses the order, putting AA first then 55, and that is because of how it will be read--the last comes first.)

Now, let's look at the MBR partition table:

-- It is 64 bytes long, each of the four partition entries is 16 bytes.
-- The first 8 bytes contains the following: The first byte is the status (0x80 = active => bootable). The next three bytes contains the start of the partition in the antiquated C/H/S geometry. The next three bytes after that contains the end of the partition, again in C/H/S.
-- The second 8 bytes of the 16-byte partition entry describes the partition's location (LBA) and size as follows:
4 bytes specifies the LBA (Logical Block Address) of the first sector of the partition.
4 bytes is used for the number of blocks in the partition (usually a block is 512 bytes but may also be 1024 bytes).

That raises the question which is at the heart of the problem with the MBR:
How big can a partition be? how big can a disk be?

> 4 bytes specifies the LBA (Logical Block Address) of the first sector of the partition.
There are 8 bits in a byte, so 4 bytes is 32 bits. A bit can be zero or one. So 32 bits can represent 2**32 binary numbers (sequences of zero's and one's). That's 2 raised to the exponent 32:
2**32 = 4,294,967,296.
So that's how many sectors we can address using the MBR, and since each sector is 512 bytes, we get:
(2**32)*512 bytes = 2,199,023,255,550 (or approximately 2.2E12) bytes.
This is approximately 2 terabytes or 2 TB.

Thus, the limit on disk size is 2 TB (otherwise we couldn't address all of its sectors).

> Similarly, the size of the partition in blocks is represented by the second 4 bytes, and with the usual 512-bytes/block, that again is 2 TB, and so the limit on partition size is 2 TB.

Thus, we have the 2 TB limit. It is a limitation of the traditional MBR used in most PC's today.


NOTES

--- One terabyte is 1024GB; 1 petabyte (PB) is 1024TB; 1 exabyte (EB) is 1024 PB; and 1 zettabyte (ZB) is 1024PB.
For a table of these decimal and binary numbers, see
http://en.wikipedia.org/wiki/Terabyte

--- See a graphical representation of the MBR here:
http://en.wikipedia.org/wiki/Master_Boot_Record

--- CHS and LBA
The old C/H/S notation (cylinder-head-sector, which starts sectors at 1) for describing the location of data on a disk was based on physical disk geometries when hard drives were very small. It was later enhanced but still very limited. It was replaced by Logical Block Addressing (LBA). which basically simply converts C/H/S into a linear, numerical sequence (sectors start at zero). Nowadays, all modern BIOSs and OSs use LBA. To learn more, read these:

CHS Cylinder-head-sector
http://en.wikipedia.org/wiki/Cylinder-head-sector
LBA Logical block addressing
http://en.wikipedia.org/wiki/Logical_block_addressing


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GPT -- GUID Partition Table -- and EFI

Just as the PC BIOS uses the MBR, the new Extensible Firmware Interface (EFI) uses the GUID partition table (GPT). EFI, developed by Intel and now handled by the Unified EFI Forum, defines a software interface between the OS and the platform firmware and is positioned to replace BIOS as the standard.

>>> This section of the present how-to is in progress:
The post you are reading is not about EFI per se, it is about GPT. We make just a few comments and provide some links, and then we return to the subject of GPT.

Apparently, we have this:
"Linux has been able to use EFI at boot time since early 2000, using the elilo EFI boot loader or, more recently, EFI versions of GRUB."

elilo:
http://en.wikipedia.org/wiki/Elilo
And, apparently there has been some controversy in the Linux community about EFI:
Linux: Linus On The Extensible Firmware Interface
http://kerneltrap.org/node/6884

Read all about EFI and related subjects:
Extensible Firmware Interface
http://en.wikipedia.org/wiki/Extensi...ware_Interface
Extensible Firmware Interface (EFI) specification (GPT: see Chapter 16)
http://www.intel.com/technology/efi/

"There are few alternatives for Legacy BIOS in the x86 world: Extensible Firmware Interface, Open Firmware (used on the OLPC XO-1) and coreboot."
Open Firmware (or OpenBoot)
http://en.wikipedia.org/wiki/Open_Firmware
Coreboot
http://en.wikipedia.org/wiki/Coreboot

>>> Here, our focus is on a part of the EFI, the GPT, motivated by the 2 TB disk size limitation of BIOS-MBR, and for that, continue reading.


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GPT layout, features, and the Protective MBR for your bootloader

The size of the GPT depends on the implementation of it by an OS platform. At a minimum, the EFI specification calls for at least 128 partition entries (or records), each 128 bytes long, so that implies a minimum GPT size of 16,384 bytes (i.e., for the partition table itself).

GPT uses LBA exclusively (it does not use the antiquated C/H/S). LBA0 refers to the starting (sector) address of the Protective MBR. LBA1 refers to the starting (sector) address of the Primary Partition Table Header.

GPT includes a Protective MBR that you may use for your bootloader
> Thus you may install GRUB 2 to the MBR of the disk that is partitioned as GPT.

The Protective MBR has the same form as a full conventional BIOS-MBR.
It goes into the first sector of the disk (just as in BIOS-MBR systems),
and it precedes the GPT partition table.

The partition table in this MBR contains just one partition entry of type 0xEE.
If the disk is less than 2 TB, the single partition is specified to be the entire disk.
If the disk is greater than 2 TB, the partition's size is set = 2 TB.

This protects the GPT against destructive actions caused by using non-GPT-aware disk partitioning utilities. If a utility reports to you only a MBR on the GPT disk, it means that you've used a GPT unaware utility. And if such a utility is used on a GPT disk, it will see a full disk, report such to you, and not attempt to partition anything (without first complaining to you that the disk is full).

GPT stores all partitions in one table
=> there is no use of any "extended" or "logical" partitions.

You may include a human-readable label for a partition
Exs.: Home; GRUB2_files; Data_Photos;

Partition table backup and integrity

The GPT scheme includes a Secondary GPT, providing redundancy: the GPT header (containing the Protective MBR and the partition table) is written at the start and at the end of the disk.

(On EFI implemented GPT: " ... [The GPT] also contains a CRC32 checksum for itself and for the
partition table, which is verified by EFI processes on boot...")

Reference
For a graphical representation of the GPT, more details, and links, see
GUID Partition Table
http://en.wikipedia.org/wiki/GUID_Partition_Table

NOTE
GUID (Globally Unique Identifier) is Microsoft's implementation of UUID (Universally Unique Identifier) used in Linux. More about UUIDs here:
http://en.wikipedia.org/wiki/UUID


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Maximum disk size in GPT systems: 9.44 billion terabytes (9.44 zettabytes (ZB))

In the partition table entry (in the GPT) for a given partition, 8 bytes are used as the pointer on the disk to the starting sector of that partition (i.e., 8 bytes are used to designate the LBA address of the starting sector of that partition). That is 64 bits (8 bytes times 8 bits/byte). And so 2**64 is the number of sectors addressable in the GPT, with 512 bytes per sector, gives a total byte-count of (2**64)*512 = 9.44E21 bytes for the disk (maximum size), or 9.44 zettabytes (ZB) (a zetabyte is a billion (~ E9) terabytes (~ E12)). Well, that certainly overcomes the 2 TB limitation of the BIOS-MBR system.


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Requirements for using a GPT

To successfully implement a GPT, you need GPT support from:

-- Kernel support
(Linux supports GPT)

-- Bootloader support
(GRUB 2 supports GPT, as do various patched versions of GRUB Legacy)

-- Disk partitioning utilities support
The command-line GNU Parted supports GPT,
as does the GUI driven GParted (Gnome Partition Editor).
(Both these are based on libparted, a good thing.)

GNU Parted
http://www.gnu.org/software/parted/index.shtml
GNOME Partition Editor
http://gparted.sourceforge.net/

Adding a GPT disk to an existing BIOS-MBR system: No problem
Your existing disk(s) may be BIOS-MBR configured.
You may install a new GPT-based disk to the setup.
> If GRUB 2 is installed to the MBR of both disks, you may boot one from the other using chainloading.

You do not need a full EFI system to use a GPT
BUT ... For GRUB 2 you will need a BIOS Boot Partition

> You can implement a GPT on a conventional BIOS-based system.

>>> Important <<<

For GRUB 2 you will need a BIOS Boot Partition in the GPT scheme

GRUB 2 boot.img will go into the protective MBR (using the first 446 bytes of the MBR).
However, in the GPT setup, there is no space following the 512-byte MBR for embedding the "second stage" core.img. Thus, you must make a separate "BIOS boot partition" to hold core.img. Make it 128 kiB as recommended in the following link. Actually, using ext2 for example, and GParted Live CD, the minimum partition size is 8 MB, or 32 MB for FAT32.

BIOS Boot Partition
http://grub.enbug.org/BIOS_Boot_Partition


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Testing GRUB 2 on your GPT-partitioned flash drive

I did a quick test, and you can, too. I'll explore this some more after GRUB 2 and 9.10 are finalized.

Here's my summary.

OS: Kubuntu 9.10 alpha 6 (which uses the latest version of GRUB 2 (1.97x).
Bootloader: GRUB 2 (beta)
Disk device: 1 GB Kingston USB flash drive
Motherboard: Intel DG33FBC; Intel D915GAVL
Disk partition utility: GParted Live CD, current version

Steps:

1 Boot into Kubuntu

2 Open Konsole (Terminal program)

3 Optional: Zero-out your flash drive
THIS WILL DESTROY ALL DATA ON THE FLASH DRIVE.
This writes zeros to the entire flash drive and restores it to factory-new condition.
Find out how Kubuntu sees your flash drive:
sudo fdisk -lu
Let's say, for this example, it is /dev/sdc.
Use the dd command to write zeros to the entire flash drive:
sudo dd if=/dev/zero of=/dev/sdc
(You will not see any progress meter or output until it finishes. It took approximately 7 minutes on my system.)

4 Partition the flash drive using GParted Live CD
You can also do this using an installed gparted (Partition Editor).
Tip: While in GParted Live CD, remember that you have access to a terminal if you need one (for dd, or sudo fdisk -lu): double-click Terminal icon at top. For root, simply use sudo in front of commands.

I partitioned as follows:

Plug in the flash drive, click Devices > Refresh (you may have do it more than once until the flash drive appears in the drop-down list of drives at the upper right or under GParted > Devices).
You'll get a message that a Disklabel must be set on the disk and asked if you want the (default) msdos Disklabel. (You will also get this message if you highlight unallocated space and click Partition > New). You don't want msdos, so click the Advanced button and select gpt, then Create.

Partitions:

Partition 1: BIOS Boot partition
8 MB (the minimum size offered), FAT32, for the BIOS Boot partition (embedding core.img).
Set a flag: Partition > Manage flags, then check the bios_grub box (as the tag).
Set a Label on the partition to remind you what it is:
Partition > Label, and I typed BIOS_BOOT as the label.

Partition 2: For setting up the GRUB 2 files in /boot/grub
10 MB, ext2
Also, set the boot flag on this partition to make it the active partition:
Partition > Manage flags > check the boot box.
Set a label on the partition to remind you what it is:
Partition > Label, and type GRUB_FILES as the label.

Partition 3: A for-fun extra test partition for the heck of it. (In another test, I also tested creating 10 partitions, and it went well under GPT.)
200 GB, ext2

5 Install GRUB 2 to the flash drive
Exit GParted Live CD, remove the CD and the flash drive, reboot into your regular Kubuntu.
Plug in the flash drive. See how it is mounted (or go into Dolphin and click on the second partition GRUB_FILES to mount it). Open Konsole. install GRUB 2 to the flash drive, setting up the GRUB 2 files in the second partition (GRUB_FILES) and installing the bootloader (boot.img = 512 bytes) to the MBR of the flash drive.
Example:
Suppose the second partition is mounted as /media/GRUB_FILES and suppose the flash drive is seen as /dev/sdc in Kubuntu (use sudo fdisk -lu to find out). Then install GRUB 2 to it as follows:
sudo grub-install --root-directory=/media/GRUB_FILES /dev/sdc
If it doesn't go, do it again with --recheck:
sudo grub-install --recheck --root-directory=/media/GRUB_FILES /dev/sdc

6 Re-booting from the flash drive:
Make sure your BIOS is set to boot from USB and configure BIOS to boot from your flash drive.
If you re-boot starting from your Kubuntu session, keep the flash drive plugged in (but click Safely Remove to unmount it), reboot the PC, enter BIOS setup, configure BIOS to boot from USB and put the flash drive at the top of the drive list, F10 to Save & Exit, and re-boot from the flash drive. After the POST, you should see the GRUB 2 prompt (coming from the GRUB 2 on the flash drive): grub>. (You get the GRUB prompt grub> since there is no boot menu (/boot/grub/grub.cfg) configured.) You can use this grub prompt to boot into one of your OSs; or simply shutdown the PC (grub>halt) and remove the flash drive; or re-boot (grub>reboot), enter BIOS setup, remove the flash drive, set BIOS to boot from your regular drive, F10 to save this change and exit to reboot from your regular drive.


>>> Tips and Troubleshooting

Reminder
See the Section:
Requirements for using a GPT (kernel, bootloader, utilities, BIOS Boot Partition)

BIOS?
Your BIOS must support this. Strange thing on my machines. On my newer Intel DG33FBC motherboard, re-booting from the flash drive didn't work exactly as expected. Instead, BIOS by-passed the flash drive and booted from my regular drive, giving me my regular GRUB 2 boot menu with various OSs to choose from. I pressed the "c" key to get a GRUB prompt, grub>, explored the drives using grub>ls, saw my flash drive, let's say it was (hd1), and then I could reboot from the GPT flash drive using chainloader:
grub>set root=(hd1)
grub>chainloader +1
grub>boot
Amazing. (I got the grub> from the GRUB 2 GPT flash drive, then used it to boot into my regular Kubuntu 9.10 OS.) Yet it wouldn't re-boot normally from the flash drive.
However, my older machine (4 years back), a D915GAVL, would reliably boot from the GRUB 2 GPT flash drive every time!

I conclude that maybe the DG33FBC BIOS is either buggy or doesn't like something about the flash drive setup; normally, it boots easily from USB: but as I said, when coaxed by manually entering boot commands at the GRUB 2 prompt, the DG33FBC BIOS would boot from the flash drive. Also, at the time of this test, neither 9.10 nor GRUB 2 were in final released version yet.

Have you repartitioned anything on the GPT flash drive lately?
If you modify one of the GPT partitions using, say, GParted, e.g. by changing the size of a partition or moving it, the partitioning utility MAY overwrite the Protective MBR; thus you may have to re-install GRUB 2.
(=> To Do: To be tested fully)

The BIOS Boot partition: Notes
-- It really doesn't not require a filesystem, just the flag: boot_bios .
You can set that flag in GParted Live CD session: Partition > Manage Flags.
Or set it at the command line in Konsole:
sudo parted /dev/sda set <partition_number> bios_grub on

-- "unknown" filesystem!
You may get this warning if you look at your GPT flash drive in GParted Live CD (or using some other utility). If so, it's OK, ignore it.

-- To see what's in the BIOS Boot partition, you can use dd to print the first 62 sectors to the screen.
Example: Suppose the BIOS Boot partition is /dev/sdc2. Then:
sudo dd if=/dev/sdc2 count=62 | hexdump -C
(You probably can't read it, unless you've studied Starman!, but you can see that almost all those sectors are filled up to the end. A * or sequence ***** indicates a block of zeros--nothing there.)
-> You can experiment with this to satisfy yourself that core.img of GRUB 2 is embedded there. Use dd to zero out that partition, use dd to look at all the zeros in the first 62 sectors, re-install GRUB 2 to the flash drive, run dd again to have a look at those first 62 sectors.

[Qqmike]

Re: GRUB 2: A Guide for Users

Under Construction: Not ready until this line is removed.
(reserved reply)

[Qqmike]

Re: GRUB 2: A Guide for Users

Under Construction: Not ready until this line is removed.
(reserved reply)