Showing posts with label boot. Show all posts
Showing posts with label boot. Show all posts

Sunday, September 27, 2009

Boot your USB Drive in VirtualBox

The GUI of VirtualBox does not have an option to boot a USB drive (Physical Drive) in a virtual machine.

However you can attach a physical drive to a virtual machine using a command line tool that is bundled with Virtual Box.You can then boot your virtual machine from the attached Physical drive.

This is the continuation of my previous article.You can read more about bootable usb drives in my previous article.

In this article I will show you how you can boot a bootable usb drive in Virtual Machine created by VirtualBox.You can easily test bootable USB drives within Windows and without restarting using this method.

Warning:Do not Attach your Primary hard disk to your Virtual Machine and Boot it in the Virtual machine

Download and install Virtual Box from here http://www.virtualbox.org/wiki/Downloads

Attaching a Physical Disk to a Virtual Machine

Section 9.10 in the VirtualBox manual contains all the details required to attach a physical disk to a virtual machine.Using the vboxmanage.exe tool you can create a tiny vmdk file which points to your real USB drive (Physical Drive/Disk).You can attach this tiny vmdk to your virtual machine.A vmdk file is a virtual hard disk file which can be used with VirtualBox and VMWare.

The vboxmanage.exe tool is bundled with VirtualBox.You don’t have to download it separately

Open Command Prompt

Navigate to your Virtual Box installation Directory.

cd c:\”Program Files”\Sun\”xVM VirtualBox”

Type the following command and press enter
Syntax of the command
VBoxManage internalcommands createrawvmdk -filename path\to\usb.vmdk -rawdisk \\.\PhysicalDrive1 -register
Example
VBoxManage internalcommands createrawvmdk -filename c:\Users\Agni\.VirtualBox\VDI\usb.vmdk -rawdisk \\.\PhysicalDrive1 -register

You have to replace path\to\usb.vmdk with the path to your VDI folder(Where all your virtual hard disks are stored).If you want to save your usb.vmdk in different location,then you will have to add the usb.vmdk file manually in the GUI.This is because the register switch only registers the virtual hard disks stored in the User ’s VDI folder .

In windows your 1st Hard Disk will be \\.\PhysicalDrive0.Your 2nd Hard disk will be \\.\PhysicalDrive1.

To find the correct number for your USB Drive

Right Click on My Computer-Manage-Disk Management

Here you can find the correct disk number of your USB Drive

Drive Number of the Physical Drive

Drive Number of the Physical Drive

You will have to replace \\.\PhysicalDrive1 with the correct drive number.

In this case there was only 1 hard disk and 1 USB disk.So the USB drive is referred by \\.\PhysicalDrive1

In linux you have to replace \\.\PhysicalDrive1 with the correct /dev/sda reference.

Now you should have a tiny vmdk file.You can start your Virtual Machine with this tiny vmdk and boot from it.

  1. Start VirtualBox.
  2. Create a new Machine or Select an Existing Machine.
  3. Settings-Hard Disk-Add-Select usb.vmdk
  4. Make sure that usb.vmdk is your Primary Master.


  5. System-Boot Order.Set your Hard Disk as the first boot device.

    Boot Order

  6. Now start your Virtual Machine.

Your virtual machine will boot from your bootable physical hard disk.

In this screenshot I have used a bootable Ubuntu USB drive created using Unetbootin.



Read more: http://agnipulse.com/2009/07/boot-your-usb-drive-in-virtualbox/#ixzz0SHfDD0LD

Wednesday, March 18, 2009

How to fix Linux boot problems

Booting, or "bootstrapping" for us older folk, is that deeply mysterious sequence of operations performed by your computer between the moment when you switch it on and the moment it's ready for you to log in. During this time, all kinds of incomprehensible messages scroll up the screen, but they're not something you usually take much notice of, and most linux distros cover them up with a pretty splash screen and a nice encouraging progress bar. This is all fine, of course, until it stops working. In this tutorial we'll examine the boot process in more detail, looking in particular at what can go wrong, and how to diagnose and fix the problem.

Grokking the problem

When I'm teaching Linux on one of my courses, many attendees tell me they are interested in troubleshooting of one form or another. Some of them are looking for a cookbook approach - "If you see the error message X, run command Y", but troubleshooting rarely works that way. My initial advice to anyone who needs to troubleshoot is always the same: "The most important thing in troubleshooting is to understand how the system is supposed to work in the first place. The second most important thing is figuring out exactly what the system was trying to do when it went wrong."

Figure 1: the normal sequence of events when booting Linux.

Figure 1: the normal sequence of events when booting Linux.

With this in mind, let's take a look at how Linux boots. Knowing the normal sequence of events, and determining how far it got before it ran into trouble, are key to diagnosing and fixing boot-time problems. Figure 1 above, right shows the normal sequence of events (green arrows) and indicates some of the possible failure paths (red arrows).

Picking yourself up by your bootstraps

Booting is a multi-stage affair. When a PC is powered up, control initially passes to a program (called the BIOS) stored in read-only memory on the motherboard. The BIOS performs a self-test of the hardware and scouts around looking for a device to boot from. The BIOS provides configuration screens that allow you to assign the order in which it searches for a bootable device, and modern BIOSes support a wide range of boot devices, including PXE booting from a network server. The only case we consider here is booting from the hard drive.

The BIOS loads the Master Boot Record (MBR) of the selected boot device and executes it. (If this fails, the BIOS will report something like "Missing Operating System", and come to a screaming halt.) The MBR occupies the very first sector of the drive. It holds the drive's partition table (64 bytes) and a very short program (446 bytes) which is 'stage 1' of the bootstrap loader.

This stage 1 loader is pretty dumb - all it does is to display the word GRUB on the screen then load a second stage boot loader using a 'block map' that is embedded into the MBR. (The block map specifies the disk block numbers where the second stage loader resides). I'm assuming here that we're using the Grub boot loader. There's an earlier boot loader called Lilo, but Grub is more recent, smarter, and used in most modern Linux distros. The second stage of the Grub boot loader is actually called stage one-and-a-half, and if you list the directory /boot/grub you can see the files that contain the various versions of this; they have names like e2fs_stage_1_5 and reiserfs_stage_1_5.

Each of these programs is able to access files by name using one particular filesystem format. e2fs_stage_1_5 can read ext2 and ext3 filesystems, and reiserfs_stage_1_5 can read reiser filesystems, and so on. Grub's ability to access files by name at boot time (before linux is running) is the thing that really sets it apart from Lilo. The stage one-and-a-half program loads Grub stage 2 which is considerably larger. This stage reads the Grub configuration file (usually /boot/grub/menu.lst or /boot/grub/grub.conf) and, based on the entries it finds there, it presents a menu of choices of the operating system you want to boot. If Grub can't find its config file it will drop down to an interactive command-line prompt to allow you to enter Grub commands manually.

A typical entry in menu.lst looks like this:

title openSUSE 10.2
root (hd0,0)
kernel /boot/vmlinuz-2.6.18.2-34-default root=/dev/hda1 vga=0x317 showopts
initrd /boot/initrd-2.6.18.2-34-default

The title line simply specifies the text that will appear in Grub's boot-time menu. The lines that follow specify the commands that Grub will execute if you select that item from the menu. The root line sets Grub's idea of where the root filesystem resides. Grub has its own way of naming disk partitions which is confusingly different from the naming scheme used by Linux.

In Grub-speak, hd0 refers to the first drive - on a typical PC with IDE drives this corresponds to the Linux device name /dev/hda, or, in some of the more recent distros, /dev/sda. In Grub-speak, (hd0,0) refers to the first partition on that drive. Linux would call this /dev/hda1 or /dev/sda1. The kernel line specifies the file that Grub will load as the Linux kernel; at the end of this line you may see some additional boot parameters that are passed to the kernel. More about these later.

The initrd line specifies the file that contains the 'initial RAM Disk' - a file system image that will be used by the kernel as it boots. Grub is also responsible for loading this file into memory. If Grub fails to find the kernel or the ramdisk images it will report Error 15: File not found, and halt.

Once the kernel starts running, it mounts the root file system from the hard drive. The name of the partition that holds this file system is passed as a parameter to the kernel, as you can see from the menu.lst entry above. Mounting the root file system is a key point in the boot process and if you're trying to pin down a boot-time problem it's vital to figure out if the kernel was able to get this far. Failure to mount the root file system will generally result in a kernel panic, though some systems just appear to halt.

If the kernel succeeds in mounting the root file system, it creates a single process (with process ID 1) which runs the program /sbin/init. If the kernel can't find init, it will either panic and halt or (depending on the distro) drop you into a root shell. Oh, by the way, just to add a little confusion, Ubuntu doesn't use init any more, it uses a replacement called upstart.

The program init is responsible for running the scripts that will start all the other services in the system. There is one important and rather low-level script run by init early in the process. On Red Hat-style systems it's /etc/rc.d/rc.sysinit, on SUSE it's /etc/init.d/boot. Among other things, these early scripts consistency-check and mount any other disk partitions, as specified in /etc/fstab. Although there is certainly plenty of scope for things going wrong at this stage, we need to leave the story at that point, at least for this month.

Getting to grips with Grub

A key skill in fixing boot-time problems is knowing how to manually intervene in the Grub boot sequence. Most distros configure Grub to boot a default choice from the menu, but allow a short time window (a few seconds) in which you can press Esc to interrupt this and gain direct control of Grub. Typically this will exit from the Grub splash screen and drop to a character-based menu.

From here, follow the on-screen instructions to select an item from the menu, and edit the commands associated with that menu selection before booting. It's even possible to drop down to a Grub command prompt where you can enter Grub commands directly; for example at this point you could, in theory, manually enter the root, kernel and initrd lines from the menu.lst file we looked at earlier. Figure 2 (below) shows the result of typing help at the Grub command prompt.

Figure 2: the result that is output when 'help' is typed at the Grub command prompt.

Figure 2: the result that is output when 'help' is typed at the Grub command prompt.

Rescue Booting

If no amount of tweaking with the Grub boot commands will allow your system to boot, it may be time to perform a 'rescue boot', which means that you'll boot Linux from an installation CD or other 'rescue media'. The kernel and its modules are loaded off the CD, along with a small file system that is built in memory. This results in a small but working Linux system that isn't dependent on any file systems on the hard drive.

You can then mount the hard drive's partitions into the file system and access them to repair the damage. The installation DVD or CD of almost any modern Linux distribution can be used for this purpose - there is no requirement that the rescue media is from the same distribution as the one you're trying to rescue.

It's important to keep a clear head when using a rescue system because the files on your hard drive won't be in the same place when they are mounted into the rescue system as when they're viewed by the 'real' installation. For example, if in the rescue system I were to mount my system's root partition onto /mnt, then the file I would normally see as /etc/fstab will be seen as /mnt/etc/fstab.

Case Study 1

Our first case study concerns a RHEL5 system on which the /usr directory had been placed on a separate partition. For some reason (I forget what) I had to dictate an edit to /etc/fstab over the phone to an newbie administrator and he ended up with the field LABEL=/user instead of LABEL=/usr in the line that specified the mounting of the /usr partition. This error causes the system to fail to come up multi-user, but instead drops into a single-user shell. The dialogue looks like this:

fsck.ext3: Unable to resolve 'LABEL=/user'        [FAILED]

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell
Give root password for maintenance
(or type Control-D to continue):

The important thing is to actually read the error message. Why is it trying to find a label called /user? In which file would this appear?

Hmmm ... Maybe /etc/fstab? Since the system has graciously dropped us into a root shell, you would imagine it would be straightforward to edit /etc/fstab and fix the error. However, it turns out that the root file system is mounted read-only at this point (for the benefit of fsck) so you are not able to edit the file and save the result. The trick here is to change the mount options for the root partition to mount it read-write without actually unmounting it, like this:

# mount -o remount,rw /

After doing that, I'm able to edit /etc/fstab, correct the error, and reboot normally.

Case Study 2

Our second case study is more complex than the one above, and involves a dual-boot scenario.

First I installed OpenSUSE 10.2 onto an empty hard drive, allocating an 8GB partition hda1 as the root partition and a 2GB partition hda2 for the swap partition. The installer wrote the stage 1 Grub loader into the master boot record, and the stage 1.5 loader into the disk blocks immediately following. Some time later, I installed Fedora 7 onto the spare space on the hard drive, allocating a further 8 GB partition hda3 for its root file system and sharing hda2 with the OpenSUSE installation as the swap partition.

Figure 3 (below) might help if you're getting lost already. I allowed Fedora to go ahead with its default selection to install Grub onto /dev/sda. (The naming is confusing because OpenSUSE 10.2 names the partitions in the traditional way, as hda1, hda2 and so on, whereas Fedora 7 uses SCSI-style naming for the self-same partitions - sda1, sda2 and so on.)

Figure 3: dual-boot configuration show interaction between the SUSE and Fedora partitions.

Figure 3: dual-boot configuration show interaction between the SUSE and Fedora partitions.

During the Fedora installation I was offered the opportunity to add additional items into the Grub boot menu so I asked it to install an extra item with the label SUSE 10.2 and the device name /dev/sda1. This results in an entry in Fedora's Grub config file like this:

title SUSE 10.2
rootnoverify (hd0,0)
chainloader +1

