The gen on emergency and rescue mode bootstrap

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:

The nature of the secure login varies somewhat, and is problematic.

The history behind this

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:

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 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)

"sysvinit" change log.

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:

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.

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 problems with secure login

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.

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 a 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: