emergency shell ignores all keyboard input

[Marius Gedminas]

An SSD that held my /boot/efi partition failed, took down local-fs.target, which brought up emergency.target. I ended up with no ssh access, and a message on the local console telling me
to press Enter to get a root shell, or press Ctrl-D to continue booting normally. The system did not react to either Enter or Ctrl-D. I could switch between virtual consoles (but nothing was running on them, e.g. no getty), toggle Caps Lock, or reboot with Ctrl+Alt+Del.

An emergency console that doesn't accept keyboard input is not a useful emergency console.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd 237-3ubuntu10.47
ProcVersionSignature: Ubuntu 4.15.0-144.148-generic 4.15.18
Uname: Linux 4.15.0-144-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.24
Architecture: amd64
Date: Mon Jun 7 11:18:39 2021
MachineType: System manufacturer System Product Name
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-144-generic root=/dev/mapper/hostname-root ro
SourcePackage: systemd
UpgradeStatus: Upgraded to bionic on 2019-08-12 (664 days ago)
dmi.bios.date: 08/14/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2204
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: P8Z77-V LX
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2204:bd08/14/2013:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP8Z77-VLX:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

[Marius Gedminas (mgedmin)]

Looking at the journal, I think the sequence of events is:

- SSD fails last Friday
- I log in today over ssh, start messing around
- I notice that collectd is not running (since Friday), try to `sudo systemctl start collectd`
- systemd tries to bring up collectd's dependency local-fs.target, which need /dev/sda1, which is the failed drive
- I figure _that_ out and start editing /etc/fstab to switch the /boot/efi device to the backup on /dev/sdb1
- in the background systemd gives up on local-fs.target and starts emergency.target, which shuts down all the services (including sshd, but not killing my ssh session) and brings up an emergency shell
- I finish editing /etc/fstab and do a `sudo mount /boot/efi; sudo systemctl daemon-reload; sudo systemctl start collectd`
- systemd notices that local-fs.target is all fine actually and stops the emergency shell
- systemd doesn't start all the services that it shut down minutes ago
- I exit my ssh session by mistake

and now we have the situation where the emergency shell is stopped but its startup message remains, confusing users. (And also no systemd services are running, except for collectd, which is not very useful for getting the system back online.)

[Dan Streetman (ddstreet)]

So to summarize:

-your drive failed
-you ssh'ed into the machine and started a service that required the drive
-systemd put the system into emergency target
-you switched to the backup partition and systemd exited the emergency target
-the emergency shell is now inactive, but of course its output text remains on the screen

If that's a correct summary, I'm not sure what you wanted systemd to do differently?

[Marius Gedminas (mgedmin)]

Ideally, I'd wish it not to stop sshd when /boot/efi becomes unavailable. Or at least bring back the services it stopped when the emergency shell is canceled.

More practically, and more on topic to the original reason for this bug report, I'd like it if stopping the emergency shell would print a message on the console, so the instructions to press Enter or Ctrl-D do not appear to still be relevant.

[Launchpad Janitor (janitor)]

[Expired for systemd (Ubuntu) because there has been no activity for 60 days.]