The same commands from previous sections are used to reboot a system, but the reboot command is more commonly used.
However, for systems running on multiuser state, you might want to issue the shutdown command first. The command sends out notifications to users who are logged in. Thus, they can save their work and log out properly.
After shutting the system down, you can boot it normally to the run level you want, or to the default multiuser state. See Shutting Down a System.
The Fast Reboot feature of Oracle Solaris is supported on both SPARC and x86 platforms. This feature implements an in-kernel boot loader that loads the kernel into memory and then switches to that kernel, so that the reboot process occurs within seconds.
The feature is configured through the svc:/system/boot-config:default service. Two properties of the service control the reboot behavior:
config/fastreboot_default controls normal system reboots.
config/fastreboot_onpanic controls system reboots that occur as a result of system panics.
The two properties are independent of each other and can have different settings without affecting each other's behavior.
On x86 systems, the service's config/fastreboot_default property is set to true and therefore Fast Reboot is always enabled by default.
On SPARC systems, the feature is disabled. To perform a single instance of a fast reboot on a SPARC system, use the reboot –f command syntax. To enable the feature permanently, change the setting of the config/fastreboot_default property. For example:
$ svccfg -s "system/boot-config:default" setprop config/fastreboot_default=true $ svcadm refresh svc:/system/boot-config:default
For more information, see the svcadm(8) and svccfg(8) man pages.
The system's capability to bypass the firmware when booting a new OS image has dependencies on the device drivers' implementation of a new device operation entry point, quiesce. On supported drivers, this implementation quiesces a device, so that at completion of the function, the driver no longer generates interrupts. This implementation also resets the device to a hardware state, from which the device can be correctly configured by the driver's attach routine, without a power cycle of the system or being configured by the firmware. For more information about this functionality, see the quiesce(9E) and dev_ops(9S) man pages.
Aside from the example in Example 20, Booting From an Alternate Boot Environment With bootadm, several other methods enable you to boot a system to alternative boot environments.
Example 21 Using the beadm CommandIn this example, you activate a selected boot environment. That boot environment is used the next time you reboot, and subsequently becomes the default BE.
$ beadm list
List of boot environments displayed
$ beadm activate be-name
$ reboot
Example 22 x86: Specifying Command Arguments
If you know the BE name, you can reboot directly to the BE by specifying it at the command line.
$ reboot -- 'rpool/zfsbe2'Example 23 x86: Using Combined Options
This example shows how enable a kernel debugger while booting from a specified BE.
$ reboot -- 'rpool/zfsbe3 /platform/i86pc/kernel/amd64/unix -k'Example 24 x86: Rebooting to a New Kernel
This example shows how to reboot the system to a new kernel named my-kernel.
$ reboot -- '/platform/i86pc/my-kernel/amd64/unix -k'Example 25 x86: Debugging While Booting to a Run Level
This example shows how to debug while rebooting a system to a single-user state.
$ reboot -- '-ks'