At some point along Debian's journey, rescue and emergency runlevels broke for anyone who has a locked root account and, say, uses sudo exclusively to run administrative commands. See the bug report and a proposed installer patch. This is not an atypical setup—it's a standard option of the Debian installer, and happens to be one I typically use.
To summarise what's going on, the system now prevents root from logging in due to it being a locked account (having no password, it cannot be authenticated), which means that the rescue and emergency runlevels always error and fail to bring up a shell. What bloody good are they, then, right?
Not too long ago things got to the point where the system can be configured to work as expected, again, but certain settings need to be enabled beforehand. This is described below. Note that doing so arguably introduces a security issue, but if you're happy to run Grub with editable boot entries (so that any user could, say, set init=/bin/bash on the kernel command line), then you're unlikely to have any reason to care.
First switch to root using “sudo su -”. Then:
for x in /etc/systemd/system/rescue.service.d/override.conf /etc/systemd/system/emergency.service.d/override.conf do mkdir -p "$(dirname $x)" cat > "$x" <<EOF [Service] Environment=SYSTEMD_SULOGIN_FORCE=1 EOF done
After that, you can exit back out of the root account. (If the runlevels still don't work, maybe you gave root a password at some point? Double-check /etc/shadow.)
In the future, the Debian installer may do this automatically. (You might want to check that the files mentioned in the code snippet above don't already exist.) But for the time-being, it has to be done manually.
Comment to add? Send me a message: <firstname.lastname@example.org>