If I select this item from the menu, Fedora's Grub will in turn load OpenSUSE's Grub from the first sector of the first partition (which Grub calls (hd0,0) and Fedora 7 calls /dev/sda1 and OpenSUSE calls /dev/hda1 - does this really have to be so confusing?) So now I can choose either Fedora or SUSE at boot time, although booting SUSE does involve the minor annoyance of having to go through a second Grub boot menu. If I had wanted to get clever, I could have copied the stanza for booting SUSE from the Grub config file in hda1 to the Grub config file in hda3, which is marginally more convenient, as I can boot direct into SUSE without having to go through a second menu.

Tipping Fedora

Anyway, a few weeks later, I decided that I no longer needed the Fedora installation and that instead I'd like to re-use the partition in the SUSE installation. So (while booted into SUSE) I ran:

# mke2fs -j /dev/hda3

...to create a new file system on the partition. Remember, hda3 was the root filesystem of my Fedora installation. Then I mounted my newly created file system onto /mnt. Everything was going fine until I tried to reboot. This is when the, er, products of digestion hit the fan, because at this point, Grub fails. I can't boot into Fedora (OK, I had deliberately destroyed that partition, so I expected that) but more seriously, I can no longer boot SUSE. In fact, all that happens is that the single word "GRUB" appears on the screen.

The secret at this point is: Don't Panic! Think back about what we did. Take another look at Figure 3, and remember that the contents of hda3 have now been overwritten. The stage 1.5 loader installed by the Fedora installation references a stage 2 loader in a file system on hda3 that no longer exists. What we need to do is re-install the original stage 1 and stage 1.5 Grub files in order to restore the capability to boot SUSE 10.2.

The only way forward is to boot from rescue media. As I mentioned earlier, almost any Linux installation CD will do the job here, but I chose to use Ubuntu 7.04 which is designed as a 'live CD'; that is, it will boot a full, working Linux system including a Gnome desktop, from CD.

Ubuntu, like Fedora, names the hard disk partitions as sda1, sda2, so once my live CD has booted I can mount my SUSE root partition into the Ubuntu file system like this:

$ sudo mount /dev/sda1 /mnt

(In case you were wondering about the sudo in this command, Ubuntu disables direct root logins and requires me to use sudo each time I run a command with root privilege. On the live CD distribution, no password is required to do this.) Now I need to run Grub to re-write the MBR. At this stage, I'm not entirely sure where the grub command is (I'm looking for the copy that SUSE installed; that is, the one on hda1), but by running:

$ sudo find /mnt -name grub

I quickly discover that it's in /mnt/usr/sbin/grub. Now I can run it and enter commands at the Grub command prompt like so:

$ sudo /mnt/usr/sbin/grub

