You've come to this page because you've asked a question similar to the following:
What is the gen on emergency and rescue mode bootstrap?
This is the Frequently Given Answer to such questions.
There are two generally recognized exceptional modes of bootstrapping a Linux system:
/
filesystem is mounted either read-only or read-write, depending from arguments (ro
and rw
) passed on the kernel command line from the boot loader.
fsck
, mounts all configured autoboot filesystems, and provides a secure login on the console.
The /
filesystem is remounted as normal, according to the filesystem database configuration.
The nature of the secure login varies somewhat, and is problematic.
Thus we come to the UNIX warm boot procedure: put 173000 into the switches, push load address and then push start. The alternate-switch setting of 173030 that will load warm UNIX is used as a signal to bring up a single user system for special purposes.
— Ken Thompson (1972-03-15). "Boot Procedures". Unix Programmer's Manual. § 8.
In the original UNIX init system, one could bootstrap Warm UNIX into two modes.
The init
program checked the front panel switches, and if they held some value other than 173030 it branched over single-user mode to the multi-user mode code; if they held that value it executed the single-user mode code.
So:
To bootstrap into
To bootstrap into
This separation between single-user mode and multi-user mode lasted for the next quarter of a century.
The init
program in AT&T System 5 UNIX entered single-user mode if there was no /etc/inittab
file, or if the init
command was invoked with the s
or S
argument.
This is the design that Linux people copied when Miquel van Smoorenburg and others wrote the Minix/Linux clone of AT&T init
, rc
, and their associated tools in the early 1990s.
(Linux people now erroneously refer to this clone as "System 5 init
", even though it isn't actually the software from UNIX System 5, and isn't just init
.)
2.57d 03-Dec-1995 - Added sulogin - Added "-b" flag to init, gives a shell before anything else (in case the startup scripts are screwed)
In 1995, though, things changed.
Linux init
gained a -b
flag and the accompanying toolset gained a sulogin
program.
The -b
flag, supplied to process #1 by the kernel (which itself received it from the boot loader), caused init
to invoke sulogin
before doing anything else.
Linux sulogin
was essentially a clone of the SCO Unix utility of that name, which was very simple in operation:
It repeatedly prompted for the root
password, invoking a shell as the superuser if the correct one was entered, until the operator sent the EOF special character on the terminal.
Linux sulogin
grew extensions beyond this simple operation:
Password lookup could fall back to raw processing of the system account database files if the C library's account database API functions failed to find the superuser account.
A non-login shell was invoked by design, thereby avoiding processing shell profile and login scripts.
sulogin
was also invoked by runlevel 1
.
These two routes to sulogin
differed in what else happened.
The runlevel 1
route invoked every initialization step from runlevels S
and 1
before running sulogin
.
The -b
option route invoked sulogin
without doing any of that.
If you need to check the root file system, you can reboot into single-user mode with the root partition mounted read-only by issuing the
-b
switch at the LILO prompt. The-b
switch will be passed through LILO to init and will cause an emergency boot […]
— David A. Bandel (1997-01-01). Disk Maintenance under Linux. Linux Journal.
Booting into Rescue Mode: To boot into a mode that allows system repairs, first try booting into runlevel 1 […]
— Dee-Ann LeBlanc (1999). General Linux I: Exam Prep. Coriolis Group Books. ISBN 9781576105672.
Within a handful of years, the ideas of "emergency mode" and "rescue mode" for these two routes had taken root.
Because usually the initramfs bootstrap program (/init
) would mount the /
filesystem read-only, "emergency mode" became (amongst other things) the well-known route to having a shell on a system such that the /
volume could be repaired with interactive fsck
.
"rescue mode" was a slightly more diluted concept, partly because bootstrapping a different operating system installation entirely, on a removable disc or some such, was also called "rescue mode".
But the idea that runlevel 1
is "rescue mode" can be found propagated by many sources including Linux For Dummies (from 2001).
These ideas persist until today.
Both systemd and nosh, for examples, continue to employ them.
nosh has emergency
and rescue
service bundles.
systemd has emergency.target
and rescue.target
targets.
In both cases, they are invoked (in place of the normal bootstrap mode) by the system management when process #1 receives command-line arguments such as -b
, emergency
, -s
, s
, S
, single
, and 1
.
Some of the details of the mechanisms have changed, though.
Emergency and rescue modes are seen nowadays as modes in which the system is up and running.
They are not modes that the system shuts down to, and are not reached by shutdown procedures.
This has forced changes in the semantics of the shutdown
command (in both the nosh toolset and in systemd).
The operation of shutdown
used to be that shutting down to single-user mode was the default action, which could be overriden with its -r
and -h
options.
The halt (-h
) action was further subdivided by the -H
and -P
options into halt-and-loop-indefinitely and halt-and-power-off.
Now that there is not even the concept of shutting down to single-user mode, the default shutdown action is to halt and power off.
The -h
and -P
options select what is already the default action, and are effectively superfluous; leaving the -r
and -H
options to select reboot and halt-and-loop-indefinitely.
The one-size-fits-all model of secure login provided by invoking sulogin
in both emergency and rescue modes has problems covering a wide range of use cases.
Some installations lock the root
account's password, with the aim of always preventing direct superuser log-on.
They don't want sulogin
's (sometime) behaviour of bypassing locked root passwords entirely (originating in Debian Bug #326678 and further adjusted with Debian Bug #789950, Debian Bug #806852, and Debian Bug #802211).
Some installations want users other than the super-user to be able to log on in rescue mode.
They don't want sulogin
's behaviour of not allowing any other user than the superuser to log on.
Some installations want the BSD behaviour of a console marked as secure
in the /etc/ttys
database. (c.f. Debian Bug #67321.)
They don't want sulogin
's behaviour of prompting for the superuser password, at all.
nosh system management tackles this by not actually employing sulogin
at all.
It is a SCO-ism that does not exist at all in the BSD world, in the first place.
Instead, there's a stronger differentiation between emergency mode and rescue mode.
The emergency-login@console
service uses an emergency-login
command that exists for both Linux and the BSDs, and the rescue
service uses the ordinary login
command.
The upshot of this is:
In emergency mode, the fallback to permitting superuser access when the system is so messed up that even the system account database isn't usable, is present. In rescue mode, there is no such fallback.
In emergency mode, the login prompt is hardwired and only the superuser account can log on. In rescue mode, the login prompt is the normal one, and any user can log on in the normal way.
In emergency mode, there are fallbacks for an unavailable or misconfigured shell and the shell is invoked as a non-login shell in order to avoid potentially problematic shell profiles or logon scripts. In rescue mode, the shell after login is a normal login shell.