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)
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)
9. Troubleshooting Booting an x86 Based System (Tasks)
Troubleshooting Booting an x86 Based System (Task Map)
Shutting Down and Booting an x86 Based System for Recovery Purposes
Stopping and Booting a System for Recovery Purposes
How to Stop a System for Recovery Purposes
How to Boot in Single-User Mode to Resolve a Bad root Shell or Password Problem
How to Boot From Media to Resolve an Unknown root Password
Forcing a Crash Dump and Reboot of the System
How to Force a Crash Dump and Reboot of the System
How to Boot a System With the Kernel Debugger Enabled (kmdb)
Troubleshooting Issues With Fast Reboot on the x86 Platform
Debugging Early Panics That Might Occur
Troubleshooting Conditions That Might Prevent Fast Reboot From Working on x86 Platforms
In the following instances, you must first shut down a system to analyze or troubleshoot booting and other system problems.
Troubleshoot error messages when the system boots.
Stop the system to attempt recovery.
Boot a system for recovery purposes.
Force a crash dump and reboot of the system.
Boot the system with the kernel debugger by using the kmdb command.
The procedures that follow describe how to safely shut down and then boot an x86 based system for recovery purposes.
You might need to boot the system for recovery purposes.
The following are some of the more common error and recovery scenarios:
Boot a system in single-user mode to resolve a minor problem, such as correcting the root shell entry in the /etc/passwd file or changing a NIS server.
Boot from the installation media or from an install server on the network to recover from a problem that is preventing the system from booting or to recover from a lost root password. This method requires you to mount the boot environment after importing the root pool.
Resolve a boot configuration problem by importing the root pool. If a problem with the menu.lst file exists, you do not have to mount the boot environment, just import the root pool, which automatically mounts the rpool file system that contains the boot-related components.
First, become the root role, then type init 0 if the keyboard and mouse are functional.
If the Press any key to reboot prompt is displayed, press any key to reboot the system.
To reboot the system, type init 6.
# init 0
# reboot
If you cannot use the arrow keys, use the caret (^) key to scroll up and the letter v key to scroll down.
# vi /etc/password
Use the following procedure if you need to boot the system to correct a problem an unknown root password or similar problem. Note that this procedure requires you to mount the boot environment after importing the root pool. If you need to recover a root pool or root pool snapshot, see How to Replace a Disk in a ZFS Root Pool in Oracle Solaris Administration: ZFS File Systems.
For example:
1 Install Oracle Solaris 2 Install Additional Drivers 3 Shell 4 Terminal type (currently xterm) 5 Reboot Please enter a number [1]: 3 To return to the main menu, exit the shell
zpool import -f rpool
# mkdir /a
# beadm mount solaris-instance|bename /a
For example:
# beadm mount solaris-2 /a
# TERM=vt100 # export TERM
# cd /a/etc # vi shadow # cd /
# bootadm update-archive /R /a
# beadm umount be-name
# halt
root@system:~# passwd -r files root New Password: xxxxxx Re-enter new Password: xxxxxx passwd: password successfully changed for root
Use the following procedure if you need to boot the system to correct a problem with the default menu.lst file. Note that this procedure does not require you to mount the boot environment. If you need to recover a root pool or root pool snapshot, see How to Replace a Disk in a ZFS Root Pool in Oracle Solaris Administration: ZFS File Systems.
For example:
1 Install Oracle Solaris 2 Install Additional Drivers 3 Shell 4 Terminal type (currently xterm) 5 Reboot Please enter a number [1]: 3 To return to the main menu, exit the shell
zpool import -f rpool
# cd /rpool/boot/grub # vi menu.lst
# bootadm update-archive -R /a
exit 1 Install Oracle Solaris 2 Install Additional Drivers 3 Shell 4 Terminal type (currently sun-color) 5 Reboot Please enter a number [1]: 5
Forcing a crash dump and reboot of the system are sometimes necessary for troubleshooting purposes. The savecore feature is enabled by default.
For more information about system crash dumps, see Managing System Crash Dump Information in Oracle Solaris Administration: Common Tasks.
If you cannot use the reboot -d or the halt -d command, you can use the kernel debugger, kmdb, to force a crash dump. The kernel debugger must have been loaded, either at boot time or with the mdb -k command for the following procedure to work.
Note - You must be in text mode to access the kernel debugger (kmdb). So, first exit any window system.
The method used to access the debugger is dependent upon the type of console that you are using to access the system.
If you are using a locally attached keyboard, press F1–A.
If you are using a serial console, send a break by using the method appropriate to that type of serial console.
The kmdb prompt is displayed.
[0]> $<systemdump
Panic messages are displayed, the crash dump is saved, and the system reboots.
Example 9-1 x86: Forcing a Crash Dump and Reboot of the System by Using halt -d
This example shows how to force a crash dump and reboot of the x86 based system by using the halt -d and boot commands.
# halt -d 4ay 30 15:35:15 wacked.<domain>.COM halt: halted by user panic[cpu0]/thread=ffffffff83246ec0: forced crash dump initiated at user request fffffe80006bbd60 genunix:kadmin+4c1 () fffffe80006bbec0 genunix:uadmin+93 () fffffe80006bbf10 unix:sys_syscall32+101 () syncing file systems... done dumping to /dev/dsk/c1t0d0s1, offset 107675648, content: kernel NOTICE: adpu320: bus reset 100% done: 38438 pages dumped, compression ratio 4.29, dump succeeded Welcome to kmdb Loaded modules: [ audiosup crypto ufs unix krtld s1394 sppp nca uhci lofs genunix ip usba specfs nfs md random sctp ] [0]> kmdb: Do you really want to reboot? (y/n) y
This procedure shows the basics for loading the kernel debugger (kmdb). The savecore feature is enabled by default.
The GRUB menu is displayed when the system is booted.
If you cannot use the arrow keys, use the caret (^) key to scroll up and the letter v key to scroll down.
The boot entry menu is displayed. In this menu, you can modify boot behavior by adding additional boot arguments to the end of the kernel$ line.
grub edit> kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS -s -k
Typing -kmdb or -k loads the debugger, then directly boots the operating system.
The method used to access the debugger is dependent upon the type of console that you are using to access the system.
If you are using a locally attached keyboard, press F1–A.
If you are using a serial console, send a break by using the method that is appropriate for that type of serial console.
To access the kernel debugger before the system fully boots, use the -kd option.
Using the -kd option loads the debugger and then gives you an opportunity to interact with the debugger before booting the operating system.
A welcome message is displayed when you access the kernel debugger for the first time.
See Also
For more detailed information about interacting with the system by using kmdb and the execution control facilities that are provided by kmdb, see the kmdb(1) man page.