• Choose a category
• All
• Classic-Fiction

Red Hat’s single-user mode is particularly fragile. Red Hat tries to fsck and mount every local filesystem before it enters single-user mode, and almost none of its commands are statically linked. If your shared libraries are not mounted or are not functioning properly, commands that are not statically linked will not run. Even Red Hat’s basic file manipulation commands, networking utilities, and text editors require the presence of a functioning set of shared libraries.

For these reasons, trying to deal with Red Hat’s single-user mode is often a waste of time. If you have broken your libraries or your linker, you’ll need to have a Red Hat rescue floppy handy. Instead of entering single-user mode, it’s almost always more convenient to use Red Hat’s “confirmation” boot mode for minor problems or to go directly to the rescue floppy.

FreeBSD single-user mode

To enter single-user mode, first select FreeBSD from the first-stage boot loader:

F1 FreeBSD

Default: F1

Then, interrupt the boot loader when prompted and type boot -s:

Hit [Enter] to boot immediately, or any other key for the command prompt.

Booting [kernel] in 9 seconds...

Type '?' for a list of commands, 'help' for more detailed help.

disk1s1a:> boot -s

The system continues booting up to the point at which you are prompted for the path to a shell. You can just press for /bin/sh.

The second-stage boot prompt understands a variety of commands. For example, to locate and boot an alternate kernel, you’d use a sequence of commands such as this:

disk1s1a:> ls

d var

d stand

d etc

...

kernel.SYNACK

kernel.LMC

kernel

...

disk1s1a:> unload

disk1s1a:> load kernel.SYNACK

disk1s1a:> boot

This transcript shows the operator obtaining a directory listing of the default root filesystem, unloading the default kernel (/kernel), loading a replacement kernel (/kernel.SYNACK), and then continuing the boot process.

2.4 STARTUP SCRIPTS

After you exit from single-user mode (or, in the automated boot sequence, at the point at which the single-user shell would have run), init executes the system startup scripts. These scripts are really just garden-variety shell scripts that are interpreted by sh. The exact location, content, and organization of the scripts vary considerably from system to system.

Startup scripts can be organized in two principal ways, each deeply rooted in ancient history. On systems descended from BSD, the scripts are kept in the /etc directory and have names starting with the letters rc. On SystemV-derived systems, the scripts are kept in the /etc/init.d directory and links to them are made in the directories /etc/rc0.d, /etc/rc1.d, and so on. SysV’s organization is cleaner, and since each script can be used to either start or stop a facility, it allows the system to be shut down in an orderly manner.

Some tasks that are often performed in the startup scripts are:

• Setting the name of the computer

• Setting the time zone

• Checking the disks with fsck (only in automatic mode)

• Mounting the system’s disks

• Removing old files from the /tmp directory

• Configuring network interfaces

• Starting up daemons and network services

Most startup scripts are quite verbose and print out a description of everything they are doing. This loquacity can be a tremendous help if the system hangs midway through booting or if you are trying to locate an error in one of the scripts.

On systems of yore, it was common practice to modify startup scripts to make them do the right thing for a particular environment. These days, the scripts supplied by your vendor should be general enough to handle most any configuration. Instead of putting the details of your local configuration in the code of the scripts, you put them in a separate configuration file (or set of files) that the scripts consult. The config files are normally just mini sh scripts that the startup scripts include to define the values of certain shell variables.

SystemV-style startup scripts

SystemV-ish scripts are the most common