grub> root (hd0,0)
grub> setup (hd0) (hd0,0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded. succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.
grub> quit

The key command here is setup (hd0) (hd0,0) which tells Grub to re-install the original (SUSE) stage 1 into the MBR of (hd0), and copies the original (SUSE) stage 1.5 into the sectors immediately following. (For a more detailed description of this, look up the install and embed commands in the GNU manual at www.gnu.org/software/grub/manual/grub.html) Once this is done, I can simply reboot and... Lo! My SUSE Grub boot menu is back!

International rescue

Live CDs such as Ubuntu or Knoppix do the job of rescue booting just fine, but there are smaller, faster rescue boot disks out there. One you might want to take a look at is SystemRescueCD (see www.sysresccd.org) which not only boots much faster but also contains an extensive collection of tools for managing and editing partitions, including classics like gparted and more unusual items such as NTFS-3g which allows you to access Windows NTFS partitions with full read and write support - great for rescuing files off that old malfunctioning Windows XP partition! Another benefit of this rescue CD is that it can cache its entire file system in memory, allowing you to remove the CD and insert another if necessary.

Kernel parameters

A common reason for modifying the Grub commands is to pass boot-time parameters to the kernel. These parameters are simply appended to the end of the kernel line. You can get a list of the boot time kernel parameters with the command man bootparam, or you can buy Greg Kroah-Hartmans' little book Linux Kernel in a Nutshell (where else would you find a kernel? Read it for free at www.kroah.com/lkn/) which devotes an entire chapter to them.

If you have installed the kernel source code you will also find a list of kernel parameters in /usr/src/linux/Documentation/kernel-parameters.txt. Be aware that many parameters relate to optional features that may or may not be configured into the kernel. The table lists just a few to give you the idea. Once Linux is up and running, you can examine the boot parameters that were passed to it by examining /proc/cmdline.

  • quiet: Suppresses kernel logging except for warnings and errors. Do not use this if you're trying to debug a boot-time problem.
  • splash: Displays a splash screen and progress bar, covering up the kernel messages. Again, remove this option if you're debugging.
  • single or S: Causes the kernel to run init to bring the system up into single-user run level. Depending on configuration, you may or may not be asked for the root password; then you'll be given a root shell. The X server and graphical desktop will not be started, nor will any partitions be mounted (except for the root partition of course). This is a useful mode for tackling X server startup problems or for repairing file systems.
  • vga=ask: This option allows you to select the mode for the video adaptor. The video mode sets the screen resolution (in character rows and columns) and you'll be prompted to select a video mode from a list. Occasionally useful if your monitor doesn't sync up to the default mode.
  • acpi=off: Disables APCI (Advanced Configuration and Power Interface).
  • init=/bin/sh: Run the program /bin/sh (the shell) instead of init. This is even more extreme than doing a single-user boot and performs almost no user-level initialisation. Booting is extremely fast, and the shell will be the only user process running.

Wednesday, February 4, 2009

Recovering Ubuntu After Installing Windows

Using the Ubuntu Desktop/Live CD

Quick Start

This option will use the Desktop/Live CD to install Grub into your MBR (Master Boot Record). This option will overwrite your Windows Boot Loader It is OK to do this, in fact that is the goal of this how to (in order to boot Ubuntu)

1. Boot the Desktop/Live CD. (Use Ubuntu 8.04 or later)

2. Open a terminal (Applications -> Accessories -> Terminal)

3. Start grub as root with the following command :

  • sudo grub

4. You will get a grub prompt (see below) which we will use to find the root partition and install grub to the MBR (hd0,0)

  •          [ Minimal BASH-like line editing is supported.   For
    the first word, TAB lists possible command
    completions. Anywhere else TAB lists the possible
    completions of a device/filename. ]

    grub>
    Type the following and press enter:
    find /boot/grub/stage1
    If you get "Error 15: File not found", try the following:
    find /grub/stage1
    Using this information, set the root device (fill in X,Y with whatever the find command returned):
    grub> root (hdX,Y)
    Install Grub:
    grub> setup (hd0)
    Exit Grub:
    grub> quit

5. Reboot (to hard drive). Grub should be installed and both Ubuntu and Windows should have been automatically detected.

6. If, after installing grub, Windows will not boot you may need to edit /boot/grub/menu.lst (That is a small "L" and not the number 1 in menu.lst)

  • Open a terminal and enter :
     gksu gedit /boot/grub/menu.lst
    Or, in Kubuntu:
     kdesu kate /boot/grub/menu.lst
    Your Windows stanza should look something like this :
     title Windows XP/Vista # You can use any title you wish, this will appear on your grub boot menu
    rootnoverify (hd0,0) #(hd0,0) will be most common, you may need to adjust accordingly
    makeactive
    chainloader +1
    Note: Put your Windows stanza before or after AUTOMAGIC KERNEL LIST in the menu.lst

Overwriting the Windows bootloader

Boot from a Live CD and open a terminal. You'll need to run a few commands as root so you can use sudo -i to get a root shell and run them normally instead of using sudo on each of them. Be extra careful when running a root shell, especially for typos !

We'll need to find which partition your Ubuntu system is installed on. Type the command fdisk -l. It will output a list of all your partitions, for example :

fdisk -l

Disk /dev/hda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 1 8 64228+ 83 Linux
/dev/hda2 9 1224 9767520 83 Linux
/dev/hda3 * 1225 2440 9767520 a5 FreeBSD
/dev/hda4 2441 14593 97618972+ 5 Extended
/dev/hda5 14532 14593 498015 82 Linux swap / Solaris
/dev/hda6 2441 14530 97112862 83 Linux

Partition table entries are not in disk order

Here I have three Linux partitions. /dev/hda2 is my root partition, /dev/hda1 is my /boot partition and /dev/hda6 is my /home partitions. If you only have one, obviously this is the one your Ubuntu system is installed on. If you have more than one and you don't know which one your Ubuntu is installed on, we'll look for it later. First, create a mountpoint for your partition, for example :

mkdir /mnt/root

Then mount your partition in it. If you don't know which one it is, then mount any of them, we'll se if it's the correct one.

mount -t ext3 /dev/hda2 /mnt/root

Of course, replace /dev/hda2 with the correct name of your partition. You can check if it's the correct one by running ls /mnt/root, which should output something like this :

bin    dev      home        lib    mnt   root     srv  usr
boot etc initrd lib64 opt sbin sys var
cdrom initrd.img media proc selinux tmp vmlinuz

If what you have looks not at all like this, you didn't mount the correct partition. Do umount /mnt/root to unmount it and try another one. You also need to mount your /boot partition if you made one, like this :

mount -t ext3 /dev/hda1 /mnt/root/boot

To make sure it was the correct one, run ls /mnt/root/boot, which sould output something like this :

config-2.6.18-3-686      initrd.img-2.6.18-3-686.bak  System.map-2.6.18-3-686
grub lost+found vmlinuz-2.6.18-3-686
initrd.img-2.6.18-3-686 memtest86+.bin

Once again, if what you have doesn't fit, unmount it and try another partition.

Now that everything is mounted, we just need to reinstall GRUB :

sudo grub-install --root-directory=/mnt/root /dev/hda

If you got BIOS warnings try:

sudo grub-install --root-directory=/mnt/root /dev/hda --recheck

Of course, replace /dev/hda with the location you want to install GRUB on. If all went well, you should see something like this :

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/hda

Now you can reboot and the GRUB menu should appear. If you see a warning message regarding XFS filesystem, you can ignore it.

Preserving Windows Bootloader

The method shown above puts GRUB back on the MBR (master boot record) of the hard drive instead of in the root partition. But you probably won't want that, if you use a third-party boot manager like Boot Magic or System Commander. (The original poster also suggested that this would be useful to restore the Grub menu after a re-ghosting.) In that case, use this alternative.

This alternative, used without a third-party boot manager, will not cause Ubuntu to boot.

If you have your Linux system in a second (or third...) hard disk this method will not work. Please check Super Grub Disk's method that address this problem.

1. Boot from a Live CD, like Ubuntu Live, Knoppix, Mepis, or similar.

2. Open a Terminal. Open a root terminal (that is, type "su" in a non-Ubuntu distro, or "sudo -i" in Ubuntu). Enter root passwords as necessary.

3. Type "grub" which makes a GRUB prompt appear.

4. Type "find /boot/grub/stage1". You'll get a response like "(hd0)" or in my case "(hd0,3)". Use whatever your computer spits out for the following lines. Note that you should have mounted the partition which has your Linux system before typing this command. (e.g. In Knoppix Live CD partitions are shown on the desktop but they're not mounted until you double-click on them or mount them manually)

