Selecting "Rescue" shell from the "Advanced options" menu in grub enters the "friendly-recovery" service and allows to drop into a root shell. After ~120 seconds, systemd sees a timeout and starts another "friendly-recovery" whiptail process. This and the running shell now compete for tty access (input and output) thus making the shell nearly unusable.
Diagnosing this, it becomes clear that in the first root shell entered from friendly-recovery, "systemctl list-jobs" lists the generated "wait for disk" tasks for the /boot partition and the swap partition still to be running. Only when they run into a timeout, the next friendly-recovery is spawned. I'll attach a log session for such a boot that has two manual "logger" entries in it:
Feb 06 10:54:57 harry root[605]: now in root shell from friendly-recovery
...
Feb 06 10:56:41 harry root[1254]: now running in parallel
This clearly shows the timing of the startup.
I have no idea why the "wait for disk" units run into a timeout as the system boots correctly in the "non-rescue" mode. I'll further attach a "systemd-analyze blame" from a regular bootup to show that there is no trace of such a timeout to be found.
Furthermore i do have this behaviour on a real machine and on an (independent) VM, so affects more than the machine the bug was reported from.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: systemd 229-4ubuntu16
ProcVersionSignature: Ubuntu 4.4.0-62.83-generic 4.4.40
Uname: Linux 4.4.0-62-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Feb 6 11:02:37 2017
InstallationDate: Installed on 2015-03-27 (681 days ago)
InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1)
MachineType: Hewlett-Packard HP EliteBook 8460p
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-62-generic root=UUID=310be2be-96ea-4fe9-b929-75605e718fdc ro resume=/dev/sda6 loop.max_part=63 quiet splash vt.handoff=7
SourcePackage: systemd
SystemdDelta:
[EXTENDED] /etc/systemd/system/display-manager.service → /lib/systemd/system/display-manager.service.d/xdiagnose.conf
[EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf
[EXTENDED] /lib/systemd/system/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
3 overridden configuration files found.
UpgradeStatus: Upgraded to xenial on 2016-12-01 (66 days ago)
dmi.bios.date: 12/22/2011
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68SCF Ver. F.22
dmi.board.name: 161C
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 97.4A
dmi.chassis.asset.tag: 617H
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr68SCFVer.F.22:bd12/22/2011:svnHewlett-Packard:pnHPEliteBook8460p:pvrA0001D02:rvnHewlett-Packard:rn161C:rvrKBCVersion97.4A:cvnHewlett-Packard:ct10:cvr:
dmi.product.name: HP EliteBook 8460p
dmi.product.version: A0001D02
dmi.sys.vendor: Hewlett-Packard
Although I couldn't reproduce it in a VM, this reliably happens on both of my hardware installs, an old Thinkpad and an Asus Z87-based desktop. The recovery shell is completely unusable. Luckily Ctrl+Alt+Del still reboots the system cleanly.
The workaround seems to be to boot directly to the systemd rescue (or emergency) target, instead of recovery. This can be done simply by adding "rescue" or "emergency" to the default linux command line.