GRUB badly broken during upgrade

[Tom H]

On Sun, Oct 7, 2012 at 1:38 PM, Kevin O'Gorman <kogorman at gmail.com> wrote:
> On Sun, Oct 7, 2012 at 10:37 AM, Kevin O'Gorman <kogorman at gmail.com> wrote:
>> On Sat, Oct 6, 2012 at 6:35 AM, Tom H <tomh0665 at gmail.com> wrote:
>>> On Fri, Oct 5, 2012 at 7:01 PM, Kevin O'Gorman <kogorman at gmail.com> wrote:
>>>>
>>>> When I had just installed Xubuntu, the grub menu would show its
>>>> 3.0.0-26 kernel at the first two lines, followed by memtest, then the
>>>> Ubuntu 2.6.x kernels with an explicit root for Ubuntu. The 3.0.0
>>>> lines would boot to Xubuntu, and the 2.6 lines to Ubuntu.
>>>
>>> Please run bootinfoscript [1] and upload the results because I (for
>>> one) don't understand your description of your setup.
>>>
>>> 1. http://sourceforge.net/projects/bootinfoscript/files/bootinfoscript/
>>
>> Nice script.
>>
>> When I ran this, the apparent state of things was that I had a working
>> Xubuntu 12.04.1 on /dev/sdb2, and an unbootable Ubuntu 11.10 on
>> /dev/sdb7.
>>
>> This brokenness of the 11.10 does not particularly trouble me, since I
>> was migrating towards Xubuntu anyway, and I can mount the older setup
>> to retrieve what I need.  At the moment, I'm reluctant to try to
>> rectify it for fear of losing the bootability of the Xubuntu.  I've
>> had to reinstall it once already, and I'd rather not do it again.
>
> Oh, and the results of the bootinfo script are attached.

What a mess!

The "grub.cfg" in the sdb2 "/boot" (Xubuntu 12.04) points to incorrect
"/boot" and "/" because it's pointing at a non-existent UUID
("ab460680-9e94-4898-8b46-f28d1615bf7b").

It points at the 3.2 kernel on "ab460680-9e94-4898-8b46-f28d1615bf7b"
(the non-existent one) and the 3.0 and 2.6 kernels on sdb7.

The "grub.cfg" in the sdb7 "/boot" (Ubuntu 11.10) points to "/boot"
and "/" on sdb7 but considers sdb to be sda since it calls it hd0.

It points at the the 3.0 and 2.6 kernels on sdb7 using the correct
UUID ("f71d3572-440d-4c3c-98b0-be3d3227d55a") and the 3.2 kernel on
sdb2.

"core.img" on sda and sdc is pointing at sdb7 via embedding a file
into "core.img" to set the UUID of "/boot" and the corresponding
prefix. I don't see how this could possibly have been done by the
automated installation tools. You must've created the "core.img" on
sda and sdc and embedded a file into it with "-c".

"core.img" on sdb points at "/boot/grub/" on sdb2.

You said in one of your posts that you get a "grub rescue" prompt.

What's the result of "ls" and "set" at that prompt? We should be able
to walk you through boting from that prompt.