11.1: How to Completely Reinstall Grub & its Stage1&2 Files?

Due to lack of concentration, I inadvertantly ran PClinux(2009-2)'s “install.sh” while I was in openSuse 11.1. This file says:
grub --device-map=/boot/grub/device.map --batch <<EOF
root (hd0,6)
setup --stage2=/boot/grub/stage2 (hd0,6)

I soon found out that Suse 11.1 would no longer boot from boot.ini (using bootpart) because the boot process now brings up PCLOS (in /dev/sda6) rather than Suse 11.1 sitting in /dev/sda5. No problem, I thought, I’ll boot from the Suse install DVD, use repair, and away I go.

Wrong. After grinding, it started mentioning about generating something for sda13, which is my last partition … NTFS! So I bailed before it got too far. I even tried “rescue” option on the DVD, command prompt, and grub commands to reinstall via “setup …”. No luck.

Then I tried to use Super Grub Disk (.97xx) to reinstall the PBR, stage 1 and stage 2 loaders. Didn’t change a thing. So then I used Grub4DOS and got into my Suse 11.1 installation using this in its menu.lst:
title openSUSE 11.1 -
root (hd0,5)
kernel /boot/vmlinuz
initrd /boot/initrd

… as opposed to 11.1’s menu.lst which says (just the pertinent part):
title openSUSE 11.1 -
root (hd0,5)
kernel /boot/vmlinuz- root=/dev/disk/by-id/ata-WDC_WD3200AAKS-00VYA0_WD-WCARW0763312-part6 resume=/dev/disk/by-id/ata-WDC_WD3200AAKS-00VYA0_WD-WCARW0763312-part11 splash=silent showopts vga=0x375
initrd /boot/initrd-

Worked fine, and is now my (only) method of booting to 11.1. So obviously it’s bypassing stage 1 and 2 files, using it’s native Grub4DOS code. But then I tried Yast-Bootloader to reinstall Grub’s files. No difference. Then I used the advanced part to “write bootloader code to disk” No difference. Even tried “propose a new boot scheme” (or whatnot) … no difference.

