I want to install Linux and OpenSolaris on the same hard disk in different partitions. I'm worried because OpenSolaris seems to actively manage the grub data when updating the OS (part of the "boot environment" feature). Is there anything I should prepare for to prevent my grub data from getting clobbered. If I later want to add another version of linux to the same system, what are the considerations? Should I choose one OS and always do grub updates from that one OS? If so, then how do I use the installation iso for a new version of Linux? Won't it go ahead and modify the grub data on its own? Once I've already booted into Linux, and I want to udpate my grub files, should I run a grub command that reads the data from the boot section of the drive, and puts it into the local filesystem I'm currently booted into?

  • This is more of an IT question, and not appropriate for SO. It's a good question but belongs elsewhere.
    – swilliams
    Oct 29 '08 at 17:33
  • Reopened. In a development environment, a programmer might be running both of these Operating Systems (or two similar OSes) and run across this problem, which would prevent booting and therefore stop development. Oct 29 '08 at 17:34
  • Programmers need to eat and sleep, but that doesn't make those acceptable topics on SO. Just because it affects programmers doesn't make it programming-related.
    – ephemient
    Oct 29 '08 at 17:41
  • Eating and sleeping aren't technical. This is a valid, technical question that helps a programmer get his/her job done. I think it's just as acceptable as finding the right chair, tools for time tracking, and that kind of thing. Oct 29 '08 at 17:47
  • I wanted to defend swilliams's reasoning. I am not sure if this is a question suitable for SO or not, it is in what I perceive to be a gray area (until the FAQs clarify further or the community votes).
    – ephemient
    Oct 29 '08 at 17:51

You're going to have to tell one OS or the other not to automatically clobber the GRUB boot sector.

All Linux distros that I've seen have some way to prevent their installation CD from clobbering the boot sector, but it's often in some obscure advanced option.

The majority of GRUB's configuration data is not stored in the very small boot sector, which just contains a small loader program and a pointer to where to find the rest. The configuration data is usually stored in a regular directory in a regular partition on the drive (/boot under many Linux distros). So unless Solaris is actually going in and monkeying with the data on the Linux partition, it's probably not a huge deal... if one OS clobbers the boot sector created by the other, you can easily recover it.


Grub is a program just like any other. There is a small section at the beginning of your hard drive (the master boot record) which points which program should be used to load operating systems. This is the thing which gets clobbered when you install a new grub. It is possible, however, to choose not to install grub with a new OS (except Windows, which should always be installed first in a multi-boot system). If you choose not to install grub, you must configure the grub of the original system to recognize the new one. In other words, you control the grub of all operating systems from one (in this case, it looks like solaris would be the best choice if it is that aggressive). From within this OS, adding other options to your grub is very easy. In /boot/grub/menu.lst you can add new options and select their order. For example, I run Ubuntu, Windows, and Gentoo to play around with. My menu.lst contains the entries:

title       Ubuntu 8.04.1, kernel 2.6.24-18-generic
root        (hd1,0)
kernel      /boot/vmlinuz-2.6.24-18-generic root=UUID=887466bc-8a0d-4408-
17a-91ec1cfd9f2a ro quiet splash vga=795
initrd      /boot/initrd.img-2.6.24-18-generic

title       Microsoft Windows XP Professional
root        (hd0,0)
chainloader +1

title       Gentoo Linux 2.6.25-gentoo-r7
root        (hd0,1)
kernel      /boot/kernel-2.6.25-gentoo-r7 root=/dev/hdb2

Each of these contains basic information about the system I want to load, including name, hard drive location (disk and partition) and where on that disk the thing to load is. Notice, since Windows wants to load itself, we let grub know that its going to chainload by finding the Windows bootloader on disk 0 partition 0 (right at the beginning), and running that instead. For a linux system, you really only need the name, root drive, and kernel location to add a new on to your grub menu.

If you later install a linux, and do forget to skip grub installation, you can also copy the menu.lst from one to another.


I think you're better of running one of the OS's as a Virtual Machine.

With a modern CPU that supports VM extensions and a couple of GB RAM, you can run 3-4 machines easily. Use the following snippet to check if your CPU supports them.

egrep '^flags.*(vmx|svm)' /proc/cpuinfo

There are plenty of options for this: Xen, kvm, VirtualBox, VMware.


The last time I set up a dual boot system (before the days of virtual machines as in the previous person's answer), it used to give you the option of making a boot floppy. This was useful, because then after you installed another OS and it wrote all over the Master Boot Record, you could boot from the floppy, set up Grub to chain load the other OSes, and reinstall it on the MBR. I don't know what the modern equivalent is, because I use VMware.


Don't share /boot between OSes, it's just more work. The default for most modern distros is to have a single / filesystem, with /boot being just a subdirectory, but even if /boot is its own partition, it'll be fine with a separate one per OS.

Each OS will then manage its own /boot, and one of them will be the default bootable partition -- you should be able to easily configure it to chainload the other. Grub can install its headers into only its own partition without affecting the whole disk.

  • The problem isn't the /boot partition, it's that a lot of installation programs put their own stuff in the Master Boot Record without respecting what's there already. Oct 29 '08 at 18:36
  • Nothing post-install should be touching the MBR without your permission, and you can easily fix up the multiple grub installs after installation. That being said, I know Debian asks if you want to install grub to the disk or partition, and I would expect similar options in other installers.
    – ephemient
    Oct 29 '08 at 18:45

you can try installing both WITHOUT grub, and just keep a cd containing super grub which will allow you to boot either OS.

Super Grub Disk is this utlity which once run, runs grub and you can choose your OS, fix the grub on your MBR, and others.

i think you can also create a boot disk aside from grub or lilo. i'm not sure how it's done however.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.