Skip Navigation Links | |
Exit Print View | |
![]() |
Booting and Shutting Down Oracle Solaris on x86 Platforms Oracle Solaris 11 Information Library |
1. Booting and Shutting Down an x86 Based System (Overview)
What's New in Booting and Shutting Down a System
Administratively Provided driver.conf Files
x86: Removal of Support for 32-Bit Kernel
Booting and Shutting Down an x86 Based System (Topic Map)
Guidelines for Booting an x86 Based System
What Happens When a System Is Booted to a Multiuser State (Run Level 3)
When to Use Run Levels or Milestones
Overview of the Oracle Solaris Boot Architecture
How the x86 Boot Process Works
Purpose and Function of the GRUB Menu
GRUB Device-Naming Conventions
2. Booting an x86 Based System to a Specified State (Tasks)
3. Shutting Down a System (Tasks)
4. Rebooting an x86 Based System (Tasks)
5. Booting an x86 Based System From the Network (Tasks)
6. Modifying Boot Parameters on an x86 Based System (Tasks)
7. Creating, Administering, and Booting From ZFS Boot Environments on x86 Platforms (Tasks)
8. Keeping an x86 Based System Bootable (Tasks)
SMF provides an infrastructure that augments the traditional UNIX startup scripts, init run levels, and configuration files. With the introduction of SMF, the boot process creates fewer messages now. Services do not display a message by default when they are started. All of the information that was provided by the boot messages can now be found in a log file for each service that is in /var/svc/log. You can use the svcs command to help diagnose boot problems. To generate a message when each service is started during the boot process, use the -v option with the boot command.
When a system is being booted you can select the milestone to boot to or select the level of error messages to be recorded. For instance:
You can choose a specific milestone to boot to using this command:
ok boot -m milestone=milestone
The default milestone is all which starts all enabled services. Another useful milestone is none which starts only init, svc.startd and svc.configd. This milestone provides a very useful debugging environment where services can be started manually. See How to Boot Without Starting Any Services in Oracle Solaris Administration: Common Tasks for instructions on how to use the none milestone.
The run-level equivalents single-user, multi-user, and multi-user-server are also available, but are not commonly used. The multi-user-server milestone, in particular does not start any services which are not a dependency of that milestone, so may not include important services.
You can choose which level of logging for svc.startd using the following command:
ok boot -m logging_level
The logging levels that you can select are quiet, verbose and debug. See SMF Service Error Logging in Oracle Solaris Administration: Common Tasks for specific information about the logging levels.
Most of the features that are provided by SMF occur behind the scenes, so users are not typically aware of these features. Other features are accessed by new commands.
Here is a list of the behavior changes that are most visible:
The boot process creates many fewer messages now. Services do not display a message by default when they are started. All of the information that was provided by the boot messages can now be found in a log file for each service that is in /var/svc/log. You can use the svcs command to help diagnose boot problems. In addition, you can use the -v option to the boot command, which generates a message when each service is started during the boot process.
Because services are automatically restarted if possible, it might seem that a process fails to terminate. If the service is defective, the service is placed in maintenance mode, but normally a service is restarted if the process for the service is terminated. The svcadm command should be used to stop the processes of any SMF service that should not be running.
Many of the scripts in /etc/init.d and /etc/rc*.d have been removed. The scripts are no longer needed to enable or disable a service. Entries from /etc/inittab have also been removed so that the services can be administered by using SMF. Scripts and inittab entries that are provided by an ISV or are locally developed will continue to run. The services might not start at exactly the same point in the boot process, but they are not started before the SMF services..