Background: I partitioned my hard disk when I built this computer several years back, and haven’t repartitioned it since. I have openSUSE, Win7, and 6 other Linux distros on it. (Kubuntu lives on sda1.) When I originally built the computer, I restored openSUSE and my openSUSE home partition from disk images from my old computer, and have done distribution upgrades ever since, so I’d never done a clean install of openSUSE on this computer. Since this computer is 64-bit and my old computer was an i386, I finally did a clean install with v12.3 in order to switch to 64-bit. I downloaded the x86_64 installation DVD and everything went fine.
Except for one thing: I told the installer to put GRUB2 on the root partition (/), not on the MBR, because *buntu’s GRUB2 is already in the MBR and is “in control” of booting all the other distros. But after the installation was complete and I was ready to reboot into openSUSE, I could not boot my computer, because no bootloader was found. Apparently, the openSUSE installer removed the existing GRUB2 from the MBR.
The problem was easy enough to fix (Ubuntu has good GRUB2 documentation), and I’m sure openSUSE does, too. What I’m wondering is, what installer option did I inadvertently miss or screw up?
If it matters, /dev/sda4 (the extended partition) has, for some unknown reason, the boot flag set. It’s been that way for who knows how long and I’ve ignored it since it hasn’t hurt anything.
Also, I don’t chainload openSUSE, although I do have a related question. If I didn’t install GRUB2 at all when I installed openSUSE, would the “master” version of GRUB2 (installed by Ubuntu to the MBR) be able to correctly boot openSUSE and pick up on kernel upgrades? (I suppose there’s an easy way to find out…) I’ve been installing GRUB2 to the root partition (/) of every distro I install, just so that it’ll create the equivalent of a /boot/grub2/grub.cfg file, in the possibly mistaken belief that Ubuntu’s GRUB2’s OS prober needs to see and read that file in order to correctly boot the distro.
On the booting screen, there is an options button. Clicking that gives the “Boot Loader Options” screen.
On that screen, there’s a box “Write generic boot code to MBR”. You failed to make sure that was not checked.
For me, it is usually unchecked by default. I think the installer recognizes that there is Microsoft boot code there. However, on one of my installs, there is Grub boot code from installing Fedora. And on that box, the opensuse installer did want to write generic boot code, which would have caused me similar problems to the ones that you had.
(And I just installed Fedora 19 (the version under development) without installing GRUB2, since their new version of Anaconda doesn’t allow you to install GRUB2 to the root partition; it’s the MBR or nothing. The GRUB2 “in control” of my computer picked up on it and boots into it just fine…at least so far.)
I do it on all Linux machines or machines with a windows / linux mix
What does it matter if say: Ubuntu is already booting
Once SUSE is installed you can boot Ubuntu from SUSE grub and re-install grub from Ubuntu
I must do this almost daily and have done for years, even with Legacy grub
Never failed yet
I do it the way I do because I have the background I like set; the screen resolution I like set; and I don’t have to think twice about what partition GRUB2’s configuration files are located on. And it’s no big deal to boot into Kubuntu and run “update-grub” (which is an Ubuntu alias for “grub-mkconfig -o /boot/grub/grub.cfg”) after installing a new distro.
As noted above, if one follows the YaST Installer menu’s and tab’s options carefully, it is possible to install openSUSE such that it does not touch the MBR.
Having typed that, I had the following taught to me on an openSUSE forum thread, and re-inforced to me in a GNU/Linux User group by a couple debian users (whose view was this is important for all GNU/Linux distributions), which is to backup one’s MBR with ‘dd’. Its not really something for a beginner, but an average user who exercises care can run the following with root permissions (to create the file ‘MBR-backup-440’ and save that file (preferably IMHO on a USB stick).
dd if=/dev/sda of=MBR-backup-440 bs=440 count=1
where in my example I am assuming the hard drive is ‘sda’ …
and then if the MBR is over written, one can always restore back to the original by copying that file back to the MBR with the command
dd if=MBR-backup-440 of=/dev/sda bs=440 count=1
Because one is using ‘dd’ command, great care is needed.
I do not know how long that sort of ‘dd’ functionality will be so convenient, as computers and hard drives and operating systems are moving to UEFI with GPT where old MBR functionality will no longer be so much in use. And I do not know what arguments to use in ‘dd’ if one wishes to adopt a UEFI/GPT approach. But I have found this useful on a few occasions.
Speaking of which, there is a 512B file in /boot/ named “backup_mbr” (which has the same date stamp of my installation), which may be of use in similar situations.