5. Type "root (hd0,3)".

6. Type "setup (hd0,3)". This is key. Other instructions say to use "(hd0)", and that's fine if you want to write GRUB to the MBR. If you want to write it to your linux root partition, then you want the number after the comma, such as "(hd0,3)".

7. Type "quit".

8. Restart the system. Remove the bootable CD.

From: http://ubuntuforums.org/showpost.php?p=121355&postcount=5

From Inside Ubuntu

You have to run "grub" not from the Ubuntu Desktop/Live CD, but from your disk installation to make it work. To do this mount your root partition (following examples assume a root partition on hda1):

sudo mkdir /mnt/linux
sudo mount /dev/hda1 /mnt/linux

then change directory to your installation sbin and run grub from there

cd /mnt/linux/sbin
sudo ./grub

Using the Unofficial "Super Grub Disk"

From within Windows

  • Download Auto Super Grub Disk

  • Double-click auto_super_grub_disk_1.0 icon, install it, and reboot.

  • On the next boot, select the UNetbootin-supergrubdisk menu entry; this will launch the Auto Super Grub Disk.

  • Do nothing till you see your Grub menu again.

  • Next time you boot Windows, click yes when asked to remove UNetbootin-supergrubdisk to remove the Super Grub Disk menu entry.

As a standalone cd/floppy/usb

  • Download Super Grub Disk

  • Burn into a cdrom (better) or a floppy
  • Boot from it
  • Select: GRUB => MBR & !LINUX! (>2) MANUAL |8-)

  • Select the Linux or Grub installation you want to restore.

  • You see the message: SGD has done it!
  • Reboot
  • You're done.

Preserving Windows Bootloader

The method shown above puts GRUB back on the MBR (master boot record) of the hard drive instead of in the root partition. But you probably won't want that, if you use a third-party boot manager like Boot Magic or System Commander. (The original poster also suggested that this would be useful to restore the Grub menu after a re-ghosting.) In that case, use this alternative.

This alternative, used without a third-party boot manager, will not cause Ubuntu to boot.

This alternative will let you boot your second hard disk Linux installations from Windows while the Using the Ubuntu Desktop/Live CD Preserving Windows Bootloader instructions will not.

Either:

  • Download Super Grub Disk

  • Burn into a cdrom (better) or a floppy
  • Boot from it

