Single User Mode and init system recovery target discrepancies

Question

Unix-like systems utilize Single User Mode to provide a minimal environment for filesystem repair and configuration diagnosis. This process typically involves passing specific flags to the bootloader to bypass the standard multi-user initialization sequence.

There is a lack of consistency in how different initialization systems handle the transition from the bootloader to the recovery shell. Specifically, the behavior of "emergency mode" versus "rescue mode" differs between legacy SysVinit and modern systemd implementations, particularly regarding which services are started and how the root filesystem is mounted.

Does the distinction between emergency and rescue modes affect the availability of network-based recovery tools?
  How does the root password prompt behavior vary between these two modes across different init systems?

Tasadduq Burney · Answer

Recovery Mode Discrepancies
Yes, the distinction between emergency and rescue modes significantly affects the availability of network tools and the authentication process. In modern systemd implementations, these modes represent different levels of system initialization, whereas legacy SysVinit typically relied on a single "Single User Mode" (Runlevel 1).

Network Availability and Service Scope
In systemd, the difference is defined by the depth of the initialization sequence:

Rescue Mode (rescue.target): This is the closest equivalent to legacy Single User Mode. It mounts the root filesystem and starts basic system services. However, it typically does not initialize the network stack. Network-based recovery tools (like ssh or wget) are generally unavailable unless manually started.
  Emergency Mode (emergency.target): This is a more restrictive state. It does not mount /etc/fstab filesystems (except for the root partition) and starts almost no services. Network tools are entirely unavailable in this mode.

In legacy SysVinit, Single User Mode (Runlevel 1) was designed to be a minimal environment for filesystem repair; it bypassed network initialization by default, making network-based recovery impossible without manual configuration of the network interface.

Root Password Prompt Behavior
The behavior of the password prompt varies based on the init system and the security configuration of the root account:

Init System
      Mode
      Prompt Behavior

systemd
      Rescue/Emergency
      Prompts for root password by default. If the root account is locked, it may drop to a shell or require a GRUB password.

SysVinit
      Single User (Runlevel 1)
      Traditionally dropped directly to a root shell without a password, unless specifically configured otherwise in the distribution's init scripts.

Verification Steps
To verify the current state and active services during a recovery session, use the following commands:
# Check which target is currently active
systemctl get-default

# List all active units to verify if network services are running
systemctl list-units --state=active

Missing Diagnostic Detail: To provide a more specific recommendation on password bypass or network availability, please specify if the root account is currently locked or if a GRUB bootloader password has been implemented.

Single User Mode and init system recovery target discrepancies

1 answer

0 question comments

Recovery Mode Discrepancies

Network Availability and Service Scope

Root Password Prompt Behavior

Verification Steps

Your perspective belongs here.

Init System	Mode	Prompt Behavior
systemd	Rescue/Emergency	Prompts for root password by default. If the root account is locked, it may drop to a shell or require a GRUB password.
SysVinit	Single User (Runlevel 1)	Traditionally dropped directly to a root shell without a password, unless specifically configured otherwise in the distribution's init scripts.