restoring GRUB loading after partition/device rename

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.

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

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.

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

sudo blkid

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.

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...

> 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

  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

.....'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 ?

> 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

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

  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

> 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.

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.

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