| Skip Navigation Links | |
| Exit Print View | |
|
Booting and Shutting Down Oracle Solaris on SPARC Platforms Oracle Solaris 11 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Booting and Shutting Down Oracle Solaris on SPARC Platforms Oracle Solaris 11 Information Library |
1. Booting and Shutting Down a SPARC Based System (Overview)
What's New in Booting and Shutting Down a System
Administratively Provided driver.conf Files
Fast Reboot on SPARC Platforms
Booting and Shutting Down a SPARC Based System (Topic Map)
Guidelines for Booting a System
Service Management Facility and Booting
Changes in Behavior When Using SMF
What Happens When a System Is Booted to a Multiuser State (Run Level 3)
When to Use Run Levels or Milestones
2. Booting a SPARC Based System to a Specified State (Tasks)
3. Shutting Down a System (Tasks)
4. Rebooting a SPARC Based System (Tasks)
5. Booting a SPARC Based System From the Network (Tasks)
6. Modifying Boot Parameters on a SPARC Based System (Tasks)
7. Creating, Administering, and Booting From ZFS Boot Environments on SPARC Platforms (Tasks)
8. Keeping a SPARC Based System Bootable (Tasks)
The Oracle Solaris SPARC boot architecture includes the following fundamental characteristics:
Use of a boot archive
The boot archive is a ramdisk image that contains all of the files that are required for booting a system.
Use of a boot administrative interface to maintain the integrity of the Oracle Solaris boot archives
The bootadm command handles the details of boot archive update and verification. During an installation or upgrade, the bootadm command creates an initial boot archive. During the process of a normal system shutdown, the shutdown process compares the boot archive's contents with the root file system. If there have been updates to the system such as drivers or configuration files, the boot archive is rebuilt to include these changes so that upon reboot, the boot archive and root file system are synchronized. You can use the bootadm command to manually update the boot archive. For instructions, see Maintaining the Integrity of the Boot Archives.
Note - Some bootadm command options do not apply to SPARC platforms.
For more information, see the bootadm(1M) and boot(1M) man pages.
Use of a ramdisk image as the root file system during installation
This process is the same on the SPARC and x86 platforms. The ramdisk image is derived from the boot archive and then transferred to the system from the boot device.
Note - On SPARC platforms, the OpenBoot PROM continues to be used to access the boot device and to transfer the boot archive to the system's memory.
In the case of a software installation, the ramdisk image is the root file system that is used for the entire installation process. Use of a ramdisk image speeds up the boot process because Oracle Solaris and any drivers and necessary applications are read one time from the removable media and placed into memory. The system then executes the installation process based on the RAM disk. The ramdisk file system type can be a High Sierra File System (HSFS).
This section describes the basic boot process on Oracle Solaris SPARC platforms. For more information about boot processes on specific hardware types, including systems that have service processors and system that have multiple physical domains, see the product documentation for your specific hardware at http://www.oracle.com/technetwork/indexes/documentation/index.html.
The process of loading and executing a stand-alone program is called bootstrapping. Typically, the stand-alone program is the operating system kernel. However, any stand-alone program can be booted instead of the kernel.
On SPARC platforms, the bootstrap process consists of the following basic phases:
After you turn on a system, the system firmware (PROM) executes a power-on self-test (POST).
After the test has been successfully completed, the firmware attempts to autoboot, if the appropriate flag has been set in the non-volatile storage area that is used by the machine's firmware.
The second-level program is either a file system-specific boot block, when you booting from a disk, or inetboot or wanboot, when you are booting across the network or using the Automated Installer (AI) utility.
The network booting process is as follows:
First, the client obtains an IP address and any other parameters that are required to load the second-stage booter.
Next, the second-stage booter loads the boot archive from the boot device.
For more information about booting a SPARC based system from the network, see Chapter 5, Booting a SPARC Based System From the Network (Tasks).
Starting with the Oracle Solaris 10 release, boot processes on SPARC platforms have been modified and enhanced to increase commonality with x86 platforms.
The following four boot phases are now independent of each other:
Open Boot PROM phase
The Open Boot PROM (OBP) phase of the boot process on SPARC platforms is unchanged.
For disk devices, the firmware driver usually uses the OBP label package's load method, which parses the VTOC label at the beginning of the disk to locate the specified partition. Sectors 1–15 of the partition are then read into the system's memory. This area is commonly called the boot block and usually contains a file system reader.
Booter phase
During this phase the boot archive is read and executed. Note that this is the only phase of the boot process that requires knowledge of the boot file system format. Protocols that are used for the transfer of the boot loader and the boot archive include local disk access, NFS, and HTTP.
Ramdisk phase
The ramdisk is a boot archive that is comprised of kernel modules and any other components that are required to boot an instance of Oracle Solaris.
Kernel phase
The kernel phase is the final stage of the boot process. During this phase, Oracle Solaris is initialized and a minimal root file system is mounted on the ramdisk that was constructed from the boot archive. In some environments, such as an installation, the ramdisk is used as the root file system and remains mounted. The ramdisk contains a set of kernel files and drivers that is sufficient to mount the root file system on the specified root device.
The kernel then extracts the remaining primary modules from the boot archive, initializes itself, mounts the real root file system, then discards the boot archive.
|