How to resurrect GRUB boot

Although SUSE is my day-to-day operating system, I often try out other distros, popping a spare hard drive into the machine and installing it on that, so I don’t touch my SUSE installation. Since nothing teaches caution better than disaster (and I’ve had a few), I normally unplug my SUSE disk while I do the installation on the other drive. This time, while giving Ubuntu a spin, I neglected to do this. I soon realized that the Ubuntu disk had taken over the boot process, and I could no longer boot from the SUSE disk. Running the YAST boot config didn’t fix the problem. I’ve run into this before both with a Windows drive - which was easily fixed using the FDISK utility to restore the MBR - and a once before with SUSE. Luckily, I had a recent disk image that time and in this recent instance that I could restore. So my question is, how does one go about fixing the SUSE boot from a running (but booted from the other operating system) SUSE system? Is it necessary to re-install GRUB, and if so, how does one go about this? I presume it involves only restoring the MBR and stage 1 boot, since the system is still bootable from the other operating system’s GRUB.

Hi !

That sounds nice.

However, as you report, in the current case that wasn’t the way things went.

Anyway, how do you come to the following conclusion

You seem to have several hard disks.

So, which MBR on which disk do you mean, exactly?

Please enter a terminal, become root, enter ‘parted -l’, wait a bit, and post the results here.

If it only needs restoring the MBR, then you can use “dd” as root. There is probably a file “/boot/backup_mbr” which saves the MBR as at the time of opensuse install.

To restore that, I would use:

# dd if=/boot/backup_mbr of=/dev/sda bs=440 count=1

This assumes that you are booting from a partition in “/dev/sda”. The “bs=440” sets the blocksize for the write. The idea is to write back only 440 bytes. That includes the boot code part of the MBR, but does not overwrite the partition table. This probably puts back the generic boot code that came from Windows. If you originally installed grub into the MBR, then you probably need to also reinstall grub.

If you also want to update or reinstall grub, you can do that with Yast → bootloader. It wouldn’t hurt to do that after fixing the MBR, but before rebooting. In some cases, you might need to run the grub2-install command as root.

This depends on how your openSUSE bootloader was configured (and probably openSUSE version that you did not mention). For a start show output of “grep LOADER_TYPE /etc/sysconfig/bootloader”.

Sorry I wasn’t more clear on that. The SUSE drive. I want to make it able to boot on its own again, after the Ubuntu installation on the second disk has taken over its boot process, and I’ve subsequently removed the Ubuntu-containing drive from the computer.

# dd if=/boot/backup_mbr of=/dev/sda bs=440 count=1

Of course, that makes sense. I didn’t realize the MBR had a backup on the drive itself. Back in the old days, when LILO was still the Linux boot device, I used to use dd to put a copy of the MBR in a file on my Windows NT disk, so I could use the Windows boot loader to dual-boot either NT or Linux - that would have been SuSE 6.1, many years ago. I’ve since forgotten a good many of the CLI tricks that I used to know.

No Windows involved this time, just SUSE and Ubuntu! I was only mentioning the Fdisk experience as an example of the sort of thing I wanted to be able to do in a Linux system, i.e., restoring the MBR to its original state.

Ok, I can see that, and seems like the logical route for trying to set things back in order. I’ll put this advice in my LinuxHowTo file for later reference, in case I hose the boot again. As I’ve said, I finally fixed things by restoring a recent disk image, but I knew there had to be a simpler way, working within the system itself.

The Loader is grub-2. Yes, sorry, I forgot to make the distinction, is is OpenSUSE. You bring up an interesting point, however, in that I don’t know exactly how the bootloader was originally configured, nor exactly what changes were made to it by installing Ubuntu on the second disk. I can only assume that it hosed the MBR (and with luck, only that), taking over stage 1, while most likely leaving the rest of the boot process untouched.

I never mess about disconnecting hdd’s
I just let whatever take control and switch back to the one I want in control

I’m unclear what you have:

But if say Ubuntu takes control
You will have an option to boot SUSE from Ubuntu, so boot it
Once in openSUSE do

su -
grub2-mkconfig -o /boot/grub2/grub.cfg

grub2-install /dev/sda

I want to point out that I only disconnect the drives during new installations. Some distros’ setup programs will muck around with other systems on the computer if they find them. Disconnecting assures that they mind their own business during installation, then later, I can hook the disk(s) back up, and run the appropriate grub configuration programs (such as Debian’s update-grub) for each system. This way, I can boot any drive independently, and also boot any system from any other grub menu.

Now, after discovering and reading /boot/boot.readme, I have a much better idea what’s going on and how to fix things when they go wrong. However, just as an aside, wouldn’t that second command most likely be /dev/sdb under these circumstance? - Not that I wouldn’t make sure to check the drive designations myself before executing such a command!

At any rate, I think the solution was staring me in the face the whole time. When I looked, the YAST boot config utility was showing “custom boot partition” and also displaying the name of the Western DIgital drive where Ubuntu had been installed (instead of my SSD, where OpenSUSE resides) in the drop-down list, instead of /dev/sda. I’m sure that if I’d checked the “boot from root partition”, reset the drive designation to /dev/sda (as these settings had been originally), and then clicked OK to run the utility, it would have set everything back right. I’d actually tried both these, but not at the same time. I just wasn’t thinking clearly at 1 AM last night. There’s nothing like “boot device not found” to send one into a state of panic and make things worse before making them better.

Thanks to all for your insightful comments, and I appreciate everyone taking the time to reply.

Well. I always have the same HDD as sda
And it’s what I would recommend.
But if you habitually pull HDD’s, when you reconnect they will likely move assignment

I always custom set the partitioning at install and set belt and braces grub like this

Please paste content of /etc/default/grub_installdevice.