Announcement

**Qqmike** · Apr 21, 2007, 12:48 PM

Re: HOW TO: GRUB Methods - Toolkit

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SECTION 7
Getting a copy of GRUB files

If you ever need a copy of GRUB files, you have four choices where to get them:
(1) The GRUB image files in the Kubuntu directory /usr/lib/grub/i386-pc
(2) Your regular Kubuntu operating system /boot/grub directory
(3) A Live CD that has them (like Super Grub Disk)
(4) A downloaded iso file (without burning a CD)

For each choice, you may do the work in graphical user interface--GUI (Konqueror/Dolphin) or command line interface--CLI (Konsole). You may copy the GRUB files without root privileges.

For example, in Kubuntu 8.04, the image files are these nine GRUB files for stages 1, 2, and 1.5, and for various filesystems:
stage1, stage2, e2fs_stage1_5, fat_stage1_5, stage2_eltorrito, jfs_stage1_5, minix_stage1_5, reiserfs_stage1_5, xfs_stage1_5.

GUI
If you need to work as root, you may open a file manager as root a follows:
in 8.10
kdesudo konqueror
kdesudo dolphin
in 8.04
kdesu konqueror
kdesu dolphin
Hidden files: There are no hidden files in a GRUB directory. However, if you are working in GUI, in many situations, you may want to enable “View > Show hidden files” (in Konqueror/Dolphin) before copying files; otherwise, you will not get the hidden files.

The /boot directory: Usually, to use GRUB files in booting, you must place the grub subdirectory (containing the GRUB files) under a boot directory, so the end result is /boot/grub.

CLI – notes, tips

cp -r /boot/grub directory1/boot
This copies the grub directory (under /boot) and its contents (the GRUB files) to directory1/boot as a subdirectory--it builds a new subdirectory of directory1 called grub; the end result is directory1/boot/grub, which contains all the GRUB files. This assumes you already created the boot subdirectory of directory1. The grub subdirectory of directory1/boot will be created by the command.

