UNIX System Administration Handbook - Evi Nemeth [20]
Operator intervention (manual boot only)
See Chapter 3 for more information about the root account. From the single-user shell, you can execute commands in much the same way as when logged in on a fully booted system. However, only the root partition is usually mounted; you must mount other filesystems by hand in order to use programs that don’t live in /bin, /sbin, or /etc.2 Daemons do not normally run in single-user mode, so commands that depend on server processes (e.g., mail) will not work correctly. See Chapter 5 for more information about filesystems and mounting. In many single-user environments, the filesystem root directory starts off being mounted read-only. If /tmp is part of the root filesystem, a lot of commands that use temporary files (such as vi) will refuse to run. To fix this problem, you’ll have to begin your single-user session by remounting / in read/write mode. The exact way that this is done varies by system. On most systems, you can run mount / to make mount consult the fstab or vfstab file and determine how the filesystem should be mounted. Red Hat’s single-user mode is a bit more aggressive than normal. By the time you reach the shell prompt, it will have tried to mount all local filesystems. Although this seems helpful at first, it can prove problematic if you have a sick filesystem. The fsck command is normally run during an automatic boot to check and repair filesystems. When you bring the system up in single-user mode, you must run fsck by hand. See page 136 for more information about fsck. When the single-user shell exits, the system will attempt to continue booting into multiuser mode. Execution of startup scripts The care, feeding, and taxonomy of startup scripts merits a major section of its own. It’s taken up in more detail starting on page 24. Multiuser operation See page 105 for more information about the login process. Keep in mind that init continues to perform an important role even after bootstrapping is complete. On BSD-based systems, init has only two states: single-user and multiuser. On other systems, init has one single-user and several multiuser “run levels” that determine which of the system’s resources are enabled. Run levels are described later in this chapter, starting on page 25. 2.2 BOOTING PCs We start our grand tour once again with the
If the system is to be brought up in single-user mode, a command-line flag passed in by the kernel notifies init of this fact as it starts up. During a single-user boot, you are normally prompted to enter the root password. If you enter the right password, the system will spawn a root shell. You can type
By the time the system is ready to run its startup scripts, it is recognizably UNIX. Even though it doesn’t quite look like a fully booted system yet, there are no more “magic” steps in the boot process. The startup scripts are just normal shell scripts, and they’re selected and run by init according to an algorithm that, though sometimes tortuous, is eminently comprehensible.
After the initialization scripts have run, the system is fully operational, except that no one can log in. For logins to be accepted on a particular terminal (including the console), a getty process must be listening on it.3 init spawns these getty processes directly, completing the boot process. init is also responsible for spawning graphical login systems such as xdm, gdm, or dtlogin if the system is set up to use them.
At this point we’ve seen the general outline of the boot process. We now revisit several of the more important (and complicated) steps, filling in some additional details and describing the specific behavior of our example systems.