Or:

  • Download UNetbootin Super Grub Disk Loader (Windows .exe version)

  • Run the installer and reboot when once done installing.
  • On the next boot, select the "UNetbootin-supergrubdisk" menu entry; this will launch the Super Grub Disk interface.

Then:

  • Super Grub Disk (WITH HELP) :-)))

  • Select: your language

  • Select: Windows

  • Select: Windows chainloads Grub!

  • Select the Linux or Grub installation you want to restore to its own partition.

  • You see the message: SGD has done it!
  • Reboot
  • You're done.

Using Microsoft Vista

If you have Vista installed and you installed Ubuntu and when you rebooted it didn't show up as a dual boot option, try going into Vista (since that is all you can do), use the program EasyBCD version 1.7 It looks like this: http://aycu01.webshots.com/image/31560/2002188190250314159_rs.jpg

Add your Linux install to the boot sequence.

Troubleshooting

This section applies to...

  • Dual-boot setups in which Windows was installed after Ubuntu
  • Conditions where Windows failure forced a re-installation
  • Windows recovery techniques involving the "restoration" of the MBR
  • Cases where GRUB failed to install

Prerequisites:

  • Your Ubuntu partitions are all still intact
  • You have a LiveCD, such as the Ubuntu Desktop CD, or anything you're comfortable with
  • You're familiar enough with your LiveCD to gain access to a console
  • You remember how you set up your partitions (having a printout of /etc/fstab is ideal, though you can make do with the output of fdisk -l /dev/hda)

  • Knowledge of how your kernel works (specifically with regards to initrd), if you're using a non-Ubuntu kernel or built your own
  • Your kernel's version; this howto assumes 2.6.10-5-386

Preparing Your Working Environment

To begin the restoration procedure, insert your LiveCD and reboot your computer. Proceed with your LiveCD's bootup proceedure until you are presented with an interface. If your LiveCD does not immediately present you with a console, also called a terminal, open one -- to do this with the Ubuntu LiveCD, click Applications -> System Tools -> Terminal.

Note: Since this is a LiveCD environment, any changes to user accounts or filesystem layouts at this level will not be permanent. This means you can set a temporary root password and create directories without affecting your actual installation.

Now, you need to gain root access. Under Ubuntu, this can be done with the following commands:

sudo -i

Under Knoppix, the following command will suffice, and you will not be prompted for a password.

su -

Now that you have root access, you need to mount the partition(s) containing your bootloader files.

You will need access to both your /sbin/ and /boot/ directories. If you have a /boot/ listing in your fstab, you are among those who will need to mount two partitions.

Begin by creating a mount point for your working environment -- you'll notice this is the same as creating a directory.

mkdir /mnt/work

If you need to mount /boot/, too, run the following command.

mkdir /mnt/work/boot

Now it's time to actually load your filesystem data. Review your fstab and identify the location(s) of / and /boot/; these will likely look something like /dev/hda3 and /dev/hda4, though the letter 'a' and the numbers 3 and 4 may differ.

Note: For the remainder of this howto, /dev/hda3 and /dev/hda4 will be assumed, so alter them as needed when typing them in yourself.

Enter the following commands to load your filesystem and some information GRUB may need.

mount /dev/hda4 /mnt/work
mount -o bind /dev /mnt/work/dev
mount -o bind /proc /mnt/work/proc
cp /proc/mounts /mnt/work/etc/mtab

Now, you have to enter your working environment. The following command will take care of that.

chroot /mnt/work/ /bin/bash

Warning: From this point on, any files you modify will affect your Ubuntu system. You have left the safety of the LiveCD. Excercise caution.

Recovering GRUB Automatically

If you have a separate /boot/ partition, type the following line.

sudo mount /dev/hda3 /boot/

Reinstalling GRUB from this point is easy. Just enter the following command.

sudo /sbin/grub-install /dev/hda

