Introduction to the Boot Process
When an x86-based system powers on, the BIOS initializes the CPU, memory, and platform hardware. Upon completion, the BIOS loads the initial bootstrap software (that is, the bootloader) from the configured boot device and hands control over to the bootloader. The Solaris 10 3/05 OS and earlier releases use a Sun-developed bootloader that includes an interactive shell and a menu-driven device configuration assistant based on realmode drivers.
Starting with the Solaris 10 1/06 release, the open source GRUB or GNU GRand Unified Bootloader is used as the bootloader. The initial delivery is based on GRUB version 0.95 and will be updated as newer versions become available. The Solaris kernel is fully compliant with the Multiboot Specification (reference 2); hence, the Solaris OS can be booted via any bootloader implementing the Multiboot Specification.
The switch to GRUB brings several benefits to Solaris customers.
With GRUB it is very easy to specify kernel and boot options in the boot menu.
For end users, booting and installing from USB DVD drives is now supported.
It is easier for the Solaris OS to coexist with other operating systems on the same machine. In particular, it is possible for the Solaris OS to share the same GRUB bootloader with Linux.
Deploying the Solaris OS via the network is also simplified, particularly in the area of DHCP server setup. Vendor-specific options are no longer required in the DHCP server setup.
Developers no longer need to deal with realmode drivers, which were part of the bootloader required for previous Solaris releases.
For IHVs, it is now possible to deliver drivers at install time via CD/DVD in addition to floppies.
Finally, by adopting a bootloader developed by the open source community, Sun's customers can leverage the considerable GRUB experience gained within that community.
2. Booting the Solaris OS With GRUB
Once GRUB gains control, it displays a menu on the console asking the user to choose an OS instance to boot. The user may pick a menu item, modify a menu item using the built-in editor, or manually load an OS kernel in command mode. To boot the Solaris OS, GRUB must load a boot_archive file and a "multiboot" program. The boot archive is a ramdisk image containing Solaris kernel modules and data. GRUB simply puts it in memory without any interpretation. The multiboot program is an ELF executable with a Multiboot Specification-compliant header. Once loading is complete, GRUB hands control over to the multiboot program. GRUB itself then becomes inactive, and its memory is reclaimed.
The multiboot program is responsible for assembling core kernel modules in memory by reading the boot_archive, and passing boot-related information (as specified in the Multiboot Specification) to the kernel. Note that the multiboot program goes hand-in-hand with the boot_archive file. You cannot mix and match multiboot and boot_archive information from different releases or OS instances.
Once the kernel gains control, it will initialize CPU, memory, and I/O devices, and it will mount the root file system on the device as specified by the bootpath property with a file system type as specified by the property fstype. Properties can be set in /boot/solaris/bootenv.rc via the eeprom(1M) command or in the GRUB command line via the GRUB menu or shell. If the properties are not specified, the root file system defaults to UFS on /devices/ramdisk:a, which is the case when booting the install miniroot.
3. Installation
The Solaris OS may be installed from CD, DVD, and net install servers. The Solaris 10 1/06 release differs from the Solaris 10 3/05 release in several ways:
Minimum memory requirement: The system must have 256MB of main memory to boot the install miniroot. Systems with insufficient memory will get a message from GRUB: "Selected item can not fit in memory".
USB drive support: Installation from CD/DVD drives connected via USB interfaces is fully supported.
Net install: The standard procedure for setting up net install images remains the same. Clients are assumed to boot via the Preboot eXecution Environment (PXE) mechanism. Clients not capable of PXE boot can use a GRUB floppy (see Appendix B).
When booting the install miniroot, a GRUB menu is displayed. A user may interactively edit boot options (see section 4.2). After GRUB loads the Solaris OS, the following install menu is displayed:
1. Solaris Interactive (default)
2. Custom JumpStart
3. Solaris Interactive Text (Desktop session)
4. Solaris Interactive Text (Console session)
5. Apply driver updates
6. Single user shell
The Device Configuration Assistant and associated interactive shell, which users are familiar with from the Solaris 10 3/05 OS and earlier, are no longer present. Users wishing to add drivers required during install (for example, host adapter drivers) should choose option 5 and supply an ITU (Install Time Update) floppy or CD/DVD.
Option 6 is available for system recovery. It provides quick access to a root prompt without going through system identification. This option is identical to booting a Solaris Failsafe session (see section 4.4).
4. Managing the Boot Subsystem
4.1 BIOS
It is generally a good idea to update the BIOS firmware to the latest revision before installing the Solaris OS. This is typically accomplished by visiting the support page for the vendor that manufactured the computer.
Compared to the Solaris 10 3/05 release, the Solaris 10 1/06 OS uses a different subset of BIOS features. In particular, the kernel makes use of more information from the Advanced Configuration and Power Management Interface (ACPI) table, using the parser from Intel's ACPI CA software.
On systems that do not conform to BIOS 2.0 specifications, the syslog may contain messages related to parsing the ACPI table, such as:
ACPI-0725: *** Warning:
Type override - [4s] had invalid type (DEB_[\200IODB
Such messages are harmless and do not impact normal system operation. If ACPI errors prevent normal system boot, the user can disable the ACPI parser by setting acpi-user-options to 2 (see eeprom(1M)) in the kernel line of the GRUB menu:
kernel .. -B ...,acpi-user-options=2
In this case, the system assumes a set of standard ISA devices is present, including a keyboard, a mouse, two serial ports, and a parallel port.
4.2 Boot Options
To boot the Solaris OS, a user may specify the kernel to load, options to be passed to the kernel (see kernel(1M)), and a list of property names and values to customize system behaviors (see eeprom(1M)). At Solaris installation time, a set of default values are chosen for the system and stored in /boot/solaris/bootenv.rc. Users may change the settings by editing the GRUB menu or modifying the bootenv.rc file indirectly via the eeprom(1M) command.
Specifying kernel name and kernel options via eeprom requires setting the boot-file property. To boot the 32-bit kernel in verbose mode, run the following command:
# eeprom boot-file="kernel/unix -v"
To specify the same thing on the GRUB menu, modify the kernel command of the GRUB menu from:
kernel /platform/i86pc/multiboot
to:
kernel /platform/i86pc/multiboot kernel/unix -v
See kernel(1M) for additional boot arguments that the Solaris kernel accepts.
Properties other than boot-file can be specified on the GRUB kernel command line with this syntax:
kernel /platform/i86pc/multiboot -B prop1=val1[,prop2=val2...]
To configure the serial console on ttya (com1), set the console property to ttya:
kernel /platform/i86pc/multiboot -B console=ttya
If the property value contains commas, the value should be quoted. The following GRUB command sets the Solaris console to ttya in high speed.
kernel /platform/i86pc/multiboot -B console=ttya,ttya-mode="115200,8,n,1,-"
In short, specifying "-B foo=bar" in the GRUB menu is equivalent to running "eeprom foo=bar". The -B option in GRUB is primarily for temporary overrides. Permanent settings should be specified via eeprom(1M) so that they are preserved by the Solaris upgrade process.
4.3 Boot Archive
The boot archive refers to the file platform/i86pc/boot_archive. It is a collection of core kernel modules and configuration files packed in either UFS or ISOFS format. At boot time, GRUB loads the boot archive into system memory. The kernel can now initialize itself from data and text in the boot archive without performing I/O to the root device. Once the kernel gains sufficient I/O capability, it will mount the root file system on the real root device as specified by the bootpath property. At this point, the boot archive loaded by GRUB is discarded from memory.
The content of the boot archive is specified in /boot/solaris/filelist.ramdisk. Upon system shutdown, the system checks for updates to the root file system and updates the boot archive when necessary. The system may manually update the boot archive prior to system shutdown by running the bootadm(1M) command.
4.4 The Failsafe Menu Entry
New to the Solaris 10 1/06 OS is a file, /boot/x86.miniroot-safe, containing a bootable, standalone Solaris image. This file can be loaded by choosing the Solaris failsafe entry from the GRUB menu. This is for the convenience of system administrators when the normal entry fails to boot.
Suppose you add a new package containing a faulty driver, and the system panics at boot time. Upon reboot, you can pick the Solaris failsafe menu entry. While in the failsafe session, mount the root file system on /a and run pkgrm -R to remove the faulty package. Once this is complete, you can reboot to the normal Solaris entry to resume system operation.
The file /boot/x86.miniroot-safe can also be copied to portable media, such as a USB stick, as a recovery tool.
4.5 Keeping the System Bootable
To ensure that the system remains bootable, the GRUB boot blocks, the GRUB menu, and the boot archive must be up-to-date.
The GRUB boot blocks reside in the Solaris partition. If the boot blocks become corrupt, they should be reinstalled using the installgrub(1M) command. Note that installboot(1M) and fmthard(1M) cannot be used to write GRUB boot blocks.
The GRUB menu resides in /boot/grub/menu.lst (or /stubboot/boot/grub/menu.lst if a Solaris boot partition is used). The menu is maintained with the bootadm(1M) update-menu subcommand. Because GRUB names disks by the BIOS disk number, a change in BIOS boot device configuration may render GRUB menu entries invalid in some cases. Running bootadm update-menu will create the correct menu entry in such cases.
The boot archive must be updated as the root file system is modified. In cases of system failure (power failure or kernel panic) immediately following a kernel file update, the boot archive may be out of sync with the root file system. In such cases, the system/boot-archive service, managed through the Solaris Service Manager (see svcadm(1M) for example), will fail on the next reboot. Solaris will print a message telling the user that it is still possible to boot and clear the event that triggered the error, but it is safer to reboot the system, select failsafe session, and update the boot archive while in the failsafe session.
