restoring GRUB loading after partition/device rename

Asked by Gary Trujillo on 2010-09-19

Greetings.

My machine, a Compaq notebook, has become unbootable - almost - due to a set of circumstances I'll describe later. First, though, here where things now stand.

The MBR of the internal drive has what I believe to be a good copy of GRUB2 (though it's not acting as I would expect - more on that subject also a bit later), and several partitions, including several for Windoze (which I'm using now to write this plea for help), and three of special interest:

  /dev/sda6 (previously known as /dev/sda8): ext4 file system

  /dev/sda7 (previously /dev/sda6): ext3 Linux /boot partition

  /dev/sda8 (previously /dev/sda7): Linux swap partition

  My problem is that GRUB knows about these file systems under their previous names, not the new ones.

  Here's what happened...

After a recent install of Ubuntu, I began installing software using apt-get. However, I didn't know that the /boot partition would be used during that process, so I had only allocated 80MB, which I discovered in the process of updating the system is insufficient. Since the /boot and swap partitions were immediately adjacent to one another, I carved a bit off of swap to give to /boot, so it would have 200MB, which seems sufficient. That part worked fine - I backed up everything in /boot, freed the space in both partitions, using fdisk, re-partitioned and restored the previous contents of /boot.

So far, so good. Then I tried rebooting, and found myself looking at a GRUB rescue prompt. After booting into Knoppix using a USB stick, I saw that the partitions had been re-arranged as indicated above. I've spent time poring over various descriptions of how to recover from such a situation, including an article at:

  https://help.ubuntu.com/community/Grub2

which, though helpful in some general ways, leaves me somewhat confused. The claim is made in the article that, though the grub2 rescue mode has a reduced command set, it includes commands like "help," "cat," "linux" and "reboot," none of which are actually available.

I was finally able to boot into Windoze using the advice in a GRUB2 manual I got at http://gnu.org/software/grub/manual/ using:

  set prefix=(hd0,x)/grub
  set root=(hd0,x)
  insmod normal
  normal

("x" being "7" in my case, to boot from /dev/sda7).

I could select the partition containing Windoze, but not the Linux one, for reasons I can understand that have to do with incorrect device names being encoded into the "grub.cfg" file.

Here's how the partition table looks, as fdisk sees it:

   Device Boot Start End Blocks Id System
/dev/sda1 * 1 26 203776 7 HPFS/NTFS
Partition 1 does not end on cylinder boundary.
/dev/sda2 27 28622 229697339+ f W95 Ext'd (LBA)
/dev/sda3 28623 30389 14180352 7 HPFS/NTFS
/dev/sda4 30389 30402 105656 c W95 FAT32 (LBA)
/dev/sda5 27 10406 83377318+ 7 HPFS/NTFS
/dev/sda6 11202 28622 139934151 83 Linux
/dev/sda7 10407 10432 208813+ 83 Linux
/dev/sda8 10433 11201 6176961 82 Linux swap / Solaris

The /mnt/boot/grub/grub.cfg file is shown at http://pastebin.ca/1943856 .

If I try to boot from the Linux partition, which is the first shown in grub.cfg, and go into edit mode, I see that the boot device is identified by means of a UUID designator, which is something I don't understand at present. I tried replacing both the device name ("sda6" to "sda7") and the UUID name in that edit session and rebooting, but nothing useful happens (I don't recall at this point exactly what happened, except that it wasn't a boot into Linux).

Here's a snippet from "grub.cfg":

  insmod ext2
  set root='(hd0,6)'
  search --no-floppy --fs-uuid --set 23fdef48-e848-4c3f-9001-efe958b8cdf7
  set locale_dir=($root)/grub/locale
  set lang=en
  insmod gettext

