The Outlook of a Startup Procedure

Single−user mode can be a security problem for a system, because full control over the system is granted. On older UNIX systems, no password was required, but physical access to the system was required in the single−user mode. On some systems, a front panel lock with normal secure vs. maintenance service key positions enabled multi−user vs. single−user mode; the system protection was the key, and only authorized personnel could acquire the key. Modern UNIX systems usually require a root password to enter single−user mode. None of these approaches are perfect, and all of them have some disadvantage. A request for the root password could make difficulties under different circumstances, if the root password was forgotten. While the BSD flavored system could be in one of three possible states — off, single−user, and multi−user mode — the System V platform explicitly defines a series of system states, called run−levels designated by a one−character name. System V run−levels are flavor dependent; an example is listed in the following table: Run−Level Name and Uses Power−down state = safe to power−off the system 1 Administrative state s or S Single−user mode on many systems same as 1 2 Multi−user mode for stand−alone system 3 Multi−user mode for networked system, possibly sharing disks with other systems = via RFS, TCPIP, and NFS, or some other protocol 4 Unused = can be user defined locally 5 Firmware state = for maintenance and running diagnostics, and for booting from an alternate not−root disk 6 Shutdown and reboot state = to reboot system from some running state s, 2, 3, or 4; the system is taken down to run−level 0 and then rebooted back To display the current system run−level, the following command is available: who −r .run−level 3 Mar 14 11:14 3 0 S The system was taken to run−level 3, from run−level S, via run−level 0, on March 14, at 11:14. The leading dot is by default at the beginning of the line. On the System V platform, movement between run−levels is managed by init, and each run−level is controlled by its own set of initialization scripts.

4.2.5 The Outlook of a Startup Procedure

UNIX systems are configured to boot automatically when powered−on. If this is not possible, systems enter some form of the ROM monitor mode — a restricted ROM resident command interpreter that enables essential diagnostics, booting, and some other basic system activities. The ROM monitor mode is also the state that the system enters after being shut down; in that state, a system can be safely powered off. On some systems there is also a keystroke combination to enter this mode — for example on Sun Microsystems systems, the key STOP−A followed by the specific ROM monitor prompt OK. 92 On old UNIX systems, manual booting from the ROM monitor was a two−stage procedure: The boot command first loaded a boot program with a stand−alone shell actually a mini−operating system. 1. A second command was then issued in a stand−alone shell to load UNIX kernel. 2. This two−step procedure looked like this: b unix Different prompts specify two steps in the boot procedure. The technology available in the past limited the bootstrap program possibilities, which led to a more complicated startup procedure. Today all UNIX flavors provide a relatively verbose system startup; a number of messages are directed to the console indicating the stage and status of the startup procedure. It is highly recommended that you monitor the system startup on the console. Otherwise, some trouble messages can remain undetected, which leads to a high probability for later surprises. The startup sequences for two system user modes are presented in Figures 4.1 and 4.2. The UNIX system named atlas is running Solaris 2.x.; brief comments follow. Figure 4.1: An illustration of a multiple−user startup sequence. 93 Figure 4.2: An illustration of a single−user startup sequence. The Sun logo and first five lines are printed from the bootstrap program. These lines list basic system configuration and identification data, as well as the kind of boot device. The somewhat cryptic description of a boot device indicates an SCSI disk. The kernel prints only two identification lines that include the system version and release. Other lines are printed from initialization scripts invoked by the program init. One of the lines indicates that the system was customized. The message that indicates the start of the HTTP service is not a part of a regular OS installation — obviously, this site has been customized to provide an Internet service. At the end, the login prompt is displayed upon the console initialization. The startup procedure includes filesystem checking, one of the most important activities performed by the fsck utility fsck is discussed in greater detail in Chapter 5. The filesystem verifications are different on BSD and System V platforms. BSD checks all filesystems on every boot; System V does not check filesystems if they were dismounted normally when the system last went down the fsstat command is used for this purpose, and faster booting is enabled. Filesystem checking can result in the display of many messages depending on the current filesystem status. If more serious filesystem corruption is encountered, the system is left in single−user mode, and manual filesystem checking and repair by the administrator may be required. A single−user startup sequence is much shorter, and it includes the boot and kernel lines. The next two lines about the network interface configuration and hosts name are printed from corresponding initialization scripts involved in the system single−user startup. Finally, the console is activated and the user is informed of two possibilities: 94 Or continue with multi−user startup by entering [Ctrl−D] 2. If [Ctrl−D] is entered, the system continues with the multi−user startup, as in the previous case.

4.2.6 Initialization Scripts