[Tfug] Grub Rescue

[Patrick Callahan]

On Tue, Nov 2, 2010 at 06:34, <charles at kissbrothers.com> wrote:

>
> I have to say that the original problem was created by my editing of GRUB2
> files that weren't supposed to be edited; I ignored the warnings, and it
> finally caught up with me.
> Now, I'll have to read up on GRUB2, and edit the appropriate files, create
> new ones, etc.  Fortunately, the documentation is substantial.
> Thanks for the help!
>
> Charles
>
>

The GRUB2 documentation, besides being "substantial", is incomplete. It's an
annoying situation. Here is some information about the simplest (though
perhaps not easiest) way to repair GRUB:

You're going to have to reinstall Grub to the MBR every time you run some
piece of software (usually an OS installer) that overwrites it. Microsoft
OSes will always overwrite the MBR (probably on your first available hard
disk, but possibly the boot record of the physical disk you're installing
the OS to) without warning or any other option. Some Linux installers give
you the option of installing GRUB or not, and in addition most distros will
detect and acknowledge the presence of other operating systems upon
installation.

Grub will break when it can't find the next drive it needs to reach. If the
partition containing Grub (boot partition) moves, this can happen when it
goes from the MBR to the boot loader (menu) itself, as it did in your case.
If instead the root partition (partition containing the root Linux
filesystem) moves, Grub will fail after trying to jump from the menu to the
OS. Usually, Grub will be able to find the root partition by UUID or disk
number if those things haven't changed since it was last updated/installed,
but with complex partition setups it sometimes gets goofed up. Yesterday,
when I resized the extended partition that contains the (logical) root
partition, I had to resize if from the beginning, effectively moving the
index of the extended partition which indicates where to find all of the
logicals it contains.

In practice, the particular cause of failure isn't very important, because
the solution in all cases is the same.

*1. Boot up another Linux OS of the same architecture (a 64-bit distro to
fix a 64-bit distro's Grub installation, etc.). This can be another locally
installed OS, a USB drive, or a LiveCD.*

*2. Locate the filesystems you want to work on.*
Most LiveCDs come with "parted", a Linux partitioning tool that can be used
to read or modify your partition table. You can also use "ls -l" check the
disks under /dev/disk/by-label to find the corresponding nodes under
/dev/sd*. If these clues aren't enough to tell which filesystem you want,
you can temporarily mount them, poke around, and unmount until you find the
partition you want. The partitions we care about for this are / and /boot.

*3. From a terminal or virtual console on the live OS, bootstrap the
installation we want to repair.*
This is a process that will allow us to "run" the broken installation
without booting it. A program called "chroot" will allow us to *change root*,
treating your broken system mounted locally as if it were the running
system. To do this, we need to mount the misconfigured Linux distro,
recreate certain special filesystems that Linux needs to truly "run", and
finally chroot into it. Here are the necessary commands to run as root,
assuming / is on /dev/sda5 and /boot is on /dev/sda1:

mkdir /mnt/brokeroot
mount /dev/sda5 /mnt/brokeroot
mount /dev/sda1 /mnt/brokeroot/boot
mount -o bind /proc /mnt/brokeroot/proc
mount -o bind /sys /mnt/brokeroot/sys
mount -o bind /dev /mnt/brokeroot/dev
mount -o bind /tmp /mnt/brokeroot/tmp
chroot /mnt/brokeroot /bin/bash

The first two commands set up our mountpoint and there mount the root
filesystem we want to work with. The third adds the boot partition to our
recreation of the full filesystem. This is only necessary if you have a
separate /boot partition; if /boot is part of /, it is optional. The rest of
the mount commands will give the chrooted environment access to the special
filesystems used to access the kernel, along with the current temporary
filesystem. The final command tells the computer to drop you to a shell with
the root directory changed to /mnt/brokeboot, and /bin/bash is the shell
you've chosen here.

*4. Fix the Grub configuration if necessary, and reinstall it.*
Fixing the Grub configuration could entail different things depending on
what caused your problem, but usually, simply running "update-grub" will fix
it by automatically creating a new Grub config file in the appropriate
location. To reinstall it, call "grub-install /dev/sdX", where X is the
letter corresponding to your boot disk. Unless you've changed your disk boot
order in the BIOS, the one we're talking about is /dev/sda.

*Additional information*
Here are some tips that you can use to simplify this procedure and save time
in certain cases:

*Note* that if the system's partition configuration has not changed and Grub
has merely been overwritten (eg. if your computer boots directly into
Windows), you can reinstall it with a less exhaustive procedure. Simply
mount the broken system's / and /boot partitions as in the first two steps,
and run "grub-install --root-directory=/mnt/brokeroot/".

*Also note* that if you can reach the Grub menu and know your way around
enough to boot the OS that houses Grub, you can use these same commands on
the real environment rather than the chrooted one, and to the same effect.

--

P.S. ...

Charles, the reason you're not supposed to edit /boot/grub/grub.cfg isn't
because it will necessarily break things, although it can. It's because that
file is overwritten automatically whenever update-grub is called, like we do
during this guide, or dpkg (Debian and Ubuntu's package manager) does after
every kernel upgrade. The update-grub command uses the settings in
/etc/default/grub to decide how to generate the corresponding grub.cfg file,
so editing the proper file is simply the difference between making your
changes temporary or permanent.

Ryan, update-grub2 is simply a wrapper script that calls update-grub. You
can see this in the man pages for update-grub2.

And thanks to Kramer, for the warning and explanation of the problems solved
in this little guide. They make a nice complement to it.

--Patrick C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20101212/f8b6117c/attachment.html>