Recovery from upgrade trashing...

[pcal]

Hi folks,

Have dual boot xp/ubuntu system, that's been running fine with v9.04 for some time. Watched it for several hours today while it upgraded to v9.10, everything claimed to have upgraded correctly.

Now when I boot, menu.lst still gives me my xp install (which still works), and also lists ubuntu 9.04 and 9.10 (in a variety of incarnations each)

If I select any of the v9.10 options, I get an error 15 - file not found. If I select any of the v9.04 options, I get pages of text flying past, mostly listing error messages, until the system eventually crashes.

I'm guessing grub is all bitter and twisted over something, and intend to run update-grub, but I can't get a running system to do this from. I could boot from v9.04 live cd, but I assume there would be incompatibilities trying to create a 9.10 menu.lst from a 9.04 system.

Do I need to download a 9.10 iso and burn another live cd (which I didn't do in the first place because I wanted to preserve a fair amount of data in the existing install), or is there an easier way?

I'm not a complete noob, but am still a long way from expert status...

Regards,

Pcal

[pcal]

In the absence of any other ideas, I've downloaded the 9.10 64bit iso and burned it to disk.

It doesn't seem to have helped me however. I couldn't boot from the disk in default configuration as it drove my monitor beyond range. So I rebooted using safe graphic mode, and ended up with only a text screen that was flashing violently every fraction of a second!

I managed to type a couple of comands (the keyboard would not respond while the screen was in its flashed off state) but once I got 'sudo update-grub' into the system, all it gave me was an error that it couldn't resolve "\".

I'm guessing having booted from cd messed up the linux equivalent of the windows environment variable so it couldn't find the correct location...

I've run out of ideas... please someone, what am I missing?

Thanks in anticipation.

Pcal

[Moozillaaa]

Is your machine capable of running 64 bit OS?

Put in a Live CD (any), and post up
fdisk -l return...

Also while booted live, type in a terminal:


cat /boot/grub/menu.lstThis is presuming you still have legacy GRUB installed, instead of GRUB2...

[pcal]

Thanks moozillaaa for the reply. :)


Is your machine capable of running 64 bit OS?

Yes. It's an AMD Quad core that's been happily running 64bit 9.04 for a while now.


Put in a Live CD (any), and post up
fdisk -l return...

Did it. Nothing appeared to happen.



Also while booted live, type in a terminal:


cat /boot/grub/menu.lstThis is presuming you still have legacy GRUB installed, instead of GRUB2...

Did it. Got "No such file or directory"

I really don't want to assume I know too much, but would not the instruction above have been looking for /boot/grub/menu.lst on the live cd I booted with, which presumably doesn't exist?

Given that no gui has opened, and I only have terminal access where every keystroke needs to be repeated 10 or 20 times until I fluke the timing just right, something is seriously "not right". It even looks as if the screen may be trying to give a morse code or something - there is a pattern. Everything flashes 5 times quickly, followed by one flash that is slightly longer, then the pattern repeats. Is this like an OS version of the beep codes the post tests can generate?

Have been testing while typing this post (I'm on the netbook sitting beside the desktop), and have just got an old fiesty live cd to boot ok into the gui, so at last I can access the menu.lst file... and it's nothing like it was just before the upgrade. I made a backup copy of it at that time, but the backup copy is not there any more.

Have attempted update-grub, but as expected, it's looking in the wrong place and can't find the directory.

Do I have a next step?

Regards,

Pcal

[pcal]

:) I got it working!

Having gained access with the v7 live cd I was able to examine the menu.lst file. Also reading the "info update-grub" and trying to grasp how the entries are supposed to be created, I found that the vmlinuz files in the boot directory did not have version numbers that lined up with the entries in the menu.lst file generated by the upgrade.

So, I manually edited the menu.lst file to correspond with the kernel version numbers from the vmlinuz files, and suddenly - it works again!

I am unsure however about the significance of the UUID entry in the menu.lst file. I left it as is, and as I have created entries for each kernel version I found, all have the same UUID entry. Is this likely to cause any sort of problem down the track?

I'm guessing that screwing up the menu.lst entries is something the update process probably shouldn't do. Should the fact that it happened be notified to 'somebody'?

Also, I am still perplexed as to why the karmic live cd was unable to boot into safe video mode, and gave me the flashing screen thing. Would still like an answer to that puzzle, but it is a whole lot less "life and death" now.

Thanks again Moozillaaa for helping out...

Regards,

Pcal

[Moozillaaa]

I really don't want to assume I know too much, but would not the instruction above have been looking for /boot/grub/menu.lst on the live cd I booted with, which presumably doesn't exist?


Yep - it sure would have, as I posted it. My mistake.

Search function might have been the correct option there...

I think the UUID # is ONLY for a device, and kernel assignment is by another 'identifier'.

If the correct kernel is loading now, I'd surely make a couple of backups of the menu entries as they are now, because if/when you do a kernel/version upgrade, then if something goes wrong, it might be difficult to see exactly what went wrong.

In fact, now might be the time to experiment with GRUB, manipulate some variables/labels, and see what 'weight' each carries. Then you'd be VERY familiar with GRUB, which will ALWAYS be a necessary skill...

Just my .02

http://genchem.rutgers.edu/cupen.jpg