After looking at all this, I’ve come to the conclusion that the PBR code in sda5 is scraunched, and/or stage 1 code (although it’s still the original date), or stage 2 (which definitely had a new timestamp of when I committed the fatal error by executing PCLOS’s “install.sh”.

So my question is this: How do I do a good COMPLETE re-install of Suse’s version of the grub files? Because, for sure, grub commands like "setup --stage2=/boot/grub/stage2 (hd0,5), and variations thereof, certainly aren’t doing it? My reasoning is that I should make sure that all the boot files get restored/confirmed as “originally installed by Suse”. TIA.

While running 11.1 booted up via rescue CD, do as root:


BTW I don’t believe that your other OS messed up GRUB’s files, just the MBR, but you can always check with

rpm -V grub

and reinstall with

rpm -i --force grub…rpm

Thanks for the reply. After my boo-boo. I looked at what had changed in /boot & boot/grub according to date/timestamp, and initrd, devicemap (no diff in contents) ,stage2 and (it seems) the code in the PBR has changed, although I have no way of verifying the latter. Stage1 still has it’s original 2008 date.

I agree that the .rpm files installed are still the same, so no need to install the rpm again. But trying “grub-install --recheck hd0,5” at the Rescue Prompt bombs out, principally because there’s no grub.conf in the rescue’s /etc.

I have regenerated the initrd by running “mkinitrd -k /boot/vmlinuz- -i /boot/initrd-”, hopefully putting that file back to Suse’s liking. I also executed “grub-install --recheck hd0,5” while in 11.1 and all it appears to have done is regenned the Stage2 file (date/timestamp).

The problem remains that booting out of the boot.ini in the Fat16/MSDOS (only) primary partition with bootpart (yes, I just recreated a new 512 byte file by bootpart after the above changes) results in hang/message “Grub Loading stage2…”, with no other info and no way to get into grub at that point to investigate further. Since Stage2 error message/causes probably are >25, the lack of clues is frustrating.

The way I’m looking at this is it’s probably a Stage1>2 hand-off problem. Since Stage2 has been regenned a couple of times, most recently a few minutes ago, I don’t think it’s that. The initrd and vmlinuz files are OK, since that’s what Grub4DOS is using to directly boot into 11.1 easily, where I’m writing this now.

More likely the cause lies in PBR/Stage1 code, thus my desire to replace that completely with “factory fresh”. Any more ideas?

The grub-install seems to be a SUSE version. There is an original version in grub-install.unsupported. This one takes the --root-directory= option. While runnng the rescue system, you can do:

grub-install.unsupported --root-directory=/mnt

assuming your target root is mounted at /mnt. You might lose the splash screen and that when you use this version but you can fix it when you boot up to SUSE.

The grub-install seems to be a SUSE version.
also in Open Mepis.

grub-install.unsupported --root-directory=/mnt

That command would write /mnt/boot/grub not /mnt/(hdo,5)/boot/grub. So be sure to put the complete mount point and mount the partition first.

After running the above command you will have to run grub, if you do not , you will see loading grub 2 error.

 root (hd0,5)
 setup (hd0,5)

be sure to put correct info for (hd0,5).

recreated a new 512 byte file by bootpart .

Need to clarify my above post :
grub-install.unsupported –root-directory= would only be use if not installing grub onto the booted linux system. grub-install default directory will be /boot/grub of the booted linux. If you are booted into Suse , do not use --root-directory= option, you use that option only if booted into a different linux.

If you make sure that the target partition is mounted first, both / and /boot, on /mnt and /mnt/boot, then that does what you want. It’s a rescue system, not a repair system, and you have to do some things manually.

Sorry, you’ve lost me. --root-directory doesn’t write anything except the MBR and stage1.5 if necessary. --root-directory is just to tell grub where to find the files it needs to use.

It’s not about whether you are booting another Linux or not, it’s a utility provided by GRUB for installing its boot sector into the MBR.

To clarify and make sure we are both on same page. (I might not be)
I have 2 hdds, (hd0,1) has mepis and (hd1,2) I have a test boot partition.

booted into mepis on (hd0,1)
1)mounted (hd1,2) at /mnt/hdc3
2)Deleted all folders on (hd1,2) /mnt/hdc3 (it now only has lost+found)
3) from root terminal ran

grub-install --root-directory=/mnt/hdc3 "(hd1,2)"
  1. (hda1,2) or hdc3 now has /boot/grub/files.
  2. the boot partition does not yet work, I am sure that now must run install or setup from the grub prompt.

the above command was NOT ran from a grub prompt. It is not the same as running install --root-directory=option from the grub prompt.

Thanks, folks, but let’s recall that I can now run the affected 11.1 Suse, the one on (hd0,5). I think the problem is the PBR, since Grub’s IPL is installed into the first sector of hd0,5.

So if I understand you folks, I should (while in the target 11.1) run:

“grub-install.unsupported”, (no parms/switches) followed by

grub (and then at the Grub Prompt run:)
root (hd0,5) (and then:)
setup (hd0,5)

Just for the record, before I do the above, /boot/grub shows Stage1 still unchanged from 2008 date/timestamp, and Stage2 has been regenned a few times over the past day.

While waiting for a response I figured, what the heck, why not try to reverse the situation using the PCLOS shell script that I inadvertantly executed, that caused this problem. So I copied over the script (in original post), modified the (hd0,6) to (hd0,5) for the target Suse 11.1 install, and let her rip, i.e:

grub --device-map=/boot/grub/device.map --batch <<EOF
root (hd0,5)
setup --stage2=/boot/grub/stage2 (hd0,5)

And you know what? It rebooted perfectly afterwards (after updating boot.ini via bootpart, for the new PBR)! Even the splash screen appeared during booting. So, something learned, I guess. If something causes a problem, why not just try to reverse it using the same script.

Anyway, thanks a lot for your help, and goodnight!

Yes, but I don’t know for sure that running grub-install using Mepis, or whatever, files would work for booting SUSE. My instructions were for the case where you boot to SUSE by whatever means, usually the rescue CD, and then you reinstall the MBR using the same release of GRUB as the target OS. So really there is one OS involved and no complications trying to use GRUB from another OS. Which could be trouble if that OS uses a release of GRUB not patched to understand ext4.