|
| 以 PDF 格式下載這本書
Booting an x86 System
6
- This chapter describes different boot scenarios and procedures for determining how to boot an x86 system.
- If you are already familiar with boot subsystems and how to use them, use the following table to proceed directly to the task-oriented sections.
-
Overview
- An x86 system has boot subsystems used for booting and controlling the system before the kernel is loaded. During the boot process, boot subsystem menus display different device and booting options. If the system receives no response after several time-out periods, it continues to boot automatically using default selections. You can stop the boot process when the boot subsystem menus are displayed or let it continue automatically.
x86 The PC BIOS
- Before the kernel is started, the system is controlled by the read-only-memory (ROM) Basic Input/Output System (BIOS), the firmware interface on a PC.
- Hardware adapters can have an onboard BIOS that displays the physical characteristics of the device and can be used to access the device.
- During the startup sequence, the PC BIOS checks for the presence of any adapter BIOS and if found, loads and executes each one. Each individual adapter's BIOS runs self-test diagnostics and displays device information.
x86 The x86 Boot Process
-

x86 The x86 Boot Process Details
- The following boot process information describes the illustration on the previous page.
- x86 BIOS Phase
-
- When the system is powered on, the PC BIOS runs self-test diagnostics to verify the system's hardware and memory. The system begins to boot automatically if no errors are found. If errors are found, error messages are displayed describing recovery options.
Additional hardware devices' BIOS are run at this time.
- The BIOS boot program tries to read the first physical sector from the boot device--either a diskette or hard drive. This first disk sector on the boot device contains the master boot record (mboot), which is loaded and executed. If no mboot file is found, an error message is displayed.
- x86 Boot Programs Phase
-
-
mboot, which contains disk information needed to find the active partition and the location of the Solaris boot program, pboot, loads and executes pboot.
-
pboot loads bootblk, the primary boot program, whose purpose is to load the secondary boot program located in the ufs file system.
- If there is more than one bootable partition, bootblk reads the fdisk table to locate the default boot partition, and builds a menu of available partitions that is displayed to the operator. This step only occurs if there is more than one bootable partition present on the system.
-
bootblk finds and executes ufsboot, the primary boot program in the root file system slice.
-
ufsboot starts a command interpreter that executes the /etc/bootrc script, which provides a menu of choices for booting the system. The default action is to load and execute the kernel, /kernel/unix.
- x86 Kernel Initialization Phase
-
- The kernel initializes itself and begins loading modules, using ufsboot to read the files. When the kernel has loaded enough modules to mount the root file system, it unmaps the /ufsboot program and continues, using its own resources.
- The kernel creates a user process and starts the /sbin/init process, which starts other processes by reading the /etc/inittab file.
- x86 init Phase
-
- The /sbin/init process starts the run control (rc) scripts, which execute a series of other scripts. These scripts (sbin/rc*) check and mount file systems, start various processes, and perform system maintenance tasks.
x86 Boot Scenarios
-
Table 6-1 provides different boot scenarios for an x86 system.
-
Table 6-1
| Boot Type | Boot Command | This Type Of Boot Is Needed When... |
| Booting to multiuser state | b | Turning off system power due to anticipated power outage. Changing kernel configuration information by modifying the /etc/system file. |
| Booting to single-user state | b -s | Performing file system maintenance, such as performing a backup or restoring system data. Repairing a system file such as /etc/passwd. |
| Booting interactively | b -a | Repairing a system configuration file such as /etc/system. |
| Booting after adding new hardware | See example on page 62 | Adding hardware to the system. (Also known as a reconfiguration boot.) |
| Booting from a local CD drive | See example on page 50 | Installing a new release of the operating system (this includes upgrading to a new operating system release). Repairing a critical system file which is causing system boot failure. |
| Booting from the network | See example on page 50 | Installing a new release of the operating system from an installation server (including upgrades). Repairing a system file when a local CD-ROM player is not available. |
| Booting kadb | b kadb | Booting the kernel debugger (kadb) to track down a system problem. |
| Forcing a crash dump and rebooting | See example on page 52 | Recovering from a hung system and you want to force a crash dump. |
-
x86 - Booting brings the system to run level 3, multiuser level with resources shared, unless specified otherwise.
x86 Boot Subsystems
- Booting an x86 system uses these subsystems:
-
- Primary boot subsystem
- Secondary boot subsystem
- Additionally, booting from the network or a local CD-ROM drive uses this subsystem:
-
- The following section describes each of these boot subsystems and provides examples of each subsystem screen. Screen displays will vary based on system configurations.
- x86 Solaris Boot Diskette
- This diskette is also known as the multiple device boot (MDB) diskette.