Someone in an IRC channel suggested I try using "Super Grub 2" (http://www.supergrubdisk.org/). Though it gives me some interesting information, I haven't yet figured out how to use it to solve my problem. I intend to go back to it while waiting for replies to this trouble report, however. (I found a note in the Wiki that serves as documentation for Super GRUB 2 that it can't deal with separate boot partitions (which I'm using because I hope to eventually be able to replace the file system I'm using with a KVM volume, so I can use encryption - however, for the time being, I've copied what's in /boot into the /boot directory on that file system, so it would be possible to boot from /dev/sda6).

I should also mention that I understand, from the help.ubuntu.com article and elsewhere, that it is not possible to simply edit the "grub.cfg" file the way that was possible with respect to "menu.lst" under plain old GRUB. However, the "update-grub" command seems to not take an argument, so it's seemingly not possible to edit the file while booted into another system, like the Knoppix live system I've been using to poke around has made possible (and Knoppix only has an old regular GRUB version of "update-grub" anyway).

My questions at this point are:

  1. Why don't I have access to all the GRUB 2 commands indicated in
     the article at https://help.ubuntu.com/community/Grub2 in GRUB2
     rescue mode?

  2. What's the easiest way to figure out what all I need to do to
     get myself back into a bootable condition, and what's the best
     procedure to use?

  3. Are there any other good resources anyone can recommend?

Thanks in advance for any advice or assistance!

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu grub2 Edit question
Assignee:
No assignee Edit question
Solved by:
Gary Trujillo
Solved:
2010-09-20
Last query:
2010-09-20
Last reply:
2010-09-19
peter b (b1pete) said : #1

take a look at

https://help.ubuntu.com/community/Grub2#Changing%20or%20Moving%20GRUB%202

a grub (re) install procedure in the new environment will hopefully work.

Gary Trujillo (gst-btlonline) said : #2

On Sun, 19 Sep 2010 03:04:22 -0000
peter b <email address hidden> wrote:

> Your question #125989 on Ubuntu changed:
> https://answers.launchpad.net/ubuntu/+question/125989

Thanks, Peter. I'll read the article carefully. One thing that
concerns me about reinstalling GRUB is that I've read several places
that there is some inherent danger involved in replacing the MBR. One
item I read said that there is some degree of uncertainty about the
size of the area the MBR occupies, or some such - that whatever reports
the size might use any of several different methods, so there's some
risk of overwriting the partition that follows the MBR, I guess.

Another thought occurred to me after posting my question, which is
whether it's possible to rename the devices. If I could somehow
restore the old names, I think all would be well - unless the UUID
names change (I don't know how those things are generated/obtained).

Anyway, I do appreciate the help, and will carefully examine the
content of the article suggested for my attention.

Best regards,

Gary

peter b (b1pete) said : #3

your ubuntu partitions as submitted would be

/dev/sda6 11202 28622 139934151 83 Linux
/dev/sda7 10407 10432 208813+ 83 Linux
/dev/sda8 10433 11201 6176961 82 Linux swap / Solaris

more than likely sda6 is / , sda7 is /boot and sda8 is swap

win partition is the one that MS mandatory wants - sda1 and, from what I understand, it was not touched.

I'd recommend BEFORE proceeding with a grub re install to get your win installation in good working order/function ie make it bootable again - use win recommended procedures to render it bootable again (grub overwrote the MBR and, v important, the logical partitions UUID was changed so grub obviously can not find the new UUID - it was configured for the old UUID's.

peter b (b1pete) said : #4

to find the new part UUID , do in a terminal while booted off CD

sudo blkid

Gary Trujillo (gst-btlonline) said : #5

I have more comments regarding this problem.

First is that the indicated article is the same one I referred to in my
original posting. The article, however, says nothing that I've seen
thus far about installing GRUB2 from an unbootable system. I expect I
can find that information elsewhere, and maybe Super GRUB provides an
option to do such an installation. Most of what is in that article
assumes that one is starting from a running system.

> peter b proposed the following answer:
> your ubuntu partitions as submitted would be
>
> /dev/sda6 11202 28622 139934151 83 Linux
> /dev/sda7 10407 10432 208813+ 83 Linux
> /dev/sda8 10433 11201 6176961 82 Linux swap / Solaris
>
> more than likely sda6 is / , sda7 is /boot and sda8 is swap

Right you are. That's pretty much what I said in my initial posting:

  /dev/sda6 (previously known as /dev/sda8): ext4 file system
  /dev/sda7 (previously /dev/sda6): ext3 Linux /boot partition
  /dev/sda8 (previously /dev/sda7): Linux swap partition

except that I neglected to mention that /dev/sda6 is the root f.s.
(but what else could it possibly be? :-)

> win partition is the one that MS mandatory wants - sda1 and, from
> what I understand, it was not touched.

Right. As I mentioned, by following instructions in the grub2.pdf file
I picked up at http://gnu.org/software/grub/manual/ , I was able to
boot into Windoze.

> I'd recommend BEFORE proceeding with a grub re install to get your win
> installation in good working order/function ie make it bootable again
> - use win recommended procedures to render it bootable again (grub
> overwrote the MBR and, v important, the logical partitions UUID was
> changed so grub obviously can not find the new UUID - it was
> configured for the old UUID's.

Well, apparently the UUID for the Windoze boot partition was not
affected by the re-partitioning, which is why I was able to do a
win-boot.

> to find the new part UUID , do in a terminal while booted off CD

> sudo blkid

OK. Thanks. But I suppose that UUID does me no good, unless I can
boot into the system whose grub.cfg I want to change. I can, however,
understand that if GRUB itself is able to handle the whole process, it
will automatically fix everything up, including those identifiers.

Gary Trujillo (gst-btlonline) said : #6

On Sun, 19 Sep 2010 03:50:11 -0000
peter b <email address hidden> wrote:

> Your question #125989 on Ubuntu changed:
> https://answers.launchpad.net/ubuntu/+question/125989
>
> peter b proposed the following answer:
> to find the new part UUID , do in a terminal while booted off CD
>
> sudo blkid

Well, I just tried the command from within Knoppix, and it reports that
the UUIDs are unchanged. I recorded those strings, copying them by
hand from the screen during an earlier boot attempt:

  hd0,6 89026b1d-ed74-465c-a925-c73d1b964c59
  hd0,7 ba5e22b1-d340-44e7-8ebc-7e19f914a659

I note that these UUIDs are, as expected, following the file systems
that had been assigned those IDs. For example, I find in "grub.cfg":

  set root='(hd0,8)'
  search --no-floppy --fs-uuid --set
  89026b1d-ed74-465c-a925-c73d1b964c59

which was appropriate when the root f.s. was on the partition
called /dev/sda8, and is now called /dev/sda6.

So what "blkid" says about the partitions is consistent with what's
reported by GRUB when I enter its edit mode after having started Super
Grub 2:

  /dev/sda6: UUID="89026b1d-ed74-465c-a925-c73d1b964c59" TYPE="ext4"
  /dev/sda7: UUID="ba5e22b1-d340-44e7-8ebc-7e19f914a659" TYPE="ext4"
  /dev/sda8: UUID="8b30e890-c52e-417f-8ee7-f33ca3f0998b" TYPE="swap"

My remaining question is how I can fix things if I can't boot. I don't
think Knoppix is going to be able to help. Maybe there's some way to
do the update from within live mode from the install disk, maybe using
grub-setup. I'll give it a try...

Sam_ (and-sam) said : #7

> 1.
The 'set root=' and other essentials are mentioned in community wiki.
https://help.ubuntu.com/community/Grub2#Using%20CLI%20to%20Boot

Editing of partitions may lead to new UUIDs.
This will read uuid into cache.
sudo blkid

Verify that uuids are the same.
ls /dev/disk/by-uuid -al
gedit /etc/fstab

Gathered information needs to be written into /etc/fstab.
In case edit fstab an reload it.
sudo mount -a
or reboot.

Before a partiton can be mounted a mount point needs to be created.
Verify that mountpoints exist.

Reference.
https://help.ubuntu.com/community/Fstab
https://help.ubuntu.com/community/FilePermissions
https://help.ubuntu.com/community/Mount
https://help.ubuntu.com/community/DrivesAndPartitions

> found myself looking at a GRUB rescue prompt

Incl. 'Expanded Instructions'
https://help.ubuntu.com/community/Grub2#Rescue%20Mode

Modifying grub.cfg wont survive the next update.
Stable is to edit /etc/default/grub
https://wiki.ubuntu.com/Grub2#grub.cfg%20%28/boot/grub/grub.cfg%29

Recover Grub via LiveCD.
https://help.ubuntu.com/community/LiveCdRecovery

## It's recommended to install Grub into MBR not on a certain partition.
After localizing devices via fdisk -l and blkid.

## Root direct method when grub.cfg doesn't need to be rewritten.

sudo mount /dev/sdXY /mnt
sudo grub-install --root-directory=/mnt /dev/sdX
sudo update-grub

In additional case of separate /boot.

sudo mount /dev/sdXY /mnt
sudo mount /dev/sdXY /mnt/boot
sudo grub-install --root-directory=/mnt /dev/sdX
sudo update-grub

## Chroot method when grub.cfg needs to be rewritten.
https://wiki.ubuntu.com/Grub2#Recover%20Grub%202%20via%20LiveCD

Additional reference.
http://members.iinet.net/~herman546/p20.html ## also mentioned in community doc.
http://www.dedoimedo.com/computers/grub-2.html
http://ubuntuforums.org/showthread.php?t=1195275

Gary Trujillo (gst-btlonline) said : #8

  On 9/19/2010 10:51 AM, Sam wrote:
> The 'set root=' and other essentials are mentioned in community wiki.
> https://help.ubuntu.com/community/Grub2#Using%20CLI%20to%20Boot
>
> Editing of partitions may lead to new UUIDs...

Thanks, Sam. I was just preparing a report of my ongoing problems when
this reply arrived. I will check out the article mentioned and make
another attempt based on whatever I learn from it before continuing on
that report, though. I hadn't thought of /etc/fstab having to be
updated to reflect the device name changes. That's a very important
point, and a major oversight on my part.

More in a bit...

Gary

peter b (b1pete) said : #9

.....'My remaining question is how I can fix things if I can't boot. I don't
think Knoppix is going to be able to help.'....

- did you carefully read and/or notice within url recommended above 'Reinstalling from LiveCD' heading and 'Boot to the LiveCD Desktop (Ubuntu 9.10 or later). ' ??

if you followed (more than likely you did not, why?) url's instructions then what's the point of repeating 'I can't boot' and keep on talking about Knoppix ? do you genuinely want your problem solved ?

Gary Trujillo (gst-btlonline) said : #10

> peter b proposed the following answer:
> .....'My remaining question is how I can fix things if I can't boot. I don't
> think Knoppix is going to be able to help.'....
>
> - did you carefully read and/or notice within url recommended above
> 'Reinstalling from LiveCD' heading and 'Boot to the LiveCD Desktop
> (Ubuntu 9.10 or later). ' ??

I did, but had not digested the import of some parts of the article when
I wrote that posting. In particular, the idea of booting from the live
disk and using the third method indicated for installing GRUB is
helpful, though it didn't completely solve my problem. (That
explanation involves using "chroot" to make the GRUB installer and other
utilities think it's dealing with the root filesystem of a running
system booted from that filesystem.)

> if you followed (more than likely you did not, why?) url's instructions
> then what's the point of repeating 'I can't boot' and keep on talking
> about Knoppix ? do you genuinely want your problem solved

Hey. There's no need for such critical comments, which are based on
what I think is a misreading of what I wrote. I wasn't trying to say
that if I couldn't use Knoppix to fix the problem it's therefore
insoluble. At that point, the importance of the idea of using chroot
was not yet apparent..

Such having been said, I'll save my detailed report for a bit later,
after I've had a chance to assemble a bit of information. I do
appreciate the help, of course, but, as I keep saying, the article I
keep getting referred to does not, as far as I can see now, solve the
problem completely, and it seems incorrect as regards the commands
available in the GRUB rescue mode.

More in a bit...

Thanks again.

Gary

delance (olivier-delance) said : #11

https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows should provide you the way to fix grub configuration issue

Gary Trujillo (gst-btlonline) said : #12

  On 9/19/2010 3:24 PM, delance wrote:
> Your question #125989 on grub2 in ubuntu changed:
> https://answers.launchpad.net/ubuntu/+source/grub2/+question/125989
>
> Status: Open => Answered
>
> delance proposed the following answer:
> https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows
> should provide you the way to fix grub configuration issue

Well, I think that all of the suggestions I've gotten thus far to
consult the article I myself cited originally or some other, though
well-meaning, aren't especially helpful at this point, since I have
followed a procedure that is given in that original article, which looks
much more thorough than the one in the article to which delance refers.

However, I should mention that I posted my question to a GNU GRUB list
and got a reply that refers to a web page containing a description of a
procedure that's very similar to the one I followed based on the
original Ubuntu article. Following is the reply I sent, which gives
more details of my problem, which I don't expect will be solved by any
simple procedure. There seems to be something else involved due to my
devices having gotten renamed. If anyone has a more in-depth knowledge
of how this stuff works, and can take a look at my specific problem, I'd
appreciate your advice. Simply referring me to generic articles,
however, don't seem likely to produce good results, since I've already
followed those procedures to the letter and still have no resolution to
my problem.

Thanks anyway.

Oh - I almost forgot one important item mentioned by the person to whom
I replied int he message quoted below, which is that the Ubuntu article
is incorrect - probably out of date - on the topic of the commands
provided in GRUB rescue mode:

> 1. Why don't I have access to all the GRUB 2 commands indicated in
> the article athttps://help.ubuntu.com/community/Grub2 in GRUB2
> rescue mode?

Because that guide is inaccurate. I'll fix it (or replace that with a
link to the official manual) when I have time.

--

Thanks much to Jordan Uggla, who, on 9/19/2010 3:27 PM, wrote in reply
to my earlier posting in which I asked:
>> 2. What's the easiest way to figure out what all I need to do to
>> get myself back into a bootable condition, and what's the best
>> procedure to use?
Jordan said:

> Follow this guide:http://grub.enbug.org/Grub2LiveCdInstallGuide

Well, with a few minor, and probably unimportant difference, the
procedure outlined in that guide Jordan cites is pretty much what's
given in the article at https://help.ubuntu.com/community/Grub2 that I
cited in my posting. The only real differences are:

   1. It uses "*grub-mkconfig -o /boot/grub/grub.cfg"* rather than
"*update-grub" *which I think performs the same function (but I'd be
glad to be corrected on this point), and it omits the "*mount --bind
/sys /mnt/sys" *command for an Ubuntu-derived system. The procedures
described are so similar, in fact, that I suspect that the information
in the help.ubuntu.com article was derived from the other one. It was
that procedure I've been using in an attempt to fix up my GRUB config
file so I can boot.

At present, I get:

[ 0.892038] Kernel panic - not syncing: VFS: Unable to mount root fs
on unknown-block(0,0)

when I try to boot one of the Linux kernels in the /boot partition

I've discovered through a bit of googling that that error is associated
with no appropriate driver being available for the file system being
referred to, which may be because an inappropriate device is being
referred to in the grub.cfg file.

If I go into edit mode in GRUB with the default kernel selected, I see:

recordfail
insmod ext2
set root=(hd0,7)
search --no-floppy --fs-uuid --set ba5e22b1-d340-44e7-8ebc-7e19f914a659
linux /vmlinuz-2.6.32-24-generic root=/dev/sda6 ro quiet splash

I'm wondering about what seems to be an inconsistency between the
"(hd0,7)" and "/dev/sda6" - one being what I assume to be the root
device used for the boot (which is actually the /boot partition), and
the one the kernel is being told about. Maybe that's just how things
work, and maybe I'll get an answer to that question by reading the GRUB
manual slowly and carefully (which I'm hoping to be able to avoid, if
possible :-) .

I should also note that the UUID referred to in the "search" command is
for /dev/sda7:

/dev/sda6: UUID="89026b1d-ed74-465c-a925-c73d1b964c59" TYPE="ext4"
/dev/sda7: UUID="ba5e22b1-d340-44e7-8ebc-7e19f914a659" TYPE="ext4"
/dev/sda8: UUID="8b30e890-c52e-417f-8ee7-f33ca3f0998b" TYPE="swap"

I've alterned my /etc/fstab along the lines of what Jordan suggests:

UUID=89026b1d-ed74-465c-a925-c73d1b964c59 / ext4 errors=remount-ro 0 1
UUID=ba5e22b1-d340-44e7-8ebc-7e19f914a659 /boot ext4 defaults 0 2
UUID=8b30e890-c52e-417f-8ee7-f33ca3f0998b none swap sw 0 0

though I'm pretty sure the failure is happening long before the root
filesystem would get mounted, since the kernel isn't even getting loaded
(right?).

Well, I'll go back to reading the GRUB2 manual, but if anyone has any
ideas or suggestions meanwhile, please let me know.

Thanks.

Gary

Gene Cumm (gene-cumm) said : #13

> I'm wondering about what seems to be an inconsistency between the
> "(hd0,7)" and "/dev/sda6" - one being what I assume to be the root
> device used for the boot (which is actually the /boot partition), and
> the one the kernel is being told about. Maybe that's just how things
> work, and maybe I'll get an answer to that question by reading the GRUB
> manual slowly and carefully (which I'm hoping to be able to avoid, if
> possible :-) .

Yes. GrUB's root for loading files versus the root file system for the Linux kernel to attach to.

Gene Cumm (gene-cumm) said : #14

I'd recommend using fdisk or another partition tool to fix the partition order, revert to your previous grub.cfg and all should be good, with a possible need to perform a grub-install again.

Gary Trujillo (gst-btlonline) said : #15

I was able to get the help I needed from the person I mentioned earlier who replied to my posting on the grub-help mailing list. Here's my reply to his most recent posting to that list. And thanks again to everyone here who provided useful suggestions also.

On 09/19/2010 11:20 PM, Jordan Uggla wrote:
> Grub-mkconfig generated a menu entry without an initrd line, despite
> the fact that Ubuntu uses and requires an initrd. The most likely
> reason for this is that when you copied your kernels from your old
> /boot partition you forgot to copy the initrd images as well. To fix
> this follow http://grub.enbug.org/Grub2LiveCdInstallGuide up to step
> two, then in the chroot run "apt-get install --reinstall
> linux-image-2.6.32-24-generic".

I want to thank Jordan, with whom I had the pleasure of chatting via the #grub IRC channel at Freenode Sunday evening, immensely for his help in solving this problem! Though I think the loss of the initrd file had something to do with the filling up of the /boot partition during a software installtion from within Synaptic, which is the reason I decided to enlarge that partition, by following the procedure outlined above, I was in fact able to restore my machine to a bootable state.

This whole experience taught me both a lot more about GRUB than I really wanted to know just at this point and that the subject is a lot more complex (or at least it seems so) than I had ever imagined. Though surely comprehensive, I think the way the GRUB manual is organized makes it hard to use as a learning resource - it reads more like a reference manual than a tutorial - which may be alright, if there are some good up-to-date HOWTOs out there someplace.

I just know that without Jordan's help, I likely never would have been able to find an fix this problem, since I hadn't known anything about initrds and UUIDs, and only enough about utilitiesss like fdisk, for that matter, to be able to get by before going through what I did.

Thanks again ever so much to Jordan, both for his suggestions and for the time he gave so generously last night. I am deeply in his debt!

Gary