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 (
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.
/ 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.
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.
To bootstrap into
To bootstrap into
This separation between single-user mode and multi-user mode lasted for the next quarter of a century.
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
This is the design that Linux people copied when Miquel van Smoorenburg and others wrote the Minix/Linux clone of AT&T
rc, and their associated tools in the early 1990s.
(Linux people now refer to this clone as "System 5
init", even though it isn't actually the software from UNIX System 5, and isn't just
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)
— "sysvinit" change log.
In 1995, though, things changed.
init gained a
-b flag and the accompanying toolset gained a
-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.
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.
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
These two routes to
sulogin differed in what else happened.
1 route invoked every initialization step from runlevels
1 before running
-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
-bswitch at the LILO prompt. The
-bswitch 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
"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.
rescue service bundles.
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
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
The operation of
shutdown used to be that shutting down to single-user mode was the default action, which could be overriden with its
The halt (
-h) action was further subdivided by the
-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.
-P options select what is already the default action, and are effectively superfluous; leaving the
-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.
emergency-login@console service uses a
emergency-login command that exists for both Linux and the BSDs, and the
rescue service uses the ordinary
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.