GRUB seriously broke

[doctordruidphd]

I did something which I shouldn't have, and I think it exposed a problem that may have been there for a while.

I normally boot from (hd0) with the system located on /dev/sda1. I was setting up a backup disk so that it would be bootable. So I booted the system on /dev/sdc1, and did a 'sudo grub-setup (hd2)' . OK, that seems to have done what I wanted.

Problem is: now that I have removed the hd2 disk, I can't boot. It evidently did something to the MBR on hd0.
So, I booted with a supergrubdisk.

root=(hd0,msdos1)
linux = /vmlinuz root=/dev/sda1 ro
initrd = /initrd.img

Tried to boot, and get a "?/normal.mod" error of some kind.

OK, in looking through /dev/sda1/boot/grub/grub.cfg I find that all of the entires that should point to (hd0,msdos1) now point to (hd2,msdos1). In other words, something thinks the root drive should be hd2, when it isn't even there.

I tried running 'sudo grub-setup '(hd0)' and it gave no errors, but when I do an update-grub, the same problem occurs.
I can fix this by manually editing grub.cfg so everything points to (hd0,msdos1), but it's going to break every time update-grub runs.

Anyone know where the (hd2) part has been set? Or why 'grub-setup '(hd0)' ' isn't fixing it?

This is 11.10

[dibl]

I think "os-prober" screwed you, when you were installing to the new disk. You'll have to reinstall grub. In a live CD session, mount your /sda1 partition, and then run grub-install using the --rootdirectory=/mnt/sda2 (or however you mount it) option, to /dev/sda.

[doctordruidphd]

OK, a couple more things --

fixing grub.cfg doesn't work, the problem looks like it's in the MBR.

I ran:
sudo grub-setup --root-device='(hd0)' --directory=/boot/grub '(hd0)'

didn't fix it.

Of course LiveCDs (nor alterante CDs) won't boot on this system. Old problem, evidently not fixable.

Now when I run update-grub, I am getting "dpkg: error: version 'exp' has bad syntax: version number does not start with digit" errors. WTF with this??

I tired copying over an old grub.cfg from last week, still won't boot, same error.

[dibl]

grub-setup won't do it. You'll have to use grub-install, I believe. If you mount your OS partition at /mnt/sda1 on the Live CD session, then

sudo grub-install --root-directory=/mnt/sda1 /dev/sda

I think you'll fix it.

[doctordruidphd]

I'm not sure that's even possible, given that livecd's won't boot on this system.

I'll download another and see if I can get the $%^&*( to boot.

There is a serious problem somewhere. I have unplugged all of the disks except /dev/sda
I ran just plain "grub-setup --verbose /dev/sda" and it's saying the roort device is (hd2,msdos1)
Maybe that's what the BIOS thinks it is, but grub rescue sees it as (hd0,msdos1) so there is a major miscommunication somewhere. Next I'll try switching the disks around I guess.

[dibl]

I'm not sure that's even possible, given that livecd's won't boot on this system.

That's not good. You'll need to boot an OS that has Grub2, somehow, before you can reinstall it.

[doctordruidphd]

solved. Operator error, as usual.

When I did the setup for /dev/sdc, it messed up the mbr on sda. Expected, sort of.

Booted with a SuperGrubDisk (never leave home without it...), which for some very strange reason, by the way, does not recognize my 11.10 system on sda1, but sees the precise system on sda2. Another trauma for another day....

So I tried to repair using grub-install, with the root-directory pointing to /dev/sda1/boot/grub. That's where it messed up -- as a result of doing that, it was looking for normal.mod in /boot/grub/boot/grub.

OK, so got into the sda system and ran

sudo grub-install --root-directory=/ /dev/sda

fixed.

Thanks dibl.

[SecretCode]

How is it that you can boot supergrubdisk but you can't boot from a live CD or alternate CD?

(And what I really want to know is ... might I get into the same difficult state?)

[doctordruidphd]

Beats me. The issue, which is with debian kernels in general -- I can't boot debian liveCDs either -- has to do with memory allocation on some 64-bit systems, most notably Dell. It isn't just me that has the problem, but all the posters I saw on the various places I found discussing it did in fact have Dell 64-bit systems.

There is a workaround involving booting with the kernel MEM option, but you have to calculate the number based on how may gb of ram you have.

However, I downloaded the current 11.10 kubuntu live CD, and it actually booted without any special parameters, so I take it the issue is solved. Nothing in the 9, 10, or 11.04 series would ever boot without the workaround. Haven't tried a current debian (6.x) cd yet.

Best way to find out if you have a problem is to download a live CD for your architecture and see if it boots. (The other problem is that the 32-bit cds won't boot on this system, no how, but I don't much care.)

[SteveRiley]

Maybe it's time for GRUB to move on...it sure has become overly complicated.

Phoronix reports that a new version of Gujin is out, perhaps it's worth some time investigating it.

[bra|10n]

From somewhere in among the cobwebs...

I remember reading a post where somebody had installed many many Linux distro's and he/she created a mbr-grub-boot-menu that seemed to link to every distro's own grub install.
I think the reason was that if particular drives weren't connected, then they simply would not appear on the mbr-grub-menu at boot.
I guess a reinstall or distro change on a particular partition would then only require updating a corresponding entry in mbr-grub?

Here: http://www.justlinux.com/forum/showthread.php?t=143973