HOW GRUBSTERS TAME THE GRUB MMOTIA -An adventure in the Live disk world

BLURB:
Assumption: You have a faulty grub bootloader and you have in your hand a live disk.
The power is YOURS!!

1. sudo mount /dev/sda1 /mnt
2. sudo mount --bind /dev /mnt/dev
3. sudo mount --bind /proc /mnt/proc
4. sudo chroot /mnt
5. sudo grub-install /dev/sda
6. sudo update-grub
6. sudo reboot

After Reboot:
7. sudo update-grub

PROLOGUE:
The procedure for (re)installing the GRUB2 is not very different from
(re)installing GRUB Legacy (GRUB1). They are essentially the same, i.e;
    - install the primary bootloader into the Master Boot Record [MBR],
    - copy the image files for grub into /boot/grub,
    - update the grub configuration file.
The word grub will sometimes be used in in this text to refer to grub2, they are
are used interchangeably.

CHAPTER ALL-IN-1:
Being aware of the simple concept of grub (re)installation, the heros of this story,
us, Grubsters, champions and savior of the world of 'Linux installation', will procede to
tame the grub mmotia -mmotia: a SCARY apparition in Ghanaian[Akan] folklore, what the
english refer to as a dwarf, scary huh!

The command to install the bootloader to MBR;
    ubuntu@ubuntu:~$ sudo grub-install /dev/sda1

However running this command in the live disk world, will not only OUCH!, burn our left
asses, but taunt us with the following error;
    /usr/sbin/grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?).

DAMN, DAMN, DAMN!!!, no one told us that grub-install -the mmotia, uses another monster
program grub-probe.

grub-probe, 'probes' device info for the /boot/grub path. In this case /boot/grub maps to
the live disk world's /boot/grub not our Linux Installation, hence the error, grub-probe
cannot find the device.

Attempts to probe any other device, eg. /dev/sda1, will return useful information, try;
    sudo grub-probe /dev/sda1

So after applying salve to our burnt left asses, we come up with a clever way of fixing this
grub-probe monster, which is why grub-install will not work, ehm sorry, why we can't tame the
grub mmotia, we need to lure the two of them to our world, 'Linux installation', on the
hard disk plane.

Let us now welcome on stage the CHROOT fairy -neat right.

A hit-and-run-affair: root@ttousai:~# chroot DIR

The chroot command changes the root -duh- of a command. Commands
executed at the terminal have / as their root, so all commands are relative to /. However
chroot, changes the default / to the one specified by DIR, so now all commands will
be relative to DIR.

We are going to use chroot to make our Linux installation our root. This works because
our Linux installation also has the grub-install, and all relevant programs to install
grub on our hard disk. But first we have to mount our Linux partition;
    sudo mount /dev/sda1 /mnt

then chroot by;
    sudo chroot /mnt

Now we have access to all the commands and programs -weapons, if you like, we installed
on our Linux partition.

We can now go ahead and run grub-probe, expecting it to work since our /boot path
now is the /boot of our Linux installation. Wise guy! [sarcastic]. We get our right butts
burnt this time round.

    ubuntu@ubuntu:~$sudo grub-install /dev/sda
    /usr/sbin/grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?).
    -- and some more trashy talk --

So we find ourselfs asking, WTF! After considerable background knowledge, thinking and
googling, we find out that, our chroot environment has no access to two important filesystems
 needed by grub, /dev and /proc. Talk about a hard-to-tame mmotia!

Now to make matters worse or better, which ever, these directories are generated automagically
by the operating system, oh yeah and our chroot environment is definitely not the OS.

But fear not, as we will realise during our brain and google storming period, we can
actually leverage the /dev and /proc filesystems generated in the world of live session, so
that grub-install will stop trash talking and just be tamed.

Question is, HOW?
    # NOTE: If you are following this explanation first exit the chroot environment by
    # typing exit.
    sudo mount --bind /dev /mnt/dev
    sudo mount --bind /proc /mnt/proc

The above commands just 'bind' -I don't know what else to say', our live session's /dev and
/proc to the /dev and /proc in our Linux installation, so any OS generated devices will be
mapped to our Linux installation.

Now we can chroot back to our Linux installation, and attempt to -not so confident huh,
Mr. Grubster?, defeat and silence the grub monster once and for all, >:)

So we once again engage in the battle, this time on our own world, Linux installation;
    ubuntu@ubuntu:~$ sudo chroot /mnt
    ubuntu@ubuntu:~$ grub-install /dev/sda

Finally, having tamed the grub mmotia, how do we know? Because it did not trash talk us to
death, or burn both our butts this time, thats how. We can now generate a file to make it
behave itself, and do some cool tricks, who says you can't teach an old dog new tricks?
Actually a list of all the available operating systems and other petty details;
    ubuntu@ubuntu:~$ update-grub   
    # to create the grub.cfg, a list of all the worlds
    # we have saved from the grub mmotia.

We can finally reboot and we will see a familiar grub boot menu. Tada!!!
And that is pretty much how you tame the grub mmotia. Cool huh!

EPILOGUE: Run update-grub again after booting to your Linux installation, to generate

and for a lack of a better word, more accurate grub.cfg.