|[ Team LiB ]|
Starting Up Systems
Starting up systems is an integral part of performing system administration tasks. This section describes procedures for routinely starting up systems. If a system does not start up gracefully, see your system documentation for information on how to diagnose booting problems.
Choosing an Init State
The init state (also called run level) determines what programs are started or initialized when a system is booted. A system can be in only one init state at a time. The Solaris Operating Environment has eight init states; the default init state for each system is specified in the /etc/inittab file. The default init state for the Solaris Operating Environment is run level 3. Table 1 shows the available run levels and the state of the system at each level.
The /sbin/init command is responsible for keeping the system running correctly and is the command you use to change init states. You can also use the init states (with the -i option) as arguments to the shutdown command. The four types of system states are described below.
When preparing to do a system administration task, you need to determine which init state is appropriate for the system and the task at hand.
The /etc/inittab File
When you boot a system or use the init or shutdown command to change run levels, the init daemon starts processes by reading information from the /etc/inittab file. This file defines the following important items for the init process.
Each entry in the /etc/inittab file has the following fields.
id: rstate: action: process
Table 2 describes the fields in the /etc/inittab file.
The following example shows a default /etc/inittab file.
ap::sysinit:/sbin/autopush -f /etc/iu.ap ap::sysinit:/sbin/soconfig -f /etc/sock2path fs::sysinit:/sbin/rcS sysinit >/dev/msglog 2<>/dev/msglog </dev/console is:3:initdefault: p3:s1234:powerfail:/usr/sbin/shutdown -y -i5 -g0 >/dev/msglog 2<>/dev/msglog sS:s:wait:/sbin/rcS >/dev/msglog 2<>/dev/msglog </dev/console s0:0:wait:/sbin/rc0 >/dev/msglog 2<>/dev/msglog </dev/console s1:1:respawn:/sbin/rc1 >/dev/msglog 2<>/dev/msglog </dev/console s2:23:wait:/sbin/rc2 >/dev/msglog 2<>/dev/msglog </dev/console s3:3:wait:/sbin/rc3 >/dev/msglog 2<>/dev/msglog </dev/console s5:5:wait:/sbin/rc5 >/dev/msglog 2<>/dev/msglog </dev/console s6:6:wait:/sbin/rc6 >/dev/msglog 2<>/dev/msglog </dev/console fw:0:wait:/sbin/uadmin 2 0 >/dev/msglog 2<>/dev/msglog </dev/console of:5:wait:/sbin/uadmin 2 6 >/dev/msglog 2<>/dev/msglog </dev/console rb:6:wait:/sbin/uadmin 2 1 >/dev/msglog 2<>/dev/msglog </dev/console sc:234:respawn:/usr/lib/saf/sac -t 300 co:234:respawn:/usr/lib/saf/ttymon -g -h -p "`uname -n` console login: " -T sun -d /dev/console -l console -m ldterm,ttcompat
Run Control Scripts
The init command uses a different script for each run level instead of grouping all of the run levels together. The files named by a run level are located in the /sbin directory.
The following listing shows the default run control scripts in the /sbin directory.
mopoke% ls -l /sbin/rc* -rwxr--r-- 3 root sys 2792 Nov 8 2001 /sbin/rc0 -rwxr--r-- 1 root sys 3177 Nov 8 2001 /sbin/rc1 -rwxr--r-- 1 root sys 2922 Nov 8 2001 /sbin/rc2 -rwxr--r-- 1 root sys 2403 Nov 8 2001 /sbin/rc3 -rwxr--r-- 3 root sys 2792 Nov 8 2001 /sbin/rc5 -rwxr--r-- 3 root sys 2792 Nov 8 2001 /sbin/rc6 -rwxr--r-- 1 root sys 9934 Nov 8 2001 /sbin/rcS mopoke%
Run control files are located in the /etc/init.d directory. These files are linked to corresponding run control files in the /etc/rc*.d directories. The files in the /etc directory define the sequence in which the scripts are performed within each run level. For example, the /etc/rc2.d directory contains files, listed below, that start and stop processes for run level 2.
mopoke% ls /etc/rc2.d K03samba S21perf S73nfs.client S90wbem K03sshd S30sysid.net S74autofs S91afbinit K06mipagent S40llc2 S74syslog S91gfbinit K07dmi S42ncakmod S74xntpd S91ifbinit K07snmpdx S47pppd S75cron S92volmgt K16apache S69inet S75flashprom S93cacheos.finish K21dhcp S70sckm S75savecore S94ncalogd K27boot.server S70uucp S76nscd S95IIim K28kdc S71ldap.client S77sf880dr S95svm.sync K28kdc.master S71rpc S80lp S96ab2mgr K28nfs.server S71sysid.sys S80spc S98efcode README S72autoinstall S85power S99audit S01MOUNTFSYS S72directory S88sendmail S99dtlogin S05RMTMPFILES S72inetsvc S88utmpd S10lu S72slpd S89bdconfig S20sysetup S73cachefs.daemon S89PRESERVE mopoke%
The scripts are always run in ASCII sort order. The names of the scripts have the form [K, S][0 - 9][A - Z][0 - 99]. Files beginning with K are run to terminate (kill) some system process. Files beginning with S are run to start a system process. The actions of each run-level control script are summarized in the following sections.
The /sbin/rc0 Script
The /sbin/rc0 script performs the following tasks.
The /sbin/rc1 Script
The /sbin/rc1 script runs the /etc/rc1.d scripts to perform the following tasks.
The /sbin/rc2 Script
The /sbin/rc2 script runs the /etc/rc2.d scripts to perform the following tasks.
Local system-related tasks:
Network service and security-related tasks:
NOTE. Many of the system services and applications started at run level 2 depend on what software is installed on the system.
The /sbin/rc3 Script
The /sbin/rc3 script runs the /etc/rc3.d scripts to perform the following tasks.
The /sbin/rc5 and /sbin/rc6 Scripts
The /sbin/rc5 and /sbin/rc6 scripts run the /etc/rc0.d/K* and S* scripts (in that order) to perform the following tasks.
The /sbin/rcS Script
The /sbin/rcS script runs the /etc/rcS.d scripts to bring the system to run level S and perform the following tasks.
Finding the Run Level for a System
To find the run level for a system, type who -r and press Return. The run level, date and time of the last run-level change, process termination status, process exit status, number of times at this run level since the last reboot, and previous run level are displayed.
In the following example, the system named paperbark is at the default multiuser run level (3), the date and time of the last run-level change is May 2 08:34, the process exit status is 3, the number of times at this run level since the last reboot is 0, and the previous run level is S.
paperbark% who -r . run-level 3 May 2 08:34 3 0 S paperbark%
The next sections describe how you might use each init state.
Using OpenBoot PROM State, Run Level 0
Using Single-User State, Run Level s and S
Use run level s or S when performing administrative tasks that require you to be the only user on the system with all file systems mounted and accessible. The terminal from which you issue the init s command becomes the console. No other users are logged in.
NOTE. In the Solaris 7 release, Bug ID 1154696 was fixed so that you can cleanly bring a system to run level S (or single-user mode) by using the shutdown -s or the init -s command. The inittab file and the rc scripts in the /etc/init.d directory and the /etc/rcn.d directories have been modified to ensure that system run-level transitions are made cleanly and efficiently.
Using Administrative State, Run Level 1
Use run level 1 as a single user to access all available file systems with no user logins allowed.
Using Multiuser State, Run Level 2
Use run level 2 for normal operations. Multiple users can access the system and the entire file system. All daemons are running except for NFS server and syslog.
NOTE. A daemon is a special type of program that, once activated, starts itself and carries out a specific task without any need for user input. Daemons typically are used to handle jobs, such as printing, mail, communication, UPS monitors (to shut down a system in case the UPS says that a power outage is imminent), and Web servers.
Using Remote Resource-Sharing State, Run Level 3
Use run level 3 for normal operations with NFS resource-sharing available.
Using Alternative Multiuser State, Run Level 4
Run level 4 is an alternative multiuser state, currently not used.
Using Power-Down State, Run Level 5
Use run level 5 to shut down the operating system so that it is safe to turn off power to the system. If possible, automatically turn off power on systems that support this feature.
Using Reboot State, Run Level 6
Use run level 6 to shut down the system to run level 0, and then reboot to multiuser level (or to whatever level is the default in the inittab file).
Changing Run Levels
Use either the telinit or init command to change run levels. The telinit command takes a one-character argument that tells init what run level to use. Although you can use the init command directly, telinit is the preferred command to use to change system run states.
Use the following steps to change run levels.
The following example shuts down the system and places the focus at the OpenBoot PROM prompt (on SPARC systems only).
oak% su Password: # telinit 0
The following example changes the system to single-user state.
oak% su Password: # telinit 1
The following example changes to multiuser state, with no NFS server daemons running.
oak% su Password: # telinit 2
The following example changes to multiuser state, with NFS server daemons running.
oak% su Password: # telinit 3
The following example shuts down and reboots a system.
oak% su Password: # telinit 6
Using Platform-Specific Booting Protocols
The OpenBoot PROM and Interface (SPARC Platforms)
Each SPARC system has a programmable read-only memory (PROM) chip with a program called the monitor. The monitor controls operation of the system before the kernel is available. When you turn a system on, the monitor runs a quick self-test procedure to check things such as the hardware and memory on the system. If the monitor finds no errors, the system begins the automatic boot process.
NOTE. Some older systems may require PROM upgrades before they will work with the Solaris Operating Environment. Contact your local service provider for more information.
The boot process consists of the boot PROM, boot programs, kernel initialization, and system initialization phases. These phases are summarized in Table 3.
The OpenBoot firmware on the SPARC PROM not only initiates the boot process but also provides a command-line interface. OpenBoot provides two modes. The restricted monitor mode, which displays the > prompt, provides only three commands. These commands enable you to boot the operating system (b specifiers), resume the execution of a halted program (c), or enter the Forth Monitor (n).
The Forth Monitor, also referred to as new command mode, is the default mode of the OpenBoot firmware. The Forth Monitor displays the ok prompt. This monitor enables you to access an extensive set of diagnostic commands for hardware and software. Anyone who has access to the system console can access these functions. To access the restricted monitor, at the ok PROM prompt, type old-mode and press Return.
Displaying the PROM Release for a System
To display the PROM release for a system, at the ok PROM prompt, type banner and press Return. Hardware configuration information, including the release number of the PROM is displayed, as shown in the following example.
ok banner Sun Blade 100 (UltraSPARC-IIe, Keyboard Present Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.5, 128 MB memory, installed, Serial #50640486. Ethernet address 0:23:ba:4:b6:66, Host ID 8304b666
OpenBoot Configuration Information
OpenBoot configuration parameters are listed in Table 4.
NOTE. Not all OpenBoot systems support all parameters. Defaults can vary depending on the system and the PROM revision.
You can display and set the list of OpenBoot commands from Solaris by using the eeprom command or display the list at the ok PROM prompt by typing printenv and pressing Return.
The following example uses the eeprom command without arguments to display the current settings.
mopoke% eeprom test-args: data not available. diag-passes=1 pci-probe-list=7,c,3,8,d,13,5 local-mac-address?=false fcode-debug?=false ttyb-rts-dtr-off=false ttyb-ignore-cd=true ttya-rts-dtr-off=false ttya-ignore-cd=true silent-mode?=false scsi-initiator-id=7 oem-logo: data not available. oem-logo?=false oem-banner: data not available. oem-banner?=false ansi-terminal?=true screen-#columns=80 screen-#rows=34 ttyb-mode=9600,8,n,1,- ttya-mode=9600,8,n,1,- output-device=screen input-device=keyboard load-base=16384 auto-boot?=true boot-command=boot diag-file: data not available. diag-device=disk net boot-file: data not available. boot-device=disk:a disk net use-nvramrc?=false nvramrc: data not available. security-mode=none security-password: data not available. security-#badlogins=0 diag-script=none diag-level=max diag-switch?=false error-reset-recovery=boot mopoke%
The following example sets the method for setting the auto-boot? parameter to true. You may need to enclose the command in double quotation marks to prevent the shell from interpreting the question mark.
# eeprom "auto-boot?"=true #
Alternatively, you can precede the question mark with an escape character (\) to prevent the shell from interpreting the question mark.
Commands Used to View or Modify Configuration Variables
Table 5 describes the commands you can use from the ok PROM prompt to view or modify the OpenBoot configuration variables.
OpenBoot Firmware Security Levels
The OpenBoot firmware provides three levels of system security: none, command, and full.
For the none security level, no password is required. Users can change all OpenBoot settings, including the boot disk partition and execute any command. By default, Sun systems are shipped with the OpenBoot security level set to none.
For the command security level, a password is required for all commands except boot and go (continue system operation after a Stop-A, L1-A, or Break sequence).
For the full security level, a password is required for all OpenBoot commands except go.
You can set the OpenBoot security level either while running Solaris or from the ok PROM prompt.
Use the following steps to set the OpenBoot security level from Solaris.
In the following example, the security level is set to command.
paperbark% su Password: # eeprom security-mode=command
To set the OpenBoot security level, at the ok PROM prompt, type security-mode=level and press Return.
In the following example, the security level is set to full.
For more information, refer to the eeprom(1M) manual page or to the OpenBoot documentation available from Sun Microsystems.
The PC BIOS (IA Platforms)
For IA platforms, before the kernel is started, the system is controlled by the read-only-memory (ROM) Basic Input/Output System (BIOS), which is the firmware interface on a PC.
Hardware adapters can have an onboard BIOS that displays the physical characteristics of the device and that can be used to access the device. During the startup sequence, the PC BIOS checks for the presence of an adapter BIOS and, if it finds one or more, loads and executes each one. The BIOS for each individual adapter runs self-test diagnostics and displays device information.
You can make the choices about booting a system at three times during the Solaris IA boot process, as described below.
Table 6 describes the IA Platform boot subsystems.
When booting an IA platform, the Configuration Assistant performs the following tasks during the device identification phase.
During the boot phase, the system displays a list of devices from which to boot. The asterisk (*) marks the default boot device. You can perform optional tasks, such as editing autoboot and property settings.
The boot process consists of the BIOS, boot programs, kernel initialization, and system initialization phases. These phases are summarized in Table 7.
Booting a System
If a system is powered off, turning it on starts the multiuser boot sequence. The following procedures tell you how to boot in different states from the ok PROM prompt. If the PROM prompt is >, type n to display the ok prompt, and then follow the appropriate steps.
NOTE. The PROM prompt description is for SPARC systems.
Table 8 describes commands for booting a system for different reboot reasons.
Booting in Multiuser State
To boot in multiuser state, at the ok PROM prompt, type boot and press Return. The automatic boot procedure starts on the default drive, displaying a series of start-up messages. The system is brought up in multiuser state.
Booting in Single-User State
To boot in single-user state, at the ok PROM prompt, type boot -s and press Return. The system boots to single-user state and prompts you for the root password.
ok boot -s INIT: SINGLE USER MODE Type Ctrl-d to proceed with normal start-up, (or give root password for system maintenance) Type the root password and press Return.
NOTE. To continue the process and bring the system up in multiuser state, press Control-D.
You may boot interactively if you want to make a temporary change to the system file or the kernel. In this way, you can test your changes and recover easily if you have any problems.
In the following example, the user accepted the default choices (shown in square brackets ) by pressing Return.
ok boot -a (Hardware configuration messages) rebooting from -a Boot device: /sbus/esp@0,800000/sd@0,0 File and args: -a Enter filename [/kernel/unix]: Enter default directory for modules [/platform/SUNW,Ultra-2/kernel /platform/sun4u/kernel /kernel /usr/kernel]: Name of system file [/etc/system]: (Copyright notice) root filesystem type [ufs] Enter physical name of root device [/sbus@if,0/SUNW,fas@e,email@example.com:a]: Swap filesystem type [swapfs] Configuring IPv4 interfaces: le0 Hostname: paperbark The system is coming up. Please wait. (fsck messages) (Startup messages) paperbark login:
Looking at the Boot Messages
The most recent boot messages are stored in the /var/adm/messages file. To see these messages after you have booted the system, type more/var/adm/messages and press Return. The /usr/sbin/dmesg command is obsolete; however, you can still use it to display boot messages.
NOTE. You can now view /usr/sbin/dmesg text from a CDE terminal window, which was not possible in previous releases.
Because the /var/adm/messages file is maintained in chronological order, the most current boot messages are at the end of the file. The following example shows the last 30 lines of the /var/adm/messages file.
paperbark% tail -30 /var/adm/messages Mar 7 18:11:15 paperbark swapgeneric: [ID 308332 kern.info] root on /sbus@1f,0/SUNW,fas@e,8800000/sd@0,0:a fstype ufs Mar 7 18:11:16 paperbark sbus: [ID 349649 kern.info] zs0 at sbus0: SBus0 slot 0xf offset 0x1100000 Onboard device sparc9 ipl 12 Mar 7 18:11:16 paperbark genunix: [ID 936769 kern.info] zs0 is /sbus@1f,0/zs@f,1100000 Mar 7 18:11:16 paperbark sbus: [ID 349649 kern.info] zs1 at sbus0: SBus0 slot 0xf offset 0x1000000 Onboard device sparc9 ipl 12 Mar 7 18:11:16 paperbark genunix: [ID 936769 kern.info] zs1 is /sbus@1f,0/zs@f,1000000 Mar 7 18:11:19 paperbark rootnex: [ID 349649 kern.info] ffb0 at root: UPA 0x1e 0x0 Mar 7 18:11:19 paperbark genunix: [ID 936769 kern.info] ffb0 is /SUNW,ffb@1e,0 Mar 7 18:11:19 paperbark unix: [ID 987524 kern.info] cpu0: SUNW,UltraSPARC (upaid 0 impl 0x10 ver 0x22 clock 168 MHz) Mar 7 18:11:22 paperbark hme: [ID 517527 kern.info] SUNW,hme0 : Sbus (Rev Id = 22) Found Mar 7 18:11:22 paperbark sbus: [ID 349649 kern.info] hme0 at sbus0: SBus0 slot 0xe offset 0x8c00000 and slot 0xe offset 0x8c02000 and slot 0xe offset 0x8c04000 and slot 0xe offset 0x8c06000 and slot 0xe offset 0x8c07000 Onboard device sparc9 ipl 6 Mar 7 18:11:22 paperbark genunix: [ID 936769 kern.info] hme0 is /sbus@1f,0/SUNW,hme@e,8c00000 Mar 7 18:11:24 paperbark genunix: [ID 454863 kern.info] dump on /dev/dsk/c0t0d0s1 size 512 MB Mar 7 18:11:26 paperbark hme: [ID 517527 kern.info] SUNW,hme0 : Internal Transceiver Selected. Mar 7 18:11:26 paperbark hme: [ID 517527 kern.info] SUNW,hme0 : Auto-Negotiated 10 Mbps Half-Duplex Link Up Mar 7 18:12:01 paperbark pseudo: [ID 129642 kern.info] pseudo-device: pm0 Mar 7 18:12:01 paperbark genunix: [ID 936769 kern.info] pm0 is /pseudo/pm@0 Mar 7 18:12:01 paperbark pseudo: [ID 129642 kern.info] pseudo-device: tod0 Mar 7 18:12:01 paperbark genunix: [ID 936769 kern.info] tod0 is /pseudo/tod@0 Mar 7 18:12:02 paperbark sendmail: [ID 702911 mail.crit] My unqualified host name (paperbark) unknown; sleeping for retry Mar 7 18:12:03 paperbark pseudo: [ID 129642 kern.info] pseudo-device: devinfo0 Mar 7 18:12:03 paperbark genunix: [ID 936769 kern.info] devinfo0 is /pseudo/devinfo@0 Mar 7 18:12:06 paperbark sws.smc: [ID 987397 daemon.notice] [1 admin.195 0 (SW) NOTICE]: Running with SWS Configuration file "/etc/ehttp/server.conf". Mar 7 18:12:10 paperbark sws.smc: [ID 409041 daemon.error] [1 servlet.353 0 (SW) ERR]: Servlet smc load error. Mar 7 18:12:10 paperbark sws.smc: [ID 420037 daemon.notice] [1 servlet.919 0 (SW) NOTICE]: Servlet Engine (with JSDK2.0) started. Mar 7 18:12:10 paperbark sws.smc: [ID 111395 daemon.notice] [1 httpd.105 0 (SW) NOTICE]: Sun_WebServer/2.1 server started. Mar 7 18:12:15 paperbark sws.smc: [ID 329940 daemon.notice] [1 httpd.135 0 (SW) NOTICE]: Shutting down server. Mar 7 18:12:18 paperbark sws.smc: [ID 987397 daemon.notice] [1 admin.195 0 (SW) NOTICE]: Running with SWS Configuration file "/etc/ehttp/server.conf". Mar 7 18:12:19 paperbark sws.smc: [ID 420037 daemon.notice] [1 servlet.919 0 (SW) NOTICE]: Servlet Engine (with JSDK2.0) started. Mar 7 18:12:19 paperbark sws.smc: [ID 111395 daemon.notice] [1 httpd.105 0 (SW) NOTICE]: Sun_WebServer/2.1 server started. Mar 7 18:13:02 paperbark sendmail: [ID 702911 mail.alert] unable to qualify my own domain name (paperbark) -- using short name paperbark%
Booting After Adding New Hardware
With the OpenBoot PROM, you can use the -r option to the boot command so that the operating system knows to look for new device drivers and incorporate them as part of the boot process.
Alternatively, if you add another device with the driver already installed, you can use the following commands to tell the system to recognize the new device.
# touch /reconfigure # _INIT_RECONFIG=YES /etc/init.d/drvconfig # _INIT_RECONFIG=YES /etc/init.d/devlinks
Forcing a Crash Dump and Rebooting the System
Sometimes you need to save crash dumps of the operating system. Starting with the Solaris 7 Operating Environment, saving crash dumps is enabled by default.
dumping to /dev/dsk/c1t0d0s1 offset 107479040, content: kernel. 100% done: 11207 pages dumped, compression ratio 2.95, dump succeeded Program terminated
Dumps are compressed to improve performance and to fit more information into existing swap partitions.
Typing the dumpadm command with no arguments shows the current settings, as shown in the following example.
mopoke% su Password: # dumpadm Dump content: kernel pages Dump device: /dev/dsk/c1t0d0s1 (swap) Savecore directory: /var/crash/mopoke Savecore enabled: yes #
Refer to the dumpadm(1M) manual page for more information.
The savecore(1M) command works with alternative kernels. In the past, the symbol table was generated from the currently installed kernel. The symbol table is now part of the dump. Before this change, if you patched the Solaris kernel and then crashed before you rebooted the system, the crash dump was useless because the symbol table generated was from the patched kernel, not the running kernel.
savecore supports large files because the file it writes can be greater than 2 Gbytes.
Administering Crash Dumps
You can administer the crash dump facility with the dumpadm(1M) command, which provides the following capabilities.
Booting the System with the Kernel Debugger
Use the following steps to boot the system by using the kernel debugger.
Refer to the kadb(1M) manual page for information about how to use the kernel debugger.
Booting a System for Recovery Purposes (SPARC Platform)
Use the following procedure on SPARC platforms when the boot process fails. The boot process can fail, for example, when an important file such as /etc/passwd has an invalid entry.
The following example shows how to repair the /etc/passwd file after booting from a local CD-ROM.
ok boot cdrom -s (Boot messages are displayed here) # mount /dev/dsk/c0t3d0s0 /a # cd /a/etc # TERM=sun;export TERM # vi passwd (Remove or edit invalid entry) # cd / # umount /a # init 6
Booting a System for Recovery Purposes (IA Platform)
Use the following procedure on IA platforms when the boot process fails. The boot process can fail, for example, when an important file such as /etc/passwd has an invalid entry.
The following example shows how to repair the /etc/passwd file after you boot from a local CD-ROM.
Type any key to reboot SunOS Secondary Boot version 3.00 Solaris Intel Platform Edition Booting System Running Configuration Assistant... Autobooting from Boot path: /pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0:a If the system hardware has changed, or to boot from a different device, interrupt the autoboot process by pressing ESC. Press ESCape to interrupt autoboot in 5 seconds. . . . Boot Solaris Select one of the identified devices to boot the Solaris kernel and choose Continue. To perform optional features, such as modifying the autoboot and property settings, choose Boot Tasks. An asterisk (*) indicates the current default boot device. > To make a selection use the arrow keys, and press Enter to mark it [X]. [ ] NET : DEC 21142/21143 Fast Ethernet on Board PCI at Dev 3 [ ] DISK: (*) Target 0, QUANTUM FIREBALL1280A on Bus Mastering IDE controller on Board PCI at Dev 7, Func 1 [ ] DISK: Target 1:ST5660A on Bus Mastering IDE controller on Board PCI at Dev 7, Func 1 [ ] DISK: Target 0:Maxtor 9 0680D4 on Bus Mastering IDE controller on Board PCI at Dev 7, Func 1 [ ] CD : Target 1:TOSHIBA CD-ROM XM-5602B 1546 on Bus Mastering IDE controller on Board PCI at Dev 7, Func 1 F2_Continue F3_Back F4_Boot Tasks F6_Help . . . <<< Current Boot Parameters >>> Boot path: /pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0:a Boot args: kernel/unix -r Select the type of installation you want to perform: 1 Solaris Interactive 2 Custom JumpStart 3 Solaris Web Start Enter the number of your choice followed by <ENTER> the key. If you enter anything else, or if you wait for 30 seconds, an interactive installation will be started. Select type of installation: b -s . . . # mount /dev/dsk/c0t0d0s0 /a . . . # cd /a/etc # vi passwd (Remove invalid entry) # cd / # umount /a # init 6
Aborting a Booting Process
Occasionally, you may need to abort the booting process. The specific abort key sequence depends on your keyboard type. For example, on SPARC systems with a Sun keyboard, you might press Stop-A or L1-A. On TTY terminals, press the Break key.
To abort the booting process, type the abort key sequence for your system. When you abort the boot process, the monitor displays the ok PROM prompt.
Type boot and press Return to restart the boot process, or type help and press Return to display a list of help options. If your terminal shows the > monitor prompt, type n to get the ok prompt.
Shutting Down a System
The following sections describe how to choose a shutdown and use it and init commands to shut down a system.
The Solaris Operating Environment is designed to be left running continuously so that the e-mail and network software can work correctly. You must, however, halt or shut down a system when performing the following tasks.
Choosing Which Shutdown Command to Use
When preparing to do a system administration task, you need to determine which shutdown command is appropriate for the system and the task at hand. The next sections describe how you might use each of the available shutdown commands.
These commands initiate shutdown procedures, kill all running processes, write out any new data to the disk, and shut down the Solaris Operating Environment to the appropriate run level.
Use the shutdown command when shutting down a system with multiple users. The shutdown command sends a warning message to all users who are logged in, waits 60 seconds (the default), and then shuts down the system to single-user state. You can choose a different default wait time.
telinit and init
Use the telinit or init command to shut down a single-user system or to change its run level. The init command changes the run level of the system. The telinit command tells init what run level you want. You can use the commands interchangeably, but telinit is the preferred command. You can use telinit to place the system in power-down state (init 0) or in single-user state (init 1).
NOTE. Use telinit/init and shutdown as the preferred method of changing system state. These programs are the most reliable way to shut down a system because they use a number of rc scripts to kill running processes.
Use the halt command when the system must be stopped immediately and it is acceptable not to warn any current users. The halt command shuts down the system without any delay and does not warn any other users on the system. The halt command does not run the rc shutdown scripts and is not the preferred method for shutting down a system.
Use the reboot command to shut down a system that does not have multiple users and to bring it back into multiuser state. The reboot command does not warn users on the system, does not run the rc scripts, and is not the preferred method for shutting down a system.
Shutting Down a Multiuser System
Before shutting down a multiuser system, inform the other users on the system and give them time to complete critical procedures such as saving changes.
paperbark% su Password: # cd / # shutdown Shutdown started. Tue May 2 13:16:57 WST 2000 Broadcast Message from root (pts/7) on paperbark Tue May 2 13:16:59... The system paperbark will be shut down in 1 minute Broadcast Message from root (pts/7) on paperbark Tue May 2 13:17:29... The system paperbark will be shut down in 30 seconds Do you want to continue? (y or n): y Broadcast Message from root (pts/7) on paperbark Tue May 2 13:17:53... THE SYSTEM paperbark IS BEING SHUT DOWN NOW! ! ! LOG OFF NOW OR RISK YOUR FILES BEING DAMAGED (Shutdown messages) INIT: SINGLE USER MODE Type control-d to proceed with normal startup, (or give root password for system maintenance):
Shutting Down a System: Alternative Ways
To change the default actions of the shutdown command, choose one of the tasks in the following six sections.
Shutting Down a System Without Confirmation
Use the following steps to shut down a system without confirmation.
Changing the Shutdown Grace Period
The default is for the shutdown command to provide a 60-second grace period to enable users to save their changes. Use the following steps to change the shutdown 60-second grace period.
The following example changes the grace period to 120 seconds.
# cd / # shutdown -g120
Shutting Down and Rebooting a Multiuser System
Use the following steps to shut down and reboot a multiuser system.
Shutting Down a Single-User System
To shut down a single-user system, type telinit 0 (or init 0) and press Return. The init command runs scripts that bring the system down cleanly. No warning messages are broadcast.
Shutting Down and Rebooting a Single-User System
To shut down and reboot a single-user system, type telinit 6 (or init 6) and press Return. Information is written to the disk, all active processes are killed, and the system is brought to a power-down state. The system is then rebooted to the default level (usually multiuser).
Shutting Down a System in a Hurry
To shut down a system in a hurry, type uadmin 2 0 and press Return. The system displays the OpenBoot PROM prompt.
|[ Team LiB ]|