cp -r /boot/grub/* directory1/boot/grub
This copies the GRUB files contained in the directory /boot/grub into the directory you have already built and named directory1/boot/grub; the end result is directory1/boot/grub, which contains all the GRUB files.

Using root, sudo: depending on the task, you may need to work as root by prefixing cp with sudo:
sudo cp -r

mkdir: To make a new directory, use the command mkdir or sudo mkdir.

Super Grub Disk
You may get GRUB files from a Live CD that has them. Super Grub Disk is an example.
Let's assume you use a SGD live CD. Put the SGD CD in the CD tray, wait for Kubuntu to recognize it, then Open it. The GRUB files are at /boot/grub on the CD. Assume the CD is mounted as /media/cdrom0 (check this in your file manager).
CLI:
sudo cp -r /media/cdrom0/boot/grub directory1/boot
will result in directory1/boot/grub.

Downloaded iso file (without burning a CD)
Example
Super Grub Disk download
The CD ROM 0.9774 from here:
http://forjamari.linex.org/frs/?group_id=61
We download super_grub_disk_0.9774.iso to the Desktop folder, then mount it as follows:
sudo mkdir /media/SGDfiles
sudo mount -t iso9660 -o loop /home/your_name/Desktop/super_grub_disk_0.9774.iso /media/SGDfiles
cd /media/SGDfiles
ls
and you will see a boot directory;
cd boot
and you will see a grub directory
cd grub
ls
and you will see the grub files. To copy them into a /boot/grub subdirectory of directory1:
cp -r /media/SGDfiles/boot/grub directory1/boot
That will build directory1/boot/grub.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SECTION 8 Boot Methods: Rescue booting or by menu.lst
GRUB booting methods
--- Configfile
--- Chainloading
--- Booting directly
--- Boot into Kubuntu using the edit function “e” on a broken boot menu

--- Configfile
You can use configfile to boot into an OS at the GRUB command line or in /boot/grub/menu.lst.

Command line -- configfile
Find the Kubuntu partition containing a workable menu.lst
grub>find /boot/grub/menu.lst
From the results, select the partition (hdx,y) you wish to boot into. Put that here:
grub>configfile (hdx,y)/boot/grub/menu.lst
You will then be given the menu.lst from (hdx,y), from which you may choose an entry to boot into.

Menu.lst -- configfile
To boot into an OS which has a menu.lst on the partition (hdx,y) using configile, include the following boot stanza entry in your menu.lst:

title My OS on partition (hdx,y) booted by configfile
configfile (hdx,y)/boot/grub/menu.lst

--- Chainloading
You can use chainloader to boot into an OS at the GRUB command line or in /boot/grub/menu.lst.

Fact:
Chainloading: If you are going to chainload an OS, you must first install GRUB to that OS’s root partition. It does no harm to do this even if you also install GRUB elsewhere.

Booting your Kubuntu OS by chainloading at the grub> prompt
First, find the GRUB files:
grub>find /boot/grub/stage1
Suppose that returns (hdx,y), which you know to be your Kubuntu root partition. Use that here to install GRUB to the root partition of your Kubuntu OS:
grub>root (hdx,y)
grub>setup (hdx,y)
Then boot Kubuntu using chainloader:
grub>chainloader (hdx,y)+1
grub>boot
and you'll get from Kubuntu the boot menu /boot/grub/menu.lst.

Booting a hard drive (MBR) by chainloading at the grub> prompt
Let's say you wish to boot your hard drive hd1 (as an example).
First, find the GRUB files you wish to install to the MBR of hd1, install them there, then boot hd1 by chainloading:
grub>find /boot/grub/stage1
Suppose that returns (hdx,y), which you know to be your Kubuntu root partition. Use that here to install GRUB to the MBR of hd1:
grub>root (hdx,y)
grub>setup (hd1)
Then boot hd1 using chainloading:
grub>chainloader (hd1)+1
grub>boot
and you'll get from Kubuntu the boot menu /boot/grub/menu.lst.

Booting using the boot menu in Kubuntu, /boot/grub/menu.lst
Same thing, but you do not need the boot command:
title My OS on (hdx,y) booted by chainloading
chainloader (hdx,y)+1

title Hard Drive hd1 booted by chainloading
chainloader (hd1)+1

=> Both these menu.lst examples assumes GRUB has been installed to (hdx,y) or to (hd1) using the GRUB files from the Kubuntu partition (hdx,y).

--- Booting directly: using specific kernel & initrd statements
Use the specific kernel-initrd commands (as in a full menu.lst), ending with the boot command.
To get the kernel and initrd statements, try to access the menu.lst on the Kubuntu partition you wish to boot:
grub>find /boot/grub/menu.lst
That returns the partition (hdx,y) you are looking for. Use it here:
grub>root (hdx,y)
grub>cat /boot/grub/menu.lst
Write down the kernel & initrd statements you need to use next:
(as an example ...)
grub>kernel /boot/vmlinuz-2.6.24-23-generic root=UUID=4f8ed8da-e015-4149-954c-a353db1b284b ro quiet splash
grub>initrd /boot/initrd.img-2.6.24-23-generic
grub>boot

In an emergency, if you having problems and don't know the UUIDs of the root partition of Kubuntu, try using Linux device notation. For example, if Kubuntu is on (hd1,1) = sdb2, try this:
grub>kernel /boot/vmlinuz-2.6.24-23-generic root=sdb2 ro quiet splash
grub>initrd /boot/initrd.img-2.6.24-23-generic
grub>boot

Tab-completion in GRUB commands
Direct kernel booting at the GRUB prompt, grub>

First, find the partition (hdx,y) where you think your Kubuntu root files and kernel are. Use the methods discussed above to do that (geometry, or find /boot/grub/stage1, or find /boot/grub/menu.lst).
Example: Suppose you want to boot Kubuntu on (hd1,4) = sdb5. Use Tab-completion to try to get the kernel booted directly. In the Tab-completion below, do NOT type the symbol < or >.

grub> root (hd1,4)
then, you need a kernel:
grub> kernel /<Press Tab key>
That gives you some choices, from which you remember that the kernel is in /boot, so choose boot (and type boot):
grub> kernel /boot<Press Tab key>
You'll get a slash /
grub> kernel /boot/<Press Tab key>
and you get a list of choices, from which you remember that a Kubuntu kernel is called vmlinuz, so, again, type:
grub> kernel /boot/vmlinuz<Press Tab key>
and you get more choices. Keep playing with this until you get a full kernel, such as:
grub> kernel /boot/vmlinuz-2.6.20-16-generic
but before you press Enter you must pass the root device to the kernel. (hd1,4) is the same as sdb5, and don't forget to name it as a device:
grub> kernel /boot/vmlinuz-2.6.20-16-generic root=/dev/sdb5
Do the same thing to get the initrd file:
grub> initrd /boot/initrd.img-2.6.20-16-generic
Then, finally,
grub> boot
and off you go! You'll boot into that operating system using that kernel & initrd.
With Tab-completion, you keep trying, little-by-little, until you get where you want to be.

--- Boot into Kubuntu using the edit function “e” on a broken boot menu

You see a boot menu, but it doesn't work.

So, re-boot, get the boot menu again, and this time you can try to edit the boot menu to see if something will work. These edits are temporary!!! To make them permanent, you must access/edit menu.lst as root and make permanent changes (with File > Save, File > Quit). (See SECTION 4, menu.lst)

Example
Suppose you select "Kubuntu on sdb5" from the boot menu, and you know Kubuntu is there and you know that sdb5 = (hd1,4). But, you get an error, perhaps Error 15 File Not Found. Re-boot to get the boot menu again. On the boot menu, Highlight "Kubuntu on sdb5." Press "e" key to edit. Ha! There you see a line
root (hd1,3)
which you know should be
root (hd1,4).
Highlight root (hd1,3), press "e" key to edit, change it using arrow keys, backspace, delete, etc., press Enter to accept the final version, then press "b" to boot, and if you are right, it'll boot into Kubuntu on sdb5.

General procedure
Re-boot to get the boot menu.
Highlight the operating system your wish to boot.
Press “e” to edit its boot stanza entry in menu.lst.
Highlight the line (in menu.lst) you wish to edit.
Press “e” to edit that line.
After completing your edit, press Enter to accept the edit.
Then press “b” to boot. Or ...
If you need more information, press “c” to get a GRUB prompt
grub>
and use geometry, find, cat, etc. to gather more information about your drives, partitions, files.
(See SECTION 1: Getting information about drives, GRUB files, menu.lst, fstab, UUIDs, version #'s
IMPORTANT: Exploring your hard drive(s) -- fdisk, geometry, Tab-completion.)
Then,
at any time,
press the ESC key on your keyboard to return to the boot menu.
Highlight and edit (“e”) some more.
When done, “b” to boot (or, again, “c” to go back to a GRUB prompt, grub>, then ESC to come back to the boot menu).

The full instructions are listed at the bottom of the boot menu. They are easy to follow. You can't harm anything by trying. Worst case, you'll have to re-boot by pressing the Re-set button on your PC. You can also, at any time, type reboot at a grub prompt to reboot:

grub> reboot
or
grub> halt
to turn the PC off.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SECTION 9 Separate GRUB Partition
Making and using a separate GRUB partition

A separate GRUB partition contains only one item: /boot/grub and the GRUB files (contained under the grub directory). The partition does not contain any other boot files under /boot; the kernel and initrd files are not present. (A full /boot partition contains the kernel(s) and initrd files. That is a different subject and is not covered here. Basically, it is the same, except you must maintain the up-to-date kernel list correctly and edit your groot= (hdx,y) statement in menu.lst)

Advantages/uses of a separate GRUB partition:
-- If you install a lot of OSs, it is easy to manage the multi-booting and boot menu using a separate GRUB partition.
-- If you change the OSs on your partitions, it is easy to modify the boot menu if you use a separate GRUB partition (if you use configfile booting, you don't have to change anything).
-- In the separate GRUB partition, you do not have to use specific kernel and initrd statements; nor do you have to use UUIDs (which is nice in case you repartition your hard drive(s), and thus there is no need to edit your main boot menu.

Four steps: To build a separate GRUB partition and make your PC boot from it.
Step 1: Use a partition editor to make a small partition (1 MB is plenty; FAT32) that will become the GRUB partition.
Step 1: Make a /boot directory in the GRUB partition, and copy GRUB files into it so you have /boot/grub.
Step 2: Using those GRUB files, install GRUB to the Master Boot Record of the first BIOS boot drive.
Step 3: Edit the boot menu (/boot/grub/menu.lst) of the GRUB partition to suit your needs.

Example
Two SATA HDs, sda and sdb. Windows XP in sda1 = (hd0,0); Kubuntu 8.04 in (hd1,1); Kubuntu 8.10 in (hd1,2). The first BIOS boot drive is hd0, from which the PC boots. The GRUB that controls the booting is the GRUB in Kubuntu 8.04 (which is also the controlling boot menu, /boot/grub/menu.lst) (and so GRUB from (hd1,1) was installed to the MBR (hd0)).
To do: Make a separate GRUB partition in sdb1 = (hd1,0) to control the booting.
Note: In setting all this up, GParted Live CD (see REFERENCES) was used to do the partitioning, formatting, and then all OSs were installed as indicated.

Outline/tips

The partitioning is already done. The separate GRUB partition was created as sdb1 = (hd1,0), formatted FAT32 (or ext2 or ext3).
Boot into Kubuntu 8.04. (This can also be done from Kubuntu 8.10 or from a Live Kubuntu CD).
You can do this work in GUI (Konqueror or Dolphin) or CLI (Konsole, or a console).
If you do it in Konsole, you may wish to open your file manager as root:
in 8.10:
kdesudo konqueror
kdesudo dolphin
in 8.04:
kdesu konqueror
kdesu dolphin

While in Kubuntu 8.04, access the GRUB partition (hd1,0) (or sdb1). Make a directory called boot.
(In GUI: right-click, Create New > Folder, name it boot; in CLI: sudo mkdir /boot).

Copy grub and GRUB files into the GRUB /boot directory:
Again, from Kubuntu 8.04, copy the grub directory and its contents into the /boot directory of the GRUB partition (hd1,0) (or sdb1). The result in the GRUB partition is /boot/grub (with all the GRUB files under grub).

Set up GRUB:
Open Konsole, and install GRUB to the MBR of the first BIOS boot drive (hd0) using the GRUB files in your GRUB partition:
Konsole
sudo grub
grub>root (hd1,0)
grub>setup (hd0)
grub>quit
$exit

Edit menu.lst in the GRUB partition:
Edit the menu.lst in the GRUB partition (hd1,0) (or sdb1) to include boot entries for XP and the Kubuntu OSs.
You may open the menu.lst (in sdb1), as root, and delete everything (if you so wish). Then type the following:

# menu.lst for separate GRUB partition.
Default 0
timeout 10

title Windows XP in (hd0,0)
chainloader (hd0,0)+1

title Kubuntu 8.04 in (hd1,1)
configfile (hd1,1)/boot/grub/menu.lst

title Kubuntu 8.10 in (hd1,2)
configfile (hd1,2)/boot/grub/menu.lst

# End of menu.lst for the GRUB partition

That's it – Your are done
Re-boot to test it.

CLI: Konsole details
Here's the details at Konsole. The lines starting with # are comments.

# First, use GParted to make and format a new partition, sdb1= (hd1,0).
# Starting in the “main” Kubuntu in sdb2, at Konsole, proceed with:
# make a new directory for mounting sdb1
sudo mkdir /media/sdb1
# mount partition sdb1 on /media/sdb1
sudo mount /dev/sdb1 /media/sdb1
# make a /boot subdirectory in sdb1
sudo mkdir /media/sdb1/boot
# The next statement automatically makes a /grub sub-directory; then -r copies recursively
# all contents of the grub folder into the /boot/grub folder on sdb1
sudo cp -r /boot/grub /media/sdb1/boot
# open, as root, menu.lst on sdb1in text editor Kate
# in 8.10, use kdesudo; in 8.04, use kdesu:
kdesudo kate /media/sdb1/boot/grub/menu.lst
# Edit this menu.lst (see the text above)
# Then File>Save and File>Quit
# get a GRUB prompt as root
sudo grub
# install GRUB to the MBR of the first BIOS boot drive (hd0) using the GRUB files in the GRUB partition (hd1,0) (= sdb1)
grub>root (hd1,0)
grub> setup (hd0)
grub> quit
# to restart and test the new boot menu from sdb1
$ sudo shutdown -r now

Notes:

-- menu.lst: You may construct your menu.lst any way you wish, using kernel & initrd booting, chainloader booting, or configfile booting, or combinations thereof.

-- For configfile and chainloader, see SECTION 8.

-- Adding a new operating system; tips on installing it
If you install a new operating system, include it in your boot menu, /boot/grub/menu.lst in your GRUB partition. When you install the new OS, have the installer put GRUB in the same partition as the root (/) files of the new OS. Do NOT let the installer put GRUB in (hd0) (doing so would overwrite the GRUB that is already there from your GRUB partition). Then copy the boot entry for the new OS from the menu.lst there to the menu.lst in your GRUB boot partition (sdb1 in the above example). For a simpler method, see “Using configfile” below.

-- Kernel updates: Editing the boot menu.
If you update an OS on your drive, you must edit the menu.lst of the GRUB partition to reflect the new kernel reference. However, see the next subject--Using configfile.

-- Using configfile to simplify things; tips
Use configfile in the menu.lst of the GRUB partition for Linux operating systems. That way, you won’t have to manually update the kernel lines in the menu.lst of your GRUB partition each time there is a change/update in one of your OS kernels.
Example:
Suppose you have an instance of Kubuntu on sdb5. To boot to it from the boot menu on sdb1, as root, access /boot/grub/menu.lst on sdb1 and include the following boot entry for Kubuntu on sdb5:

title Kubuntu on sdb5 = (hd1,4)
configfile (hd1,4) /boot/grub/menu.lst

When you select this from the sdb1 boot menu, GRUB will show you the boot menu from sdb5, from which you then select Kubuntu again (or any other OS listed on the sdb5 menu.lst). That is, you will see two boot menus, the first one from the GRUB partition sdb1, the second one from the OS you chose to boot into. To make Kubuntu boot automatically and quickly from the second boot menu, edit, as root, /boot/grub/menu.lst on sdb5, to set the timeout to some small number of seconds (e.g., timeout = 2), but NEVER zero seconds!, and set the default = n to point at the Kubuntu on sdb5 (i.e, set n equal to the position of Kubuntu in the menu.lst, counting title lines starting at zero; usually, n = 0). You never want to set timeout = 0; if you did, you'd never be able able to select another OS, nor would you be able to interrupt the boot menu in an emergency (by typing “c”).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SECTION 10
Rescuing Your System, Emergencies, Fixing Boot problems
SGD, Emergency boot methods, Working from a Live Kubuntu CD
Options, strategies for accessing menu.lst and re-installing GRUB

This section is a quick summary if you have a boot emergency and don't know how to proceed. For an expanded version of troubleshooting tips, see Reply #22 (GRUB Boot--Rescue Methods; How to Boot Into Your Operating System in an Emergency, and some tips on fixing the problem).

Rx: Either fix menu.lst, and/or re-install GRUB
If your PC does not let you boot into your operating systems, one of two GRUB components must be fixed: the boot menu, /boot/grub/menu.lst; and/or you must re-install GRUB (to the first BIOS boot drive (hd0)).

Two ways to do this work: boot into Kubuntu; or use a Live Kubuntu CD
You may do this work either booted into ANY one of your Kubuntu/Linux OSs or from a Live Kubuntu CD.
Suppose you can't boot into any of your Kubuntu/Linux OSs.
=> Then, you must use a Live CD to try to fix GRUB.
Suppose you can't boot into your “main” Kubuntu, but you can boot into another of your Kubuntu/Linux OSs.
=> You can fix GRUB from any Linux OSs you are able to boot into.
=> You can use Konsole (terminal) and/or Konqueror/Dolphin.
Suppose you can boot into your “broken” Kubuntu.
=> You can then use Konsole and/or Konqueror/Dolphin to fix the problem.

Emergency boot methods:
Ways to (try to) boot into your Kubuntu OS (or any of your Linux OSs) where you can then try to fix the problem)

SGD gets you in fast
If you need to boot into your Kubuntu, try Super Grub Disk Live CD:
Super Grub Disk: http://www.supergrubdisk.org/

Boot into Kubuntu from a GRUB prompt, grub>
Three ways to get a GRUB prompt, grub>:
1 After BIOS POST, when the GRUB boot menu appears, press the “c” key. (Press ESC to go back to boot menu)
2 If you do not have a workable menu.lst, but GRUB is setup, after the POST, you’ll get a grub> prompt instead of menu.lst.
3 Use a rescue disk (Super Grub Disk ), press the “c” key when prompted
Then:
When you get the GRUB prompt, grub>, try to boot into Kubuntu using these methods:
configfile
chainloader
direct kernel booting
using the edit function “e” on a broken boot menu

=> See SECTION 8 for these methods.

Fixing the problem from inside Kubuntu
Fixing the problem assuming you are able to boot into the broken Kubuntu OS (using one of the Emergency boot methods above). How to re-install GRUB, and how to access menu.lst:

Re-install GRUB (from inside Kubuntu at Konsole)
-- Re-install GRUB to the MBR of the first BIOS boot drive (hd0) using GRUB files from your Kubuntu partition.
Open Konsole
sudo grub
grub>find /boot/grub/stage1
# then, if necessary, determine which partition (hdx,y) Kubuntu is in
# using grub>geometry (hd1), grub>geometry (hd2); etc.
# Put the correct (hdx,y) here:
grub>root (hdx,y)
grub>setup (hd0)
grub>quit
$exit

-- To install/re-install GRUB to the MBR of a non-first HD, do the same, except use
grub>setup (hd1) (or grub>setup (hd2), etc.) (Applies to external HDDs and flash drives)

Fixing menu.lst (from inside Kubuntu)
-- Using Konqueror or Dolphin:
Open Konqueror/Dolphin as root, then do the edits:
in 8.10: kdesudo konqueror (or dolphin)
in 8.04: kdesu konqueror (dolphin)
Then, from the file manager, access/edit menu.lst, make your edits, then File>Save and File>Quit.
-- Using Kate (to open menu.lst as root):
in 8.10: kdesudo kate /boot/grub/menu.lst
in 8.04: kdesu /boot/grub/menu.lst
Then, make your edits, and File>Save and File>Quit.

Fixing the problem using a Live Kubuntu CD
Fixing the problem assuming you wish to use or you must use a Live Kubuntu CD. How to re-install GRUB, and how to access menu.lst:
Boot the Live Kubuntu CD, start a live session (i.e., do not “Install”), open Konsole.

Re-install GRUB (from the Live Kubuntu CD at Konsole)
-- Re-install GRUB to the MBR of the first BIOS boot drive (hd0) using GRUB files from your Kubuntu partition.
sudo grub
grub>find /boot/grub/stage1
# then, if necessary, determine which partition (hdx,y) Kubuntu is in
# using grub>geometry (hd1), grub>geometry (hd2); etc.
# Put the correct (hdx,y) here:
grub>root (hdx,y)
grub>setup (hd0)
grub> quit
# If that's all you have to do, you may exit
# Or, you may continue, and access menu.lst for editing ...

Fixing menu.lst (from the Live Kubuntu CD at Konsole)
=> As root make a “mount” directory, mount the filesystem containing the menu.lst you need to edit, open menu.lst as root, edit it, save, quit, unmount the filesystem, exit.
# to identify which partition contains the menu.lst (and your Kubuntu):
sudo fdisk -lu
# Example: let's suppose it is sdb3
# 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
#
# Now, you may use a file manager or a text editor (Kate) to access menu.lst and make edits:
# (Choose your method; do NOT use the comment signs #.)
#
# Open Konqueror/Dolphin as root, then do the edits:
# in 8.10: kdesudo konqueror (or dolphin)
# in 8.04: kdesu konqueror (or dolphin)
# Access /boot/grub/menu.lst
# Make your edits, then File > Save, File > Quit
#
# Or,
# Open menu.lst as root using Kate, then do the edits:
# in 8.10: kdesudo kate /boot/grub/menu.lst
# in 8.04: kdesu kate /boot/grub/menu.lst
# Make your edits, then File > Save, File > Quit
#
# After making edits to menu.lst:
# unmount the directory; note the spelling of umount:
sudo umount /media/sdb3
$ exit

**Rog131** · Jun 15, 2007, 12:46 PM

Re: HOW TO: GRUB Methods - Toolkit

A gui to edit grub:

StartUp Manager, or SUM, is a gui tool for changing settings in the bootloader and splash screen in ubuntu.

also in the kubuntu

Homepage:
http://web.telia.com/~u88005282/index.html

Ubuntu Forums:
http://ubuntuforums.org/showthread.php?t=295524

Note:
SUM seems to work BUT a good advice: Read Qqmike's

The boot menu: /boot/grub/menu.lst How to access, back up, and edit

and especially

Case 2: Live OS CD method: Use this (or Super Grub Disk) if you are not able to boot into any of your Linux OSs to access/edit the menu.lst.

**dibl** · Jun 15, 2007, 03:56 PM

Re: HOW TO: GRUB Methods - Toolkit

Wow -- Qqmike, my hat is off! Thank you very much for taking the time to write it out.

I presently boot 4 OS's, on 1 PATA and 2 SATA drives. Keeping the Grub menu correct is quite a feat, and I could have used this instruction, rather than figuring it out the hard way(s).

I appreciate the effort that went into this!

**askrieger** · Jun 15, 2007, 04:20 PM

Re: HOW TO: GRUB Methods - Toolkit

As anyone who has perused their /boot/grub/menu.lst file lately has noticed, life has gotten a little more complicated lately (in Feisty). In order to compensate for removable drives switching their device numbers, (*)buntu is now using UUIDs to identify partitions in menu.lst! Thus what used to be "root=(hd0,0)"<==hda1 (or sda1) in the good old days, is now "root=UUID=67cc8394-6917-48b5-9e8f-ddfd06cc9c2b" Curiously enough, that doesn't apply to windoze partitions which still have the old-style designation. However, this must be taken into account when messing around with GRUB! . It is now much easier to crash your system. Backing up first is now even more important than before. BE WARNED

**Qqmike** · Jun 16, 2007, 06:49 AM

Re: HOW TO: GRUB Methods - Toolkit

Yes, about the UUIDs, also about sdx naming (the old hdx is now being called sdx, and you may need to check your x’s, too). Here’s a brief discussion about this at another forum I hang out at (hardwareguys as mikemqa):

http://forums.hardwareguys.com/ikonb...ST;f=12;t=5440

- - - - -

Herman’s bigpond reference is at:

Bigpond, home: http://users.bigpond.net.au/hermanzone/
(under Filesystems and Mounting)

where he lists some useful things, like:
“ . . .this command, (below), will give a whole list of your partitions and their UUIDs,

herman@edgy:~$ ls /dev/disk/by-uuid/ -alh . . . “

- - - - -

Vista and GRUB?

Another topic I haven’t really nailed own, but only see all the many mentions of it popping up everywhere, is how Vista plays with GRUB. We know the Vista bootloader has changed (not the NTLDR).
A really good contribution would be to have a brief How-To on that. I don’t use Vista, so it’s difficult to experiment! Maybe Herman will do some work on that.
I’ll post that issue at the Super Grub Disk mailing list for fun and see if anything comes up.

- - - - -

Finally, dibl thanks much for your thanks and kind words. (I’ve quoted you many times re GRUB on mixed SATA and IDE drives.)

And thanks Rog131 and thanks askrieger for your interest/comments here, too.

**Qqmike** · Jun 16, 2007, 12:59 PM

Re: HOW TO: GRUB Methods - Toolkit

Two new subjects:

UUIDs (in Feisty’s filesystem table, fstab)

Windows Vista dual-booting issues

-- EDIT: Vista and Linux. I've added another post below on July 17, 2007 on dual booting Vista and Linux, and some related subjects.

-- Please consider this post to be work-in-progress as I get new information

- - - - - - - - - -

UUIDs

Summary: How the “kernel” lines of the /boot/grub/menu.lst are changed to reflect the new UUID’s for naming devices, starting with Feisty.

With Feisty, the fstab (filesystem table) uses UUIDs (unique device identifiers) instead of sda, sdb, etc., to name devices.

To see your UUIDs, use these commands:
-- From a live Cd or drom a hard-disk installed OS:
$ ls /dev/disk/by-uuid/ -alh
(Note: “ls” is “l” as in “list”; and “-alh” is also with an “l” as in”list”)
-- From only a hard disk-installed OS:
$ blkid

This change is at the operating system level. It is not a change in GRUB (or some other place).
But it affects how GRUB passes the root device to the operating system in the kernel line of the GRUB configuration file (ie, in /boot/grub/menu.lst).

Example

Suppose the old or previous fstab entry is:
/dev/sdb3 /media/sdb3 {followed by all the options}
And it changes (in Feisty) to:
UUID=7f4c701f-1ad2-4781-83e5-2bd423cc8g44 /media/sdb3 {options}

So then, for GRUB:
The configuration file, menu.lst, passes the root to the kernel for the root filesystem, as in:
root (hd1,2)
kernel /vmlinuz-2.6.17-10-generic root=/dev/sdb3 {all the kernel options}
initrd /boot/initrd.img-2.6.17-10-generic

Since fstab changed the naming of /dev/sdb3, so must the kernel command be changed as follows:
root (hd1,2)
kernel /vmlinuz-2.6.17-10-generic root=UUID=7f4c701f-1ad2-4781-83e5-2bd423cc8g44 {kernel options}
initrd /boot/initrd.img-2.6.17-10-generic

(End of the Example)
- - - - -

When you change things on your disks, check your UUIDs in fstab and menu.lst . . .

Herman (bigpond) reminded me about something else:
When you make changes to your partitions, when you edit them, or change any filesystem types, or reformat partitions, whatever, you should check to see which UUIDs have changed as a result. So you should check it as follows --
Use the command to check your UUIDs ( ls /dev/disk/by-uuid/ -alh ), and check your filesystem table (fstab) to make sure everything (partitions and UUIDs) is correct. Then, your menu.lst references (to UUIDs) should be checked.

- - - - -

UUID, a note about hdx and sdx’s:

In the past, in Linux notation (eg, in fstab), hard drives were designated hdx (for IDE/PATA drives) and sdx (for SATA drives).
I have read (and seen one example in Feisty) that the old hdx is gone for IDE/PATA hard drives. PATA drives that used to be hdx are now sdx. Drives that used to be sdx are still sdx but the x is likely to be different.

- - - - - - - - - -
- - - - - - - - - -
Windows Vista
notes

EDIT: I've added another post on July 17, 2007 (see below) on dual booting Vista and Linux, and some related subjects.

Issue #1: Chainloading Vista from Linux, using GRUB

Instead of the three lines (in /boot/grub/menu.lst) for Windows:
root (hd0,0)
chainloader +1
boot

. . . use these three lines for the Vista boot entry in menu.lst:

rootnoverify (hd0,0)
chainloader +1
boot

Issue #2: Chainloading Linux from Vista

There are problems when people want to chainload Linux from the new Vista bootloader.
This topic is not covered here, anyway, but a note is made here about it.
(Previously, people found various ways to chainload Linux from the Windows “old” bootloader NTLDR and the boot.ini file.)

- - - - - - - - - -

References:

Thanks to askrieger (post above) for raising the issue of UUIDs in Feisty.

Many thanks to the Super Grub Disk mail list owner and members. You can find what I’ve said here and other good GRUB stuff in the archives:
SGD Archives: https://listas.ensanjose.net/pipermail/supergrub/
(say OK to any certificates etc.)

Thanks to Herman at bigpond ( http://users.bigpond.net.au/hermanzone/ ) for the command for finding your UUIDs in fstab, $ ls /dev/disk/by-uuid/ -alh .

I ripped the following references from our Kubuntu forum where we were trying to assist someone.
Some more info/detail/aspects of this UUID subject.
http://www.penguin.ch/dokuwiki/doku....:k_0704:revert
and USB tacking (interesting):
http://www.penguin.ch/dokuwiki/doku....ab#usb_tacking
reasoning behind the UUIDs:
https://wiki.ubuntu.com/LibAtaForAtaDisks

**penguin.ch** · Jun 16, 2007, 01:09 PM

Re: HOW TO: GRUB Methods - Toolkit

Originally posted by askrieger

(*)buntu is now using UUIDs to identify partitions in menu.lst

Interestingly enough, (a.o. Feisty's) device.map sticks to traditional notation ... Am I supposed to understand that?

**askrieger** · Jun 16, 2007, 02:19 PM

Re: HOW TO: GRUB Methods - Toolkit

"Consistency is the hobgoblin of little minds." R.W. Emerson (or something like that, by someone like that)

**Qqmike** · Jun 16, 2007, 02:24 PM

Re: HOW TO: GRUB Methods - Toolkit

I’m not sure about that (Edit: what UnicornRider said above). In fact, sometimes, I feel I’m not sure about using device.map at all, to be honest. It's been a bit confusing to me.

As we all know, BIOS sees drives in a certain way, GRUB sees them as BIOS does, and Linux sees drives in its own certain way. The correspondence between how BIOS sees HDDs and how Linux grub shell (what you see when you type grub at bash prompt -- not the GRUB menu that you see when you boot your computer) sees them is defined by the mapping table in /boot/grub/device.map.

For example, the native GRUB (the one you see when you boot the computer, and the one that shows you your boot menu from menu.lst) sees as hd0 the first hard disk from the BIOS point of view. The file device.map is not read at all. That is, the native GRUB bootloader does not see the device.map.

These device.map settings are useful so that the grub shell can read it and the data are correct; for example, when grub-install is run, and the grub shell is used, the device.map is read, so the map table there must be correct or an error or a message occurs. As an example, if you invoke the grub shell, and if no /boot/grub/device.map is found, you’ll get the message: "Probing devices for getting BIOS devices … this may take awhile." However, if there's a /boot/grub/device.map, the grub shell reads it. Also, once you are in the shell you can use the device command to override "device-grubdrive" mappings. (This info was paraphrased from a Super Grub Disk mail list member’s post and other notes.) The GRUB manual describes this grub shell in Section 15.

*****
EDIT:
***** See Reply #20 below for more on the subject of device.map and the grub shell in Kubuntu. *****

**Qqmike** · Jul 08, 2007, 04:04 PM

Re: HOW TO: GRUB Methods - Toolkit

How to make a separate, dedicated “GRUB partition.”
Make a partition dedicated to the GRUB files and make your PC boot from those GRUB files.

Changed:
This topic has been deleted in this post.
It has been re-written/improved and included in SECTION 9 of the original post (and appears in Reply #1 above)

For the Table of Contents of the GRUB toolkit, see the original post (above).

**Qqmike** · Jul 17, 2007, 10:05 AM

Re: HOW TO: GRUB Methods - Toolkit

Vista -- Linux Dual Boot
(Also, some Vista – XP issues)

This is a conceptual, birds-eye summary of methods taken from the following excellent source:
The Definitive Dual-Booting Guide: Linux, Vista and XP step-by-step: http://apcmag.com/node/5162/

Notes & Disclaimer: For actual, step-by-step details, with screenshots, see the Guide. It’s hard to improve upon what they’ve done there, and it seems to be well maintained and tested. The reader comments following each tutorial are very useful, too. As of today, this Guide is the most visible, easiest to read, and generally the best I could find in a 3-minute google scan. The Guide is being continually revised and expanded. (I’m not connected with the Guide. I’m just doing some research/summarizing and sharing it with you so you have a concise, conceptual summary of methods, what’s involved, and what your choices are.)

- - - - - - - - - -
Vista and Linux

When Vista is already installed first, then you install K/Ubuntu (the easiest case):

1 Use the Vista Disk Management utility to shrink the Vista partition. That leaves a lot of unallocated space.
2 Two choices now:
Make partition(s) in the unallocated space using GParted Live CD, then install K/Ubuntu,
Or,
Simply just proceed to install K/Ubuntu in the unallocated space using the manual partitioning method of the K/Ubuntu installer ("Manual - use the largest continuous free space").
3 GRUB will overwrite the MBR and take over the boot management.
4 Optional: Access /boot/grub/menu.lst in K/Ubuntu to edit the boot menu for the default OS, the timeout, or to edit the title lines.

When K/Ubuntu is already installed first, then you install Vista:

1 If the existing K/Ubuntu takes up the entire disk, use GParted Live CD to shrink the existing K/Ubuntu partition. In the freed-up space, do whatever other partitioning/editing you wish to do now.
Still in GParted now:
-- If you want the Vista bootloader to take over the booting, then note that “… [the K/Ubuntu partition] is marked as a boot partition, and this means that the Vista installation won't work properly while there's a bootable non-Windows partition on the system. Remove the boot flag and click Close.”
-- If you will instead have GRUB control the booting, then leave the boot flag in place.

2 Install Vista in the newly created space (or partition you made for it).

3 In Step 2, the Vista bootloader overwrote the MBR. So now you have to fix the bootloader.
Two choices:

-- If you want GRUB to control the booting, then use the K/Ubuntu Live CD to re-install GRUB to the MBR. This requires the easy and familiar steps: root (hdx, y), setup (hd0), quit, where the GRUB files are located in (hdx, y) (which is also where you may have put the K/Ubuntu root files). Then check to see if you also need to or wish to edit the boot menu (/boot/grub/menu.lst).

-- If you want the Vista bootloader to control the booting, then proceed as follows:
First Step:
Re-install GRUB to the K/Ubuntu * boot partition * (where /boot/grub/stage1 is located; NOT to the MBR). This requires the steps: root (hdx, y), setup (hdx, y), quit. (Normally, (hdx, y) will probably be (hd0, 0) for most standard K/Ubuntu installations.) Doing this ensures that the Vista bootloader can load K/Ubuntu by loading GRUB and passing control to it.
Second Step:
In Vista, download and install the EasyBCD.
Use EasyBCD to add an entry for K/Ubuntu, using the same partition (hdx, y) you used in the First Step above.
- - - - - - - - - -

Vista and XP – a few notes

“…. if your boot loader is a Microsoft only one, and the installer detects that it is a newer version than the one it is installing, it leaves it intact.”
“… Vista recognises (sic) that XP is installed and takes over booting it with no fuss…”
http://www.apcstart.com/3895/how_vis...ooting_nirvana

This is consistent with the following expected * principle *:
“. . . Things are a little better starting with Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1, though. Those and future versions of Windows setup check the version of the NTLDR file and will leave a newer version of the boot loader intact rather than overwriting it with an older version.”
(From a Windows blogger about how Windows overwrites boot sectors:
http://blogs.msdn.com/oldnewthing/ar...20/505887.aspx )

- - - - -
XP and Vista -- Overview of two install cases:

-- XP is on your system, then you install Vista:
If you need to shrink the XP partition, try first to use the utility on the Vista CD (DISKPART). If it won’t go, then use GParted Live CD to shrink it. Then install Vista. The Vista bootloader will automatically recognize and include XP for booting. Download and install Easy BCD. Edit the Vista bootloader as desired (usually for cosmetics only). (EasyBCD is a GUI for the command line BCDEDIT utility; EasyBCD may be easier to use than the CLI.)

-- Vista is already installed, then you install XP:
If Vista’s partition needs to be shrunk to make room for XP, load Vista, and use its utility (DISKPART) to do so. Then install XP in the partition you created for it. XP will overwrite the MBR, so Vista can’t boot now. Then re-install the Vista bootloader to the MBR (using the Vista DVD, Repair Your Computer, System Recovery Options, etc.). Download and install Easy BCD. Use Easy BCD to edit the Vista bootloader to Add and Entry for XP. See the Guide for other issues (like if the Windows XP bootloader corrupts during the install and fixing it).
- - - - -

Notes and References

Other Cases:
See the tutorials, especially the reader comments following each tutorial.
Example: Same hard drive or two hard drives? Try it on two. Many readers have done so successfully without major issues.

EasyBCD, download:
http://neosmart.net/dl.php?id=1
(EasyBCD is third-party GUI front end to the BCDEDIT bootloader command-line editor in Vista.)

For basic GRUB methods (editing the boot menu; re-installing GRUB), use the first post and following posts of this "How To GRUB Methods - Toolkit" you are reading right now.

GParted Live CD:
http://gparted.sourceforge.net/livecd.php.
http://sourceforge.net/project/showf...kage_id=173828
(Note: GParted is also included as a system application in K/Ubuntu 7.04, System > Administration > GNOME Partition Editor, but it’s also handy to have a copy of the GParted Live CD).

**Qqmike** · Jul 24, 2007, 10:20 AM

Re: HOW TO: GRUB Methods - Toolkit

Install Windows XP *after* Kubuntu, and assume
You install XP to a non-first hard drive
- - - - - Question: How do you setup/edit GRUB so it boots either your Kubuntu or your XP?

Changed:
This topic has been deleted in this post.
It has been re-written/improved and included in SECTION 6 of the original post (and appears in the first post above).

For the Table of Contents of the GRUB toolkit, see the original post (above).

**Qqmike** · Aug 18, 2007, 05:12 AM

Re: HOW TO: GRUB Methods - Toolkit

Install Kubuntu 7.04 to an external USB hard drive: How to.

If I may, for people who ended up here, I’d like to cross reference the Thumb Drive How-To where I added a new post:

How To Make GRUB Thumb Drive
http://kubuntuforums.net/forums/inde...opic=3081748.0
*** New posting:
How to install K/Ubuntu 7.04 to an external USB hard disk drive (HDD).
(Scroll to the second post, August 14, 2007.)

Installing to an external USB HDD involves the same BIOS and GRUB issues you encounter when building a bootable USB Flash Drive (UFD) or thumb drive.

**Qqmike** · Aug 19, 2007, 10:47 AM

Re: HOW TO: GRUB Methods - Toolkit

Separate, dedicated GRUB partition--Another example.

Changed:
This topic has been deleted in this post.
It has been re-written/improved and included in SECTION 9 of the original post (and appears in Reply #1 above)

For the Table of Contents of the GRUB toolkit, see the original post (above).

Announcement

HOW TO: GRUB Methods - Toolkit

HOW TO: GRUB Methods - Toolkit

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment