<< Back to Part 4, Windows via VirtualBox

This is the only blog entry in this series that I have not actually performed on my laptop.  Instead, I experimented with the instructions in a virtual environment, using VirtualBox.  The standard disclaimers apply:

• I am describing a single hard drive system
• Messing around with the partitions and the Master Boot Record (MBR) on a disk can be dangerous.  Always back up your data first.  If you're really nervous (like me) experiment in a virtual environment first.
  

The inspiration for this entry came from a comment posted by Luca Morettoni over on Part 2: Install Ubuntu:

I have only one question: when you update the linux os and the system install a new kernel, *probably* it overwrite the OpenSolaris grub installation, or not? If yes, there is a workaround or I need to reinstall OpenSolaris grub (eg. from a liveCD)?

In my experience, a typical update of a GNU/Linux distribution does not overwrite whatever GRUB you have installed on your hard drive (although the menu.lst entries might get changed).  For example, on my old laptop I did an online update of Ubuntu from 7.04 to 7.10 and the GRUB was unchanged.

Doing a second installation (in other words, a re-install) of a GNU/Linux distribution, however, will typically overwrite whatever GRUB you have installed.  I believe there are also some situations where installing service packs for Windows will overwrite the current MBR, which would mean that the partition with OpenSolaris would no longer be marked as Active.

So the question remains: if the GRUB installed by OpenSolaris 2008.05 gets overwritten or superseded, how do you restore it?

The process is fairly easy.  I started by booting the LiveCD of OpenSolaris 2008.05.  I opened a terminal window after the desktop is displayed.  The command to use is installgrub.  If you look at the man page for installgrub, you will see that it requires three parameters.  The third parameter is the raw-device name.  Note this important piece of information from the man page about that name: "For disk devices, specify the slice where the GRUB menu file is located."

The slice? What's up with that? Since my laptop is an x86 system, I had thought that partitions are the only subdivisions of the hard drive that matter.  As Johan Hartzenberg explains so well in this blog entry, however, that is not the case. OpenSolaris uses slices to do a further subdivision of the partition on which it is installed.

The GRUB menu file is in the root slice, so you will need to know the number for the root slice. To find that out, I used this command:

$ pfexec prtvtoc /dev/rdsk/c5d0s2
*
* /dev/rdsk/c5d0s2 partition map
*
* Dimensions:
*     512 bytes/sector
*      63 sectors/track
*     255 tracks/cylinder
*   16065 sectors/cylinder
*    9297 cylinders
*    9295 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      2    00    4209030 145115145 149324174
       1      3    01      16065   4192965   4209029
       2      5    01          0 149324175 149324174
       8      1    01          0     16065     16064

Notice that the device name that I passed to prtvtoc includes a slice number: s2.  By convention s2 means the "entire disk." And therein lies the potential for confusion.  Within the context of these commands, when run on an x86/x64 system, the "entire disk" means: just the partition of the hard drive that contains OpenSolaris. In the output of prtvtoc the final table has a column heading labeled "Partition."  The "partition" numbers displayed by prtvtoc are not primary or extended partitions on my hard drive - they are instead slices within the primary partition that contains OpenSolaris. 

The Tag value for slice 0 is 2, indicating slice 0 is the root slice.  That means the syntax for the installgrub command would be:

$ pfexec installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c5d0s0 

An important note: by default installgrub does not modify the MBR. And depending on your situation, that might be what you want.  For example, if you are happy with the GRUB that a Linux installation wrote to the MBR then after running installgrub you can chainload the OpenSolaris GRUB by adding an entry to the /boot/grub/menu.lst that is used by your GNU/Linux distribution.  As an example:

title OpenSolaris 2008.05
rootnoverify (hd0,2)
chainloader +1

If, however, you do want the OpenSolaris GRUB installed to the MBR, specify the -m flag on the installgrub command line:

$ pfexec installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c5d0s0 

After installing to the MBR you will see the OpenSolaris GRUB menu when you boot from the hard drive.  If the reason you went through all this was because the installation of a GNU/Linux distribution replaced your OpenSolaris GRUB, then you need to make sure the entries in the menu.lst that the OpenSolaris GRUB uses are correct for your new GNU/Linux kernel.  At the very least, the UUID will be different, as shown in this example: 

# title        Ubuntu 8.04, kernel 2.6.24-16-generic
# root        (hd0,4)
# kernel        /vmlinuz-2.6.24-16-generic root=UUID=61d0afdc-4e12-4d74-a1ae-388ff74d7630 ro quiet splash
# initrd        /initrd.img-2.6.24-16-generic
# quiet

# title        Ubuntu 8.04, kernel 2.6.24-16-generic (recovery mode)
# root        (hd0,4)
# kernel        /vmlinuz-2.6.24-16-generic root=UUID=61d0afdc-4e12-4d74-a1ae-388ff74d7630 ro single
# initrd        /initrd.img-2.6.24-16-generic 

title		Ubuntu 8.04, kernel 2.6.24-16-generic
root		(hd0,4)
kernel		/vmlinuz-2.6.24-16-generic root=UUID=276561b9-09ea-45e7-9fbc-d2f4a273fcd9 ro quiet splash
initrd		/initrd.img-2.6.24-16-generic
quiet

title		Ubuntu 8.04, kernel 2.6.24-16-generic (recovery mode)
root		(hd0,4)
kernel		/vmlinuz-2.6.24-16-generic root=UUID=276561b9-09ea-45e7-9fbc-d2f4a273fcd9 ro single
⁞initrd		/initrd.img-2.6.24-16-generic