Trying to install openSUSE 11.1 on machines that have multiple Linux installs, with a top-level GRUB installed in the MBR, which chainloads the various OSs/partitions. Problem is that the 11.1 installer either deletes or damages the MBR so that the machine will not boot post install (until I use a rescue disc and reinstall the MBR GRUB).
It certainly seems like I am selecting what should be the correct installation options to prevent this. I go into the Boot Loader Settings screen, click on Boot Loader Installation, and then check only Boot from Root Partition. The installer does install the 11.1 GRUB into the root partition all right, but it also damages or deletes the MBR. This makes no sense to me, and this is the only Linux installer I have ever used where I could not figure out how to prevent the MBR from getting munged. Is there something I am missing–or at least some way to prevent this from happening?? At it stands, we will have to forbid students from installing openSUSE in the lab, as we cannot have the MBR being corrupted by each install.
I’ve done a LOT of experimenting with multi-booting, and the only thing I’ve found that works every time is - hiding the various partitions from the various OSs during installation and bootup.
If you want to try this, here’s an excellent link:
The scheme is suitable for any number of Linux plus any number of non-MS systems like Solaris and BSD.
It took me several days to wrap my mind around the concept of hiding partitions from operating systems, but it works like a charm, once you figure it out.
While this technique hides the partitions from the OSs, all your apps (file managers, players, etc.) will work like normal. It just keeps the OSs from battling each other.
Tell openSUSE not to install a boot loader during installation. Then manually add it to the boot loader of what ever other distro you are using. That’s how I do it and I have several distro’s running all off one bootloader.
We do this (multi-level) bootloaders all the time with a bunch of different distros. It would work fine here (it does after I fix the MBR) if the openSUSE installer wasn’t doing something to the MBR when told to use the root partition. If there is no way to get it to quit corrupting the MBR, I will file a bug report, as this is definitely incorrect behavior. I have installed lots and lots of distros, and while many make it tricky to avoid changing the MBR, this is the first that appears to make it impossible.
We wanted to use this in our Linux lab, where we have a generic top-level GRUB in the MBR with entries for every partition. This allows students to install a new Linux and set its bootloader into the root partition, and it just works, and doesn’t interfere with the other installs. So not installing a bootloader and manually adding SUSE to another bootloader is not an option. This means that we simply will have to forbid the students from installing openSUSE, which is too bad, as it is a nice distro. (Last year for this course we used openSUSE 10.3, and it worked fine–selecting Boot from Root Partition–I have the notes from last year.)
You are right, there is a bug in the YaST Boot Loader module (check the Novell Bugzilla if you wish). Last I looked, it was fixed and being fed into the process which gets it to the Updates repo. But I don’t know if it is there yet. For now, you can do what you want using the grub shell, outside of YaST. Sounds like you have a lot of experience with this, so probably already know how to. (Obviously, this isn’t a fix suitable for students in the long-term, just a temporary workaround.) Essentially, I’m suggesting installing openSUSE without installing the boot loader, and then using LiveCD, the DVD in Rescue, or another distro instance to install grub to the SuSE boot sector.
Two critical details I presume you already know: One distro needs to be the master which controls the MBR and its menu.list controls all other booting. And second, be careful re issues with different kernel versions and the accompanying grub (this conceivably could be what you are encountering rather than the bug ref’d above); there was a major change in the 2.6.2x kernel in libata that changed the disk addressing, but not all distros introduced this change at the same time (one indicator is that all hard disk naming switched from /dev/hdx to /dev/sdx).
Thanks mingus725! I actually had looked at bugzilla but did not find it. Must not have used good search terms I guess.
Right–I know how to fix things (and have already several times while trying variations), but it is unreasonable to expect students to do this, as we already have enough issues with them overwriting the MBR by mistake. Really unfortunate, as I would have recommended openSUSE to them highly. Trying to fight against the “Ubuntu is Linux” tide.
I doubt this is an issue with the GRUB version, as what happens is that after an openSUSE install the BIOS says “no os” and GRUB is not even started. Also, the GRUB is from Mandriva 2009.0, quite recent. I will admit, though, that I have not actually examined the MBR to see what is there, as it doesn’t really matter what is being done to it, just that it is damaged. I will look into the libata issue further though.
What we do in the lab (and I have begun doing on many of my personal machines as well) is to create a one or two sector partition just for the “top-level” GRUB. This works great as distros can come and go from your partitions, and the main bootloader is not affected. We basically set up 8 partitions on the machines for students to use, and then the top-level grub has entries for each of these eight partitions (chainloading). Another advantage of this approach is that it is very easy to reinstall the correct MBR as long as you can get a GRUB shell somehow. Still another advantage is that you can have multiple kernels, etc., for each distro install, and your bootloader menu doesn’t become an unreadable mess. The top-level one will simply list the distros available. Anyway, the idea for this came from the following site if anyone is interested in this: Making a Dedicated Grub Partition
