Go to main content

Booting and Shutting Down Oracle® Solaris 11.3 Systems

Exit Print View

Updated: October 2017
 
 

x86: How GRUB Legacy Menu Entries Are Migrated to GRUB 2

After upgrading to a version of Oracle Solaris that supports GRUB 2, all of the Oracle Solaris menu entries are automatically migrated from the GRUB Legacy menu.lst file to the new grub.cfg file. Any chainloader entries are also migrated. When the system reboots, only those boot entries that were migrated are displayed in the main GRUB menu. Any other boot entries that you want displayed in the main GRUB menu must be manually converted and added to the custom.cfg file. See Customizing the GRUB Configuration.


Note -  All of the boot entries from the menu.lst file are present in the GRUB Legacy submenu for that root pool.

It is also important to note that GRUB 2 can directly boot all supported releases of Oracle Solaris 11, as well as Oracle Solaris 10 releases, starting with the Solaris 10 1/06 release. Previous Oracle Solaris releases can be booted indirectly by using the chainloading mechanism. You can add menu entries that use chainloading to the custom.cfg file in the same way that other custom entries are added.

Although the principle of chainloading is the same for GRUB 2 as it is for GRUB Legacy, the syntax is slightly different. In the following example, the entry is chainloaded to the master boot record (MBR) on disk 0. This type of chainloading is useful only if GRUB 2 is not installed in that location. Note also that chainloading this way only works on systems with BIOS firmware (which includes all Oracle Solaris 10 systems).

menuentry "Boot from Hard Disk" {
               set root=(hd0)
               chainloader --force +1
       }

In the following example, Oracle Solaris 10 is installed in the second DOS partition. In addition, the Oracle Solaris 10 version of GRUB Legacy is installed into the partition boot record (PBR) of that partition.

menuentry "Solaris 10" {
               set root=(hd0,msdos2)
               chainloader --force +1
       }

In this example, the entry is chainloaded to the Oracle Solaris 10 GRUB Legacy menu. The result is that there a two levels of menus: one to chainload from GRUB 2 to the Oracle Solaris 10 GRUB Legacy menu, and one to boot the Oracle Solaris 10 kernel from the Oracle Solaris 10 GRUB Legacy menu. To boot the system, you must select the appropriate Oracle Solaris 10 menu entry.

In addition to the Oracle Solaris menu entries that were converted from the menu.lst file, there is one submenu for each root pool that contains a GRUB Legacy menu.lst file. This submenu includes all of the menu entries in the respective menu.lst file and provides access to all menu.lst entries for maximum backward compatibility.

When booting back to an Oracle Solaris boot environment that does not contain the prerequisite packages for GRUB 2, changes to the boot configuration, for example, those that are made by using the beadm and bootadm commands, are only made to the menu.lst file for the appropriate root pool. If you then reboot the system, the GRUB 2 menu does not reflect those changes. Only the Legacy GRUB submenu for the appropriate root pool reflects the changes.

Additionally, these changes do not show up in the main GRUB menu until a GRUB 2 aware boot environment is booted, and the grub.cfg file is regenerated. Wherever possible, when a system runs a boot environment that uses GRUB 2, the menu.lst file is synchronized with the grub.cfg file. This synchronization occurs whenever the beadm or bootadm command is used to make changes to the GRUB 2 configuration.