- The Solaris boot diskette provides a menu of bootable devices such as disk, network, or CD-ROM. (The system probes currently connected devices and displays the devices in the MDB menu.)
- x86 Primary Boot Subsystem
- The primary boot subsystem menu displays a list of partitions to boot from if there is more than one bootable partition.

- The default partition is automatically selected if you press Return or do not select an alternate partition from which to boot (after a 30-second time out).
- x86 Secondary Boot Subsystem
- The second boot subsystem menu displays available boot options.

- The system automatically boots to run level 3 if you don't select an option (after a five-second time out) from this menu. The other options enable you to specify boot options or enter the boot interpreter (see boot(1M)).
x86 Booting a System
- The boot procedures provided in this section assume that the system has been shut down using the Solaris 2.x commands and is waiting at the type any key to reboot prompt or has been shut down by pressing the reset button.
- x86 Interrupting Automatic Time Outs
- You can prevent the system from automatically moving to the next boot subsystem menu (using the time out values) by typing a value on the boot subsystem menu without pressing Return.
- To change the automatic time out value for the secondary boot subsystem, edit the set boot_timeout value in the /etc/bootrc file.
-
x86 - The following procedures use the reset button to restart the system. If your system does not have a reset button, use the on/off switch to restart the system. You might be able to press the Control-Alt-Del keys to interrupt system operation depending upon the state of the system.
-
x86 How to Boot to Multiuser State (Run Level 3)
- Booting to multiuser state is usually done after halting the system or performing some system hardware maintenance task. This is the default boot level where all resources are available and users can log into the system.
-
-
Press any key to reboot the system if the system displays the type any key to reboot prompt. Or, use the reset button to restart the system if the system is shut down.
The Primary Boot Subsystem menu is displayed after a few minutes.
-
Select the Active Solaris partition (Part #2 in the example on page 46) as the boot device from the Primary Boot Subsystem menu. Press Return.
If you do not make a selection within 30 seconds, the default boot partition is selected automatically. The Secondary Boot Subsystem menu is displayed.
-
Type b to boot the Solaris 2.x environment to run level 3. Press Return. If you do not make a selection within 5 seconds, the system is automatically booted to run level 3.
-
x86 How to Boot to Single-User State (Run Level S)
- Booting to single-user state is usually done prior to performing a system maintenance task such as backing up the system. At this level only some file systems are mounted and users cannot log into the system.
-
-
Press any key to reboot the system if the system displays the type any key to reboot prompt. Or, use the reset button to restart the system if the system is shutdown.
The Primary Boot Subsystem menu is displayed after a few minutes.
-
Select the Active Solaris partition (Part #2 in the example on page 46) as the boot device from the Primary Boot Subsystem menu. Press Return.
If you do not make a selection within 30 seconds, the default boot partition is selected automatically.
- The Secondary Boot Subsystem menu is displayed.
-
-
Type b -s to boot the Solaris 2.x environment to run level s. Press Return. If you do not make a selection within 5 seconds, the system is automatically booted to run level 3.
-
Type the root password, if prompted.
-
Perform the maintenance task that needed the run level change to s.
-
Press Control-d to bring the system back to run level 3.
-
x86 How to Boot Interactively
- You may want to boot interactively to make a temporary change to the system file or the kernel. Booting interactively lets you test your changes and recover easily if you have any problems.
-
-
Press any key to reboot the system if the system displays the type any key to reboot prompt. Or, use the reset button to restart the system if the system is shutdown.
The Primary Boot Subsystem menu is displayed after a few minutes.
-
Select the Active Solaris partition as the boot device from the Primary Boot Subsystem menu. Press Return.
If you do not make a selection within 30 seconds, the default boot partition is selected automatically. The Secondary Boot Subsystem menu is displayed.
-
Type b -a at the Select (b)oot or (i)nterpreter: prompt. Press Return.
-
Press Return to use the default kernel (/kernel/unix) as prompted, or type the name of the kernel to use for booting and press Return.
-
Press Return to use the default /etc/system file as prompted, or type the name of an alternate system file and press Return.
-
Press Return to use the default modules directory path as prompted, or type alternate path for the modules directory and press Return.
-
-
Press Return to use the default root file system type as prompted: ufs for local disk booting or nfs for diskless clients.
-
Press Return to use the default physical name of the root device as prompted, or type the device name.
- x86 Example: How to Boot Interactively
- In this example, the default choices (shown in square brackets []) are accepted by pressing Return:
-
Select (b)oot or (i)nterpreter: b -a
(Copyright notice)
Enter filename [/kernel/unix]:
Name of system file [/etc/system]:
Name of default directory for modules [/kernel /usr/kernel]:
root filesystem type [ufs]
Enter physical name of root device
[/eisa/dpt@5c88,0/cmdk@0,0:a]:
Configuring network interfaces: smc0
Hostname: venus
(fsck messages)
The system is coming up. Please wait
(More messages)
venus login:
|
-
x86 How to Boot from the Local CD-ROM Drive or the Network
- This procedure is used to recover from an invalid system file that is preventing the system from booting successfully. This situation requires booting from a local CD-ROM drive or the network to recover. Recovering from a invalid /etc/passwd file is used as an example.
- Substitute the device name of the file system to be repaired for the devicename variable identified in the procedures below. Refer to Chapter 5, "Accessing Devices on an x86 System," if you need help identifying your device names.
-
-
Boot from the Solaris 2.x installation CD (or the network) to single-user mode using steps a-f.
If you are booting from the network, skip steps a and b.
a. Insert the Solaris 2.x installation CD into the CD caddy.
-
b. Insert the CD caddy into the CD-ROM drive.
-
c. Insert the Solaris boot diskette into the primary diskette drive (DOS drive A).
-
d. Press any key to reboot the system if the system displays the type any key to reboot prompt. Or, use the reset button to restart the system if the system is shutdown.
- The Multiple Device Boot Subsystem menu is displayed after a few minutes.
-
e. Select the CD-ROM drive or net(work) as the boot device from the Multiple Device Boot menu.
- The Secondary Boot Subsystem menu is displayed.
-
f. Type b -s at the Select the type of installation: prompt.
- After a few minutes, the single-user mode # prompt is displayed.
-
-
Mount the root (/) file system that has the invalid passwd file.
-
# mount /dev/dsk/devicename /a
|
-
-
Change to the newly mounted etc directory.
-
-
-
Set the terminal type.
-
# TERM=AT386
# export TERM
|
-
-
Make the necessary change to the /etc/passwd file using an editor.
-
Change to the root directory.
-
Unmount the /a directory.
-
-
-
Reboot the system.
-
-
x86 How to Abort a Booting Process
- Occasionally, you may need to abort the booting process. The specific abort key sequence depends on your system type. For example, press the reset button to abort the system. If your system doesn't have a reset button, turn the power off and back on again.
-
x86 How to Force a Crash Dump and Reboot the System
- Use the following procedure if your system hangs and you want to force a crash dump. This procedure assumes that you have enabled the savecore feature and you have booted kadb. See Common Administration Tasks for information on the savecore feature.
-
-
Press Control-Alt-d.
The kadb> prompt is displayed.
-
-
-
Type 0:c at the kadb> prompt.
-
-
-
Type :c at the kadb> prompt.
-
- After the crash dump is written to disk, the system will continue to reboot.
x86 Displaying Boot Information
- The dmesg command displays information that is provided during the boot process. The boot information displayed as messages on the system console provide helpful information for troubleshooting system boot problems.
- This information is stored in the /var/adm/messages file.
- An example of dmesg output is displayed below.

|
|