If the command you used above failed, which is unlikely, you will need to configure GRUB manually (it isn't too hard); if it succeeded, you should read the note at the start of the final section: "Configuring the GRUB Menu".

Recovering GRUB Manually

Before you can undertake the next step, it's important that you understand how GRUB identifies partitions.

To GRUB, numbers begin with 0, and letters are expressed numerically, also beginning with 0.

For example, /dev/hda1 is "hd0,0" to GRUB. Similarly, /dev/hdb3 is "hd1,2".

Note: The "root" line must point to the location of your /boot/ partition if you have one. If you do not have one, point it at your / partition.

sudo /sbin/grub
grub> root (hd0,2)
grub> setup (hd0)
grub> quit

Note: This step does not need to be done if you're just trying to recover your MBR. Installing Windows will not alter the contents of your existing menu.lst, so if everything was working right before, everything will continue to work right now, and you can restart your computer.

Open the GRUB menu file, /boot/grub/menu.lst, with your favourite text editor. An example follows.

sudo nano /boot/grub/menu.lst

Note: Your menu.lst file is used to control the operating systems GRUB displays on startup, as well as its visual appearance. This howto will only explain how to get your operating systems to boot; it will not tell you how to make your bootloader pretty.

A sample menu.lst, stripped of unnecessary comments, appears below. It is based on the /dev/hda3 and /dev/hda4 example above, and assumes Windows resides at /dev/hda1.

timeout 5 #The number of seconds GRUB should wait before booting an OS
default 0 #The entry which should be booted by default
fallback 1 #The entry which should be booted in the event of the first one failing

title Ubuntu, 2.6.10 #A 32-bit Ubuntu entry
#This (or something like it) should be in your configuration
root (hd0,2)
initrd /initrd.img-2.6.10-5-386
kernel /vmlinuz-2.6.10-5-386 root=/dev/hda4

title Ubuntu, 2.6.10 #Another 32-bit Ubuntu entry
#This is an example of an Ubuntu entry which does not have a separate /boot/ partition
#(it is provided only as an alternate to the example above -- do not use them together)
root (hd0,2)
initrd /boot/initrd.img-2.6.10-5-386
kernel /boot/vmlinuz-2.6.10-5-386

title Microsoft Windows XP Home #An entry for a Windows installation
#If you're reading this guide, you probably want this
root (hd0,0)
makeactive
chainloader +1

And that's it. Save and close the file, then reboot and try out the entries.

Using the Ubuntu Alternate/Install CD

This section explains how to rescue GRUB (the GRand Unified Boot loader), using the Ubuntu alternate/install CD ROM.

  1. Enter your computers BIOS to check computer can boot from CD ROM. If you can boot from CD, insert CD ROM into drive. Exit the BIOS (if needed save your settings to make sure the computer boots from the CD ROM).
  2. When the Ubuntu splash screen comes up with the boot: prompt, type in rescue and press enter.

  3. Choose your language, location (country) and then keyboard layout as if you were doing a fresh install.
  4. Enter a host name, or leave it with the default (Ubuntu).
  5. At this stage you are presented with a screen where you can select which partition is your root partition (there is a list of the partitions on your hard drive, so you are required to know which partition number Ubuntu is on). This will be dev/discs/disc0/partX, where the X is a partition number.

  6. you are then presented with a command prompt (a hash).
  7. type $ grub-install /dev/hdaX where X is your Ubuntu root install.

The GUI Way: Using the Alternate/Install CD and Overwriting the Windows bootloader

  1. Boot your computer with the Ubuntu CD
  2. Go through the installation process until you reach "[!!!] Disk Partition"
  3. Select Manual Partition
  4. Mount your appropriate linux partions:
    • /
    • /boot
    • swap
    • ...
  5. DO NOT FORMAT THEM.

  6. Finish the manual partition
  7. Say "Yes" when it asks you to save the changes
  8. It will give you errors saying that "the system couldn't install ....." after that
  9. Ignore them, keep select "continue" until you get back to the Ubuntu installation menu
  10. Jump to "Install Grub ...."
  11. Once it is finished, just restart your computer

From: http://doc.gwos.org/index.php/Restore_Grub and http://ubuntuforums.org/showthread.php?t=76652

GRUB Resources

重装Windows 不影响Ubuntu Linux系统,备份mbr

备份mbr

对于mbr丢失许多初学者很困惑,但是这个东西又很重要。

昨晚试了一下,备份mbr用dd命令很好用,只要备用一次,以后不管怎么重装,对多系统的启动都没有问题了

备份mbr:

sudo dd if=/dev/sda of=/mnt/windows/linux.lnx bs=512 count=1

意思为把硬盘的mbr(即前512个字节)导出存为linux.lnx文档,以后就一劳永逸了。

写入mbr:

sudo dd if=/mnt/windows/linux.lnx of=/dev/hda bs=512 count=1

重新把mbr写回,双启动菜单又出来了。

mbr被副盖的具体方法:

把linux.lnx文档放在C:盘下

echo c:\"linux.lnx"=linux >> boot.ini

启动windows2k时就出现双启动菜单,选择linux选项进入LINUX操作系统。

然后用dd命令重新写回mbr,至此全部搞定!