System Startup and Shutdown O BJECTIVES. The following objectives for the Solaris System Administrator Exam are covered in this chapter:

Transcription

1 O BJECTIVES The following objectives for the Solaris System Administrator Exam are covered in this chapter: Explain how to execute boot PROM commands to. Identify the system s boot PROM version. Boot the system; access detailed information. List, change, and restore default NVRAM parameters. Display devices connected to the bus. Identify the system s boot device. Create and remove custom device aliases. View and change NVRAM parameters from the shell. Interrupt a hung system. Given a scenario involving a hung system, troubleshoot problems and deduce resolutions.. Explain how to perform a system boot, control boot processes, and complete a system shutdown, using associated directories, scripts, and commands. You need to understand the primary functions of the OpenBoot environment, which includes the programmable read-only memory (PROM. You need to have a complete understanding of how to use many of the OpenBoot commands and how to set and modify all the configuration parameters that control system bootup and hardware behavior. C H A P T E R 3 You must understand the entire boot process, from the proper power-on sequence to the steps you perform to bring the system into multiuser mode. System Startup and Shutdown

2 O BJECTIVES O UTLINE You must be able to identify the devices connected to a system and recognize the various special files for each device. Occasionally, conventional shutdown methods might not work on an unresponsive system or on a system that has crashed. This chapter introduces when and how to use these alternative shutdown methods to bring the system down safely. You must understand how the system run levels define which processes and services are started at various stages of the boot process. You need to understand all the run levels that are available in Solaris. Introduction 251 Booting a System 251 Powering On the System 252 The Boot PROM and Program Phases 252 The OpenBoot Environment 253 Entry-Level to High-End Systems 254 Accessing the OpenBoot Environment 255 OpenBoot Firmware Tasks 256 The OpenBoot Architecture 257 You need to understand how to add and modify run control scripts to customize the startup of processes and services on Solaris systems. You need to have a detailed understanding of the programs and configuration files involved at the various run levels. The OpenBoot Interface 258 The Restricted Monitor 258 The Forth Monitor 259 Getting Help in OpenBoot 259 PROM Device Tree (Full Device Pathnames) 261 OpenBoot Device Aliases 265 OpenBoot NVRAM 267 The nvedit Line Editor 273

3 O UTLINE OpenBoot Security 275 OpenBoot Diagnostics 277 Input and Output Control 280 OpenBoot PROM Versions 282 Booting a System 282 The boot Command 284 The Kernel 292 System Run States 296 swapper 298 The init Phase 299 rc Scripts 300 Using the Run Control Scripts to Stop or Start Services 304 Adding Scripts to the Run Control Directories 304 System Shutdown 306 Commands to Shut Down the System 306 The /usr/sbin/shutdown Command 307 The /sbin/init Command 308 The /usr/sbin/halt Command 309 The /usr/sbin/reboot Command 309 The /usr/sbin/poweroff Command 310 Stopping the System for Recovery Purposes 310 Turning Off the Power to the Hardware 312 Summary 313 Apply Your Knowledge 314

4 S TUDY S TRATEGIES The following study strategies will help you prepare for the exam:. When studying this chapter, you should practice on a Sun system each step-by-step process that is outlined. In addition to practicing the processes, you should practice the various options described for booting the system.. You should display the hardware configuration of your Sun system by using the various OpenBoot commands presented in this chapter. You need to familiarize yourself with all the devices associated with your system. You should be able to identify each hardware component by its device pathname.. You should practice creating both temporary and permanent device aliases. In addition, you should practice setting the various OpenBoot system parameters that are described in this chapter.. You should practice booting the system by using the various methods described. You need to understand how to boot into single-user and multiuser modes and how to specify an alternate kernel or system file during the boot process.. During the boot process, you should watch the system messages and familiarize yourself with every stage of the boot process. You should watch the system messages that are displayed at bootup. You need to understand each message displayed during the boot process from system power-on to bringing the system into multiuser mode.. You need to thoroughly understand all the system run states, including when and where to use each of them. In addition, you must understand run control scripts and how they affect the system services. You should practice adding your own run control scripts.. You should practice shutting down the system. You should make sure you understand the advantages and disadvantages of each method presented.

5 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 251 INTRODUCTION System startup requires an understanding of the hardware and the operating system functions that are required to bring the system to a running state. This chapter discusses the operations that the system must perform from the time you power on the system until you receive a system logon prompt. In addition, it covers the steps required to properly shut down a system. After reading this chapter, you ll understand how to boot the system from the OpenBoot programmable read-only memory (PROM) and what operations must take place to start up the kernel and Unix system processes. BOOTING A SYSTEM Bootstrapping is the process a computer follows to load and execute the bootable operating system. The term comes from the phrase pulling yourself up by your bootstraps. The instructions for the bootstrap procedure are stored in the boot PROM. The boot process goes through the following phases: 1. Boot PROM phase After you turn on power to the system, the PROM displays system identification information and runs self-test diagnostics to verify the system s hardware and memory. It then loads the primary boot program, called bootblk, from its location on the boot device into memory. 2. Boot programs phase The bootblk program finds and executes the secondary boot program (called ufsboot) from the Unix file system (UFS)and loads it into memory. After the ufsboot program is loaded, the ufsboot program loads the two-part kernel. 3. 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.

6 252 Part I EXAM PREPARATION TIP EXAM Boot Phases For the exam, you need to make sure you thoroughly understand each boot phase and the order in which each phase is run. The first two phases are described in this section, with the description of OpenBoot. The kernel and init phases are described later in the chapter, in the sections The Kernel and System Run States. 4. init phase The kernel starts the Unix operating system, mounts the necessary file systems, and runs /sbin/init to bring the system to the initdefault state specified in /etc/inittab. The kernel creates a user process and starts the /sbin/init process, which starts other processes by reading the /etc/inittab file. 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. W ARNING Connecting Cables with the Power Turned Off Always connect your cables before turning on the hardware; otherwise, you could damage your system. Powering On the System Before you power on the system, you need to make sure everything is plugged in properly. Check the small computer system interface (SCSI) cables that connect any external devices to the system (such as disk drives and tape drives) to make sure they are properly connected. Check your network connection. Also make sure that the keyboard and monitor are connected properly. Loose cables can cause your system to fail during the startup process. The correct sequence for powering on your equipment is to first turn on any peripherals (that is, external disk drives or tape drives) and then turn on power to the system. The Boot PROM and Program Phases The bootstrap process begins after power-up, when the startup routines located in the hardware s PROM chip are executed. Sun calls this the OpenBoot firmware, and it is executed immediately after you turn on the system. The primary task of the OpenBoot firmware is to boot the operating system either from a mass storage device or from the network. OpenBoot contains a program called the monitor that controls the operation of the system before the kernel is available. When a system is turned on, the monitor runs a power-on self-test (POST) that checks such things as the hardware and memory on the system.

7 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 253 If no errors are found, the automatic boot process begins. OpenBoot contains a set of instructions that locate and start up the system s boot program and eventually start up the Unix operating system. The boot program is stored in a predictable area (sectors 1 15) on the system hard drive, CD-ROM, or other bootable device and is referred to as the bootblock (bootblk). The bootblock is responsible for loading the secondary boot program (ufsboot) into memory, which is located in the UFS on the boot device. The path to ufsboot is recorded in the bootblock, which is installed by the Solaris installboot utility. ufsboot locates and loads the two-part kernel. The kernel (which is covered in detail later in this chapter) is the part of the operating system that remains running at all times until the system is shut down. It is the core and the most important part of the operating system. The kernel consists of a two-piece static core called genunix and unix. genunix is the platform-independent generic kernel file, and unix is the platform-specific kernel file. When the system boots, ufsboot combines these two files into memory to form the running kernel. NOTE Automatic System Recovery Sun Enterprise class servers can recognize failed components and disable the board that contains the failed component. If the server is configured with multiple central processing unit (CPU)/memory and input/output (I/O) boards, the system can boot in a degraded yet stable condition, even with failed components. See your server s System Reference Manual for details on automatic system recovery. THE OPENBOOT ENVIRONMENT Identify the system s boot PROM version. The hardware-level user interface that you see before the operating system starts is called the OpenBoot PROM (OBP). OpenBoot is based on an interactive command interpreter that gives you access to an extensive set of functions for hardware and software development, fault isolation, and debugging. The OBP firmware is stored in the socketed startup PROM. The OpenBoot PROM consists of two 8KB chips on the system board: the startup PROM itself, which contains extensive firmware that allows access to user-written startup drivers and extended diagnostics, and a nonvolatile random-access memory (NVRAM) chip. The NVRAM chip has user-definable system parameters and writable areas for user-controlled diagnostics, macros, and device aliases. NVRAM is where the system identification information is stored, such as the host ID, Ethernet address, and time-of-day (TOD) clock. A single lithium battery backup provides backup for

8 254 Part I EXAM PREPARATION NOTE No OpenBoot Environment on the Intel Platform The Intel environment has no OpenBoot PROM or NVRAM. On Intel systems, before the kernel is started, the system is controlled by the ROM basic input/output system (BIOS), the firmware interface on a PC. the NVRAM and clock. Many software packages use the host ID for licensing purposes; therefore, it is important that the NVRAM chip can be removed and placed into any replacement system board. Because NVRAM contains unique identification information for the machine, Sun sometimes refers to it as the identification programmable read-only memory (ID PROM). OpenBoot is currently at version 5. Depending on the age of your system, you could have PROM version 1, 2, 3, 4, or 5 installed. The original boot PROM firmware, version 1, was first introduced on the Sun SPARCstation 1. The first version of the OpenBoot PROM was version 2, and it first appeared on the SPARCstation 2 system. OpenBoot versions 3 and 4 are the versions that are currently available on the Ultra series systems. Version 5 is available on the Sun Enterprise 3500, 4500, 5500, and 6500 servers. Versions 3, 4 and 5 of the OpenBoot architecture provide a significant increase in functionality over the boot PROMs in earlier Sun systems. One notable feature of the OpenBoot firmware is a programmable user interface based on the interactive programming language Forth. In Forth, sequences of user commands can be combined to form complete programs. This capability provides a powerful tool for debugging hardware and software. Another benefit of versions 3, 4, and 5 is the Flash update feature. You can update the version 3, 4, and 5 firmware without replacing the PROM chip, but you will not be tested on updating the firmware on the exam. Entry-Level to High-End Systems Every Sun workstation and server except the midrange, midframe, and high-end servers has only one system board and holds only one boot PROM and NVRAM chip. The following are examples of systems that are capable of using only one system board:. SPARCstation 4, 5, 10, and 20. Sun Blade 100 and Ultra 1, 2, 5, 10, 30, 60, 80, 220, 250, 240, 420, and 450. Netra X1, T1, T1400, and T1405. Sun Fire V120, V480, and V880

9 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 255 Sun s midrange, midframe, and high-end servers can be configured with multiple CPU/memory and I/O boards. The following are examples of these systems:. Midrange Enterprise 3000, 3500, 4000, 4500, 5000, 5500, 6000, and Midframe Sun Fire 3800, 4800, 4810, and High-end Enterprise 10000, Sun Fire 12000, and Sun Fire All other systems can be configured with multiple system boards and have special boot PROM and NVRAM arrangements. The following are some things you should be aware of on multiple-cpu systems:. A multiple-cpu system has a clock board to oversee the backplane communications.. The host ID and Ethernet address are on the clock board and are automatically downloaded to the NVRAM on all CPU boards when the POST is complete.. PROM contents on each CPU are compared and verified via checksums.. The CPU that is located in the lowermost card cage slot is the master CPU board.. Each CPU runs its own individual POST.. If these systems are configured with redundant CPU/memory and I/O boards, they can run in a degraded yet stable mode, even when some components have failed. Accessing the OpenBoot Environment You can get to the OpenBoot environment by using any of the following methods:. Halting the operating system.. Pressing the Stop and A keys simultaneously (Stop+A). On terminals that are connected to the serial port and do not have a Stop key, you press the Break key.

10 256 Part I EXAM PREPARATION NOTE W ARNING Alternate Methods for Stopping a System An alternate sequence that can be used to stop the system is Enter+~+Ctrl+B, which is equivalent to Stop+A. There must be an interval of more than 0.5 seconds between characters, and the entire string must be entered in less than 5 seconds. You can use this method only with serial devices acting as consoles and not for systems with keyboards of their own. To enable this alternate sequence, you must first modify the /etc/default/kbd file by removing the # from the entry: #KEYBOARD_ABORT=alternate Then you save the changes and, as root, type: kbd -i to put the changes into effect. On a server with a physical keyswitch, the alternative BREAK does not work when the key is set to the Secure position. If your console is connected to the serial port via a modem, you can send a break (Stop+A or L1+A) through the tip window by typing ~# (tilde and then the pound sign). Using Stop+A Sparingly Forcing a system into the OpenBoot PROM by using Stop+A or Break abruptly breaks execution of the operating system. You should use these methods only as a last resort to restart the system.. When the system is initially powered on. If your system is not configured to start up automatically, it stops at the user interface. If automatic startup is configured, you can make the system stop at the user interface by pressing Stop+A after the display console banner is displayed but before the system begins starting the operating system.. When the system hardware detects an error from which it cannot recover. (This is known as a watchdog reset.) OpenBoot Firmware Tasks The primary tasks of the OpenBoot firmware are as follows:. Test and initialize the system hardware.. Determine the hardware configuration.. Start the operating system from either a mass storage device or a network.. Provide interactive debugging facilities for testing hardware and software.. Allow modification and management of system startup configuration, such as NVRAM parameters. Specifically, the following tasks are necessary to initialize the operating system kernel: 1. OpenBoot displays system identification information and then runs self-test diagnostics to verify the system s hardware and memory. These checks are known as a POST. 2. OpenBoot loads the primary startup program, bootblk, from the default startup device. 3. The bootblk program finds and executes the secondary startup program, ufsboot, and loads it into memory. The ufsboot program loads the operating system kernel.

11 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 257 THE OPENBOOT ARCHITECTURE Display devices connected to the bus. The OpenBoot architecture provides an increase in functionality and portability compared to the proprietary systems of some other hardware vendors. Although this architecture was first implemented by Sun Microsystems as OpenBoot on SPARC (Scaleable Processor Architecture) systems, its design is processor independent. The following are some notable features of OpenBoot firmware:. Plug-in device drivers A device driver can be loaded from a plug-in device such as an SBus card. The plug-in device driver can be used to boot the operating system from that device or to display text on the device before the operating system has activated its own software device drivers. This feature lets the input and output devices evolve without changing the system PROM.. The FCode interpreter Plug-in drivers are written in a machine-independent interpreted language called FCode. Each OpenBoot system PROM contains an FCode interpreter. This enables the same device and driver to be used on machines with different CPU instruction sets.. The device tree Devices called nodes are attached to a host computer through a hierarchy of interconnected buses on the device tree. A node representing the host computer s main physical address bus forms the tree s root node. Both the user and the operating system can determine the system s hardware configuration by viewing the device tree. Nodes with children usually represent buses and their associated controllers, if any. Each such node defines a physical address space that distinguishes the devices connected to the node from one another. Each child of that node is assigned a physical address in the parent s address space. The physical address generally represents a physical characteristic that is unique to the device (such as the bus address or the slot number where the device is installed). The use of physical addresses to identify devices prevents device addresses from changing when other devices are installed or removed. TIP EXAM The OpenBoot Device Tree In this section, pay close attention to the OpenBoot device tree. You re likely to see this topic on the exam.

12 258 Part I EXAM PREPARATION NOTE Forth If you re interested in more information on Forth, refer to American National Standards Institute (ANSI) Standard X (see The programmable user interface The OpenBoot user interface is based on the programming language Forth, which provides an interactive programming environment. Forth is used for direct communication between humans and machines. It can be quickly expanded and adapted to special needs and different hardware systems. Forth is used not only by Sun but also by other hardware vendors such as Hewlett- Packard. THE OPENBOOT INTERFACE The OpenBoot firmware provides a command-line interface for the user at the system console. On older Sun systems such as SPARCstation 10 and SPARCstation 20, this command-line interface had two modes: the Restricted Monitor and the Forth Monitor. The Restricted Monitor The Restricted Monitor provides simple sets of commands to initiate booting of the system, resume system execution, and enter the Forth Monitor. The Restricted Monitor is also used to implement system security. The Restricted Monitor prompt is > (the greater than symbol). When you enter the Restricted Monitor, the following code displays, showing the commands you can enter: Type b (boot), c (continue), or n (new command mode) > The Restricted Monitor commands are listed in Table 3.1. TABLE 3.1 R ESTRICTED M ONITOR C OMMANDS Command Description b Boots the operating system c Resumes the execution of a halted program n Enters the Forth Monitor

13 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 259 The Forth Monitor The Forth Monitor, the default mode in OpenBoot, is an interactive command interpreter that gives you access to an extensive set of functions for hardware and software diagnosis. You ll also see the Forth Monitor referred to as new command mode. These functions are available to anyone who has access to the system console. The Forth Monitor prompt is ok. When you enter the Forth Monitor mode, the following line displays: Type help for more information ok On older Sun SPARCstations, if you want to leave the Forth Monitor mode and get into the Restricted Monitor mode, you type the following: ok old-mode NOTE Switching from the > Prompt to the ok Prompt When the system is halted, the PROM monitor prompt displays. The type of prompt depends on your system type. Older Sun systems use > as the PROM prompt. Current Sun systems use ok as the PROM prompt but support the > prompt. To switch from the > prompt to the ok prompt on newer Sun systems, you type n at the > prompt. GETTING HELP IN OPENBOOT At any time, you can obtain help on the various Forth commands supported in OpenBoot by using the help command. The help commands from the ok prompt are listed in Table 3.2. TABLE 3.2 O PENBOOT HELP Command help help <category> help <command> C OMMANDS Description Displays instructions for using the help system and lists the available help categories. Shows help for all commands in the category. You use only the first word of the category description. Shows help for an individual command. Because of the large number of commands, help is available only for commands that are used frequently.

14 260 Part I EXAM PREPARATION The following example shows the help command with no arguments: ok help The system responds with the following: Enter help command-name or help category-name for more help (Use ONLY the first word of a category description) Examples: help select -or- help line Main categories are: Repeated loops Defining new commands Numeric output Radix (number base conversions) Arithmetic Memory access Line editor System and boot configuration parameters Select I/O devices Floppy eject Power on reset Diag (diagnostic routines) Resume execution File download and boot nvramrc (making new commands permanent) ok If you want to see the help messages for all commands in the category diag, for example, you type the following: ok help diag The system responds with this: test <device-specifier> Run selftest method for specified device Examples: test floppy - test floppy disk drive test net - test net test scsi - test scsi test-all Execute test for all devices with selftest method watch-clock Show ticks of real-time clock watch-net Monitor network broadcast packets watch-net-all Monitor broadcast packets on all net interfaces probe-scsi Show attached SCSI devices probe-scsi-all Show attached SCSI devices for all host adapters ok If you want help for a specific command, you type the following: ok help test The system responds with the following: test <device-specifier> Run selftest method for specified device Examples: test floppy - test floppy disk drive

15 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 261 test net - test net test scsi - test scsi test-all Execute test for all devices with selftest method watch-clock Show ticks of real-time clock watch-net Monitor network broadcast packets watch-net-all Monitor broadcast packets on all net interfaces probe-scsi Show attached SCSI devices probe-scsi-all Show attached SCSI devices for all host adapters ok PROM DEVICE TREE (FULL DEVICE PATHNAMES) Display devices connected to the bus. Identify the system s boot device. OpenBoot deals directly with the hardware devices in the system. Each device has a unique name that represents both the type of device and the location of that device in the device tree. The OpenBoot firmware builds a device tree for all devices from information gathered at the POST. Sun uses the device tree to organize devices that are attached to the system. The device tree is loaded into memory, to be used by the kernel during boot to identify all configured devices. The paths built in the device tree by OpenBoot vary, depending on the type of system and its device configuration. The following example shows a full device pathname for an older Sun system with SBus architecture, such as a SPARCstation 20: /sbus@1f,0/esp@0,40000/sd@3,0:a The following example shows the device tree for an internal disk on a peripheral component interconnect (PCI) bus system such as an Ultra 5: /pci@1f,0/pci@1,1/ide@3/disk Typically, the OBP uses disk and cdrom for the boot disk and CD- ROM drive. The following example shows the disk device on an Ultra system with a PCI-SCSI bus: /pci@1f,0/pci@1/isptwo@4/sd@3,0 NOTE The Device Tree Versus Device Pathname The terms device tree and device pathname are often interchanged, and you ll see both used. They both mean the same thing.

16 262 Part I EXAM PREPARATION A device tree is a series of node names separated by slashes (/).The top of the device tree is the root device node. Following the root device node, and separated by a leading slash /, is a bus nexus node. Connected to a bus nexus node is a leaf node, which is typically a controller for the attached device. Each device pathname has this form: driver-name@unit-address:device-arguments The components of the device pathname are described in Table 3.3. TABLE 3.3 D EVICE PATHNAME PARAMETERS Parameter driver-name Description This is the root device node, which is a human-readable string that consists of 1 to 31 letters, digits, and the following punctuation characters:, (comma). (period) _ (underscore) + (plus sign) - (minus sign) Uppercase and lowercase characters are distinct from one another. In some cases, the driver name includes the name of the device s manufacturer and the device s model name, separated by a comma. Typically, the manufacturer s uppercase, publicly listed stock symbol is used as the manufacturer s name (for example, SUNW,hme0). For built-in devices, the manufacturer s name is usually omitted (for example, sbus or must precede the address parameter; it serves as a separator between the driver name and unit address.

17 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 263 Parameter unit-address device-arguments Description A text string that represents the physical address of the device in its parent s address space. The exact meaning of a particular address depends on the bus to which the device is attached. In this example, /sbus@3,0/sunw,fas@3,0/sd@0,0 sbus@3,0 represents the I/O board in slot 1, located on the back of the system, and SUNW,fas@3,0 is the onboard fast/wide SCSI controller of the same board. The following are common device driver names: fas Fast/wide SCSI controller. hme Fast (10/100Mbps) Ethernet. isp Differential SCSI controllers and the SunSwift card. glm UltraSCSI controllers. scsi SCSI devices. sf SCSI-compliant nexus driver that supports the Fibre Channel Protocol for SCSI on Private Fibre Channel Arbitrated Loops (FC-ALs). soc Serial optical controller (SOC) device driver. socal The Fibre Channel host bus adapter, which is an SBus card that implements two full-duplex Fibre Channel interfaces. Each Fibre Channel interface can connect to an FC-AL. sd@0,0 is the SCSI disk (sd) set to target id 0. (In this case, it is an internal disk because only internal disks should be controlled by the onboard SCSI controller of the I/O board in slot 1.) A text string whose format depends on the particular device. device-arguments can be used to pass additional information to the device s software. In this example: /pci@1f,0/pci@1,1/ide@3/atapicd@2,0:f the argument for the disk device is f. The software driver for this device interprets its argument as a disk partition, so the device pathname refers to partition f on a CD- ROM. You use the OpenBoot command show-devs to obtain information about the device tree and to display device pathnames. This command displays all the devices known to the system directly beneath a given device in the device hierarchy. show-devs used by itself shows the entire device tree. The syntax is as follows: ok show-devs

18 264 Part I EXAM PREPARATION The system outputs the entire device tree, as follows: /SUNW,UltraSPARC-IIi@0,0 /pci@1f,0 /virtual-memory /memory@0, /aliases /options /openprom /chosen /packages /pci@1f,0/pci@1 /pci@1f,0/pci@1,1 /pci@1f,0/pci@1/pci@1 /pci@1f,0/pci@1/pci@1/sunw,qfe@3,1 /pci@1f,0/pci@1/pci@1/pci108e,1000@3 /pci@1f,0/pci@1/pci@1/sunw,qfe@2,1 /pci@1f,0/pci@1/pci@1/pci108e,1000@2 /pci@1f,0/pci@1/pci@1/sunw,qfe@1,1 /pci@1f,0/pci@1/pci@1/pci108e,1000@1 /pci@1f,0/pci@1/pci@1/sunw,qfe@0,1 /pci@1f,0/pci@1/pci@1/pci108e,1000@0 /pci@1f,0/pci@1,1/ide@3 /pci@1f,0/pci@1,1/sunw,m64b@2 Commands that are used to examine the device tree are listed in Table 3.4. TABLE 3.4 C OMMANDS FOR B ROWSING THE D EVICE T REE Command.properties dev <device-path> dev <node-name> dev.. dev / device-end Description Displays the names and values of the current node s properties. Chooses the specified device node and makes it the current node. Searches for a node with the specified name in the subtree below the current node and chooses the first such node found. Chooses the device node that is the parent of the current node. Chooses the root machine node. Leaves the device tree.

19 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 265 Command <device-path> find-device ls pwd see <wordname> show-devs <device-path> words <device-path> select-dev Description Chooses the specified device node, similar to dev. Displays the names of the current node s children. Displays the device pathname that names the current node. Decompiles the specified word. Displays all the devices known to the system directly beneath a given device in the device hierarchy. show-devs used by itself shows the entire device tree. Displays the names of the current node s methods. Selects the specified device and makes it the active node. You can examine the device path from a Unix shell prompt by typing the following: prtconf vp OpenBoot Device Aliases Create and remove custom device aliases. Device pathnames can be long and complex. Device aliases, like Unix aliases, allow you to substitute a short name for a long name. An alias represents an entire device pathname, not a component of it. For example, the alias disk0 might represent the following device pathname: /sbus@1,f /esp@0,40000/sd@3,0:a OpenBoot provides the predefined device aliases listed in Table 3.5 for commonly used devices, so you rarely need to type a full device pathname. Be aware, however, that device aliases and pathnames can vary on each platform. The device aliases shown in Table 3.5 are from a Sun Ultra 5 system.

20 266 Part I EXAM PREPARATION TABLE 3.5 P REDEFINED D EVICE A LIASES Alias Device Pathname disk disk0 disk1 disk2 disk3 cdrom /pci@1f,0/pci@1,1/ide@3/disk@0,0 /pci@1f,0/pci@1,1/ide@3/disk@0,0 /pci@1f,0/pci@1,1/ide@3/disk@1,0 /pci@1f,0/pci@1,1/ide@3/disk@2,0 /pci@1f,0/pci@1,1/ide@3/disk@3,0 /pci@1f,0/pci@1,1/ide@3/cdrom@2,0:f If you add disk drives or change the target of the startup drive, you might need to modify these device aliases. Table 3.6 describes the devalias commands, which are used to examine, create, and change OpenBoot aliases. NOTE New Names Overwrite Old Names If an alias with the same name already exists, the new value overwrites the old. TABLE 3.6 T HE DEVALIAS C OMMANDS Command Description devalias Displays all current device aliases devalias <alias> Displays the device pathname that corresponds to alias devalias_alias Defines an alias that represents device-path <device-path> The following example creates a device alias named disk3, which represents an Integrated Drive Electronics (IDE) disk with a target ID of 3 on an Ultra 5 system: devalias disk3 /pci@1f,0/pci@1,1/ide@3/disk@3,0 To confirm the alias, you type devalias, as follows: ok devalias The system responds by printing all the aliases, like this: screen net /pci@1f,0/pci@1,1/sunw,m64b@2 /pci@1f,0/pci@1,1/network@1,1

21 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 267 cdrom disk disk3 disk2 disk1 disk0 ide floppy ttyb ttya keyboard! keyboard mouse name /pci@1f,0/pci@1,1/ide@3/cdrom@2,0:f /pci@1f,0/pci@1,1/ide@3/disk@0,0 /pci@1f,0/pci@1,1/ide@3/disk@3,0 /pci@1f,0/pci@1,1/ide@3/disk@2,0 /pci@1f,0/pci@1,1/ide@3/disk@1,0 /pci@1f,0/pci@1,1/ide@3/disk@0,0 /pci@1f,0/pci@1,1/ide@3 /pci@1f,0/pci@1,1/ebus@1/fdthree /pci@1f,0/pci@1,1/ebus@1/se:b /pci@1f,0/pci@1,1/ebus@1/se:a /pci@1f,0/pci@1,1/ebus@1/su@14,3083f8:forcemode /pci@1f,0/pci@1,1/ebus@1/su@14,3083f8 /pci@1f,0/pci@1,1/ebus@1/su@14,3062f8 aliases You can also view device aliases from a shell prompt by using the prtconf vp command. User-defined aliases are lost after a system reset or power cycle unless you create a permanent alias. If you want to create permanent aliases, you can either manually store the devalias command in a portion of NVRAM called NVRAMRC or you can use the nvalias and nvunalias commands. The following section describes how to configure permanent settings in the NVRAM on a Sun system. OPENBOOT NVRAM List, change, and restore default NVRAM parameters. View and change NVRAM parameters from the shell. System configuration variables are stored in system NVRAM. These OpenBoot variables determine the startup machine configuration and related communication characteristics. If you modify the values of the configuration variables, any changes you make remain in

22 268 Part I EXAM PREPARATION effect even after a power cycle. Configuration variables should be adjusted cautiously, however, because incorrect settings can prevent a system from booting. Table 3.7 describes OpenBoot s NVRAM configuration variables, their default values, and their functions. TABLE 3.7 NVRAM VARIABLES Variable Default Description auto-boot? true The system starts up automatically after power-on or reset if auto-boot? is true. If it is set to false, the system stops at the OpenBoot prompt (ok) after power-on or reset. boot-command boot The command that is executed if auto-boot? is true. boot-device disk or net The device from which to start up. boot-file Empty string Arguments passed to the started program. diag-device net The diagnostic startup source device. diag-file Empty string Arguments passed to the startup program in diagnostic mode. diag-switch? false Whether to run in diagnostic mode. fcode-debug? false Whether name fields are included for plug-in device FCodes. input-device keyboard A console input device (usually keyboard, ttya, or ttyb). nvramrc Empty The contents of NVRAMRC. oem-banner Empty string A custom original equipment manufacturer (OEM) banner (enabled with oem-banner? true). oem-banner? false If true, use custom OEM banner. oem-logo No default A byte array custom OEM logo (enabled with oem-logo? true). Displayed in hexadecimal.

23 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 269 Variable Default Description oem-logo? false If true, use custom OEM logo; otherwise, use the Sun logo. output-device screen A console output device (usually screen, ttya, or ttyb). sbus-probe-list 0123 Which SBus slots to probe and in what order. screen-#columns 80 The number of onscreen columns (characters/line). screen-#rows 34 The number of onscreen rows (lines). security-#badlogins No default The number of incorrect security password attempts. security-mode none The firmware security level (options: none, command, or full). security-password No default The firmware security password (which is never displayed). use-nvramrc? false If true, execute commands in NVRAMRC during system startup. NOTE OpenBoot Versions Because older SPARC systems use older versions of OpenBoot, they might use different defaults or different configuration variables from those shown in Table 3.7. This text describes OpenBoot version 4. You can view and change the NVRAM configuration variables by using the commands listed in Table 3.8. TABLE 3.8 C OMMANDS FOR V IEWING AND M ODIFYING C ONFIGURATION VARIABLES Command password printenv Description Sets the security password. Displays the current value and the default value for each variable. To show the current value of a named variable, you type the following: printenv <parameter-name> setenv <variable> <value> Sets <variable> to the given decimal or text <value>. Changes are permanent, but they often take effect only after a reset. continues

24 270 Part I EXAM PREPARATION TABLE 3.8 continued C OMMANDS FOR V IEWING AND M ODIFYING C ONFIGURATION VARIABLES Command set-default <variable> Description Resets the value of <variable> to the factory default. set-defaults Resets variable values to the factory defaults. The following examples illustrate the use of the commands described in Table 3.8. All commands are entered at the ok OpenBoot prompt. You use the printenv command, with no argument, to display the current value and the default value for each variable: ok printenv The system responds with this: Variable Name Value Default Value tpe-link-test? true true scsi-initiator-id 7 7 keyboard-click? false false keymap ttyb-rts-dtr-off false false ttyb-ignore-cd true true ttya-rts-dtr-off false false ttya-ignore-cd true true ttyb-mode 9600,8,n,1,- 9600,8,n,1,- ttya-mode 9600,8,n,1,- 9600,8,n,1,- pcia-probe-list 1,2,3,4 1,2,3,4 pcib-probe-list 1,2,3 1,2,3 mfg-mode off off diag-level max max #power-cycles 89 system-board-serial# system-board-date fcode-debug? false false output-device screen screen input-device keyboard keyboard load-base boot-command boot boot auto-boot? false true watchdog-reboot? false false diag-file diag-device net net boot-file boot-device disk:a disk net disk net local-mac-address? false false ansi-terminal? true true screen-#columns 80 80

25 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 271 screen-#rows silent-mode? false false use-nvramrc? false false nvramrc security-mode none security-password security-#badlogins 0 oem-logo oem-logo? false false oem-banner oem-banner? false false hardware-revision last-hardware-update diag-switch? false false To set the auto-boot? variable to false, you type the following: ok setenv auto-boot? false The system responds with this: NOTE The printenv Command Depending on the version of OpenBoot that you have on your system, the printenv command might show slightly different results. This example uses a system running OpenBoot version auto-boot? = false You can verify the setting by typing the following: ok printenv auto-boot? The system responds with this: auto-boot? = true To reset the variable to its default setting, you type the following: ok set-default auto-boot? The system does not respond with a message only another OpenBoot prompt. You can verify the setting by typing the following: ok printenv auto-boot? The system responds with this: auto-boot? = true To reset all variables to their default settings, you type the following: ok set-defaults The system responds with this: Setting NVRAM parameters to default values. It s possible to set variables from the Unix command line by issuing the eeprom command. You must be logged in as root to issue this command, and although anyone can view a parameter, only root can

26 272 Part I EXAM PREPARATION W ARNING NOTE Setting the OpenBoot Security Mode Setting the security mode and password can be dangerous: If you forget the password, the system is unable to boot. It is nearly impossible to break in without sending the CPU to Sun to have the PROM reset. OpenBoot security is discussed more in the section OpenBoot Security, later in this chapter. Resetting NVRAM Variables If you change an NVRAM setting on a SPARC system and the system no longer starts up, you can reset the NVRAM variables to their default settings by holding down Stop+N while the machine is powering up. When you issue the Stop+N key sequence, you hold down Stop+N immediately after turning on the power to the SPARC system; you then keep these keys pressed for a few seconds or until you see the banner (if the display is available). These are both good techniques for forcing a system s NVRAM variables to a known condition. change the value of a parameter. For example, to set the auto-boot? variable to true, you type the following at the Unix prompt: eeprom auto-boot\?=true Any nonroot user can view the OpenBoot configuration variables from a Unix prompt by typing the following: /usr/sbin/eeprom For example, to change the OpenBoot parameter security-password from the command line, you must be logged in as root and issue the following command: example# eeprom security-password= Changing PROM password: New password: Retype new password: The security mode password you assign must be between zero and eight characters. Any characters after the eighth are ignored. You do not have to reset the system after you set a password; the security feature takes effect as soon as you type the command. With no parameters, the eeprom command displays all the OpenBoot configuration settings, similar to the OpenBoot printenv command. To view OpenBoot parameters from the shell prompt, you type prtconf vp. You can use the NVRAM commands listed in Table 3.9 to modify device aliases so that they remain permanent, even after a restart. TABLE 3.9 NVRAM COMMANDS Command nvalias <alias> <device-path> nvunalias <alias> Description Stores the command devalias <alias> <device-path> in NVRAMRC. (The alias persists until the nvunalias or set-defaults command is executed.) This command turns on use-nvramrc?. Deletes the corresponding alias from NVRAMRC.

27 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 273 For example, to permanently create a device alias named disk3 that represents a SCSI disk with a target ID of 3 on a SPARCstation 10 system, you type the following: nvalias disk3 /pci@1f,0/pci@1,1/ide@3/disk@3,0 The nvedit Line Editor On systems with a PROM version of 1.x or 2.x, the nvalias command might not be available. On these systems, you need to use nvedit to create custom device aliases. nvedit is a line editor that edits the NVRAMRC directly, has a set of editing commands, and operates in a temporary buffer. The following is a sample nvedit session: ok setenv use-nvramrc? true The system responds with the following: TIP EXAM Learning nvedit This section is included for information purposes, to show an additional method for modifying the NVRAM. The nvedit line editor will not be on the certification exam. use-nvramrc? = ok nvedit true 0: devalias disk0 /pci@1f,0/pci@1,1/ide@3/disk@0,0\ 1: <Control-C> ok nvstore ok reset Resetting ok boot disk0 The preceding example uses nvedit to create a permanent device alias named disk0. The example uses Ctrl+C to exit the editor. It also uses the nvstore command to make the change permanent in the NVRAMRC. Then, it issues the reset command to reset the system and then boots the system from disk0 by using the boot disk0 command. Table 3.10 lists some of the basic commands you can use while in the nvedit line editor. TABLE 3.10 NVEDIT C OMMANDS Command Meaning Ctrl+A Moves backward to beginning of the line. Ctrl+B Moves backward one character. continues

28 274 Part I EXAM PREPARATION TABLE 3.10 continued NVEDIT Command Esc+B Ctrl+C Ctrl+D Esc+D Ctrl+E Ctrl+F Esc+F Ctrl+H Esc+H Ctrl+K Ctrl+L Ctrl+N Ctrl+O Ctrl+P Ctrl+Q Ctrl+R Ctrl+U Ctrl+W Ctrl+Y Return (Enter) C OMMANDS Meaning Moves backward one word. Exits the script editor, returning to the OpenBoot command interpreter. The temporary buffer is preserved but is not written back to the script. You use nvstore afterward to write it back. Erases the next character. Erases from the cursor to the end of the word, storing the erased characters in a save buffer. Moves forward to the end of the line. Moves forward one character. Moves forward one word. Erases the previous character. Erases from the beginning of the word to just before the cursor, storing erased characters in a save buffer. Erases from the cursor position to the end of the line, storing the erased characters in a save buffer. If at the end of a line, it joins the next line to the current line (that is, deletes the new line). Displays the entire contents of the editing buffer. Moves to the next line of the script-editing buffer. Inserts a new line at the cursor position and stays on the current line. Moves to the previous line of the script-editing buffer. Quotes the next character (that is, allows you to insert control characters). Retypes the line. Erases the entire line, storing the erased characters in a save buffer. Erases from the beginning of the word to just before the cursor, storing erased characters in a save buffer. Inserts the contents of the save buffer before the cursor. Inserts a new line at the cursor position and advances to the next line.

29 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 275 Command Delete Backspace Meaning Erases the previous character. Erases the previous character. OPENBOOT SECURITY Anyone who has access to a computer keyboard can access OpenBoot and modify parameters unless you set up the security variables. These variables are listed in Table TABLE 3.11 O PENB OOT S ECURITY VARIABLES Variable security-mode security-password Description Restricts the set of operations that users are allowed to perform at the OpenBoot prompt. Specifies the firmware security password. (It is never displayed.) You should not set this variable directly; you set it by using password. security-#badlogins Specifies the number of incorrect security password attempts. To set the security password, you type the password at the ok prompt, as shown in the following: New password (only first 8 chars are used): <enter password> Retype new password: <enter password> Earlier in this chapter you learned how to change the OpenBoot parameter security-password from the command line. After you assign a password, you can set the security variables that best fit your environment. You use security-mode to restrict the use of OpenBoot commands. When you assign one of the three values shown in Table 3.12, access to commands is protected by a password. The syntax for setting security-mode is as follows: setenv security-mode <value> W ARNING Setting the OpenBoot Security Mode It is important to remember your security password and to set it before setting the security mode. If you later forget this password, you cannot use your system; you must call your vendor s customer support service to make your machine bootable again. If you are able to get to a Unix prompt as root, you can use the eeprom command to either change the security-mode parameter to none or reset the security password.

30 276 Part I EXAM PREPARATION TABLE 3.12 O PENB OOT S ECURITY VALUES Value full command none Description Specifies that all OpenBoot commands except go require a password. This security mode is the most restrictive. Specifies that all OpenBoot commands except boot and go require a password. Specifies that no password is required. This is the default. The following example sets the OpenBoot environment so that all commands except boot and go require a password: setenv security-mode command With security-mode set to command, a password is not required if you enter the boot command by itself or if you enter the go command. Any other command requires a password, including the boot command with an argument. The following are examples of when a password might be required when security-mode is set to command: Example ok boot ok go ok boot vmunix Description No password is required. No password is required. A password is required. The system displays a password prompt as follows: Prompt Password ok reset-all Description The password is not echoed as it is typed. A password is required. The system displays a password prompt as follows: Prompt Password Description Type the password. Note that with Password, the password is not echoed as it is typed.

31 Chapter 3 SYSTEM STARTUP AND SHUTDOWN 277 If you enter an incorrect security password, there is a delay of about 10 seconds before the next startup prompt appears. The number of times that an incorrect security password can be typed is stored in the security-#badlogins variable, but you should not change this variable. OPENBOOT DIAGNOSTICS You can run various hardware diagnostics in OpenBoot to troubleshoot hardware and network problems. The diagnostic commands are listed in Table TABLE 3.13 O PENB OOT D IAGNOSTIC C OMMANDS Command probe-scsi probe-ide test <device-specifier> Description Identifies devices attached to a SCSI bus. Identifies IDE devices attached to the PCI bus. Executes the specified device s self-test method. For example, test floppy tests the floppy drive (if installed), and test net tests the network connection. test-all <device-specifier> watch-clock watch-net Tests all devices that have built-in self-test methods below the specified device tree node. If <device-specifier> is absent, all devices beginning from the root node are tested. Tests the clock function. Monitors the network connection. The following examples use some of the diagnostic features of OpenBoot. To identify peripheral devices currently connected to the system, such as disks, tape drives, or CD-ROMs, you use OpenBoot probe commands. To identify the various probe commands and their syntax, you use the OpenBoot sifting command, as follows: sifting probe