Debian stretch has the opposite issue: there, rescue only works if no desktop session is active. Otherwise, whether systemctl is run from within that session or not, the console is left completely unusable; not even Ctrl+Alt+Del works.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858162 exists for that, but the Xenial issue is completely different: the console never becomes unresponsive. Instead, the system is stuck in some intermediate state where the normal getty is stlil alive, but login is not allowed, and the actual rescue prompt is never reached. ** Bug watch added: Debian Bug tracker #858162 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858162 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1671991 Title: systemctl rescue leaves system inaccessible unless run from within active desktop session Status in systemd package in Ubuntu: New Bug description: I don't think it's just me, as I'm able to reproduce this on 2 physical systems as well as a vanilla qemu/kvm instance, immediately after fresh installs from both ubuntu-16.04.1-desktop-amd64.iso and ubuntu-16.04.2-desktop-amd64.iso When I run 'sudo init 1' or 'sudo telinit 1' from any virtual console, the system never gets to single-user mode. Instead, I am presented with a non-functioning login prompt and no way to actually interact with the machine except Ctrl-Alt-Del, which luckily still works. The login prompts look normal, but only appear on two virtual consoles: tty1 always, plus the one I was using (if it wasn't tty1). All others are blank. Typing my username results in the message "System is going down," instead of a password prompt. After a couple of minutes, it will clear the screen and draw a fresh prompt, with the same results; otherwise, nothing changes until I give the three- fingered salute to reboot. I've attached a screenshot from the VM. This happens regardless of whether I first log out of my desktop, stop the lightdm service entirely, or neither. The truly bizarre part is that if I enter the command from inside a gnome-terminal running on the desktop, it works as expected. It's a little unbelievable, but seems to be reliably reproduceable. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: init 1.29ubuntu3 ProcVersionSignature: Ubuntu 4.8.0-36.36~16.04.1-generic 4.8.11 Uname: Linux 4.8.0-36-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity Date: Fri Mar 10 22:10:34 2017 InstallationDate: Installed on 2017-03-11 (0 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) SourcePackage: init-system-helpers UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671991/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
