Bug #16787

Trigger emergency shutdown on resume when the boot device is missing

Added by intrigeri 2019-06-07 10:43:22 . Updated 2020-05-09 11:52:33 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

i.e. it was removed during suspend. The idea is that when suspended, both sequences of user actions should result in emergency shutdown:

  • wake up the system, then unplug the boot device: this works
  • unplug the boot device, then wake up the system: this used to work but the fix for Bug #11729 broke it as a side effect (commit:e4e7f81288ff9723b94ec434bbc7006ce240cb0f)

See Bug #11052#note-31 and follow-ups.

Files

diff (605 B) intrigeri, 2020-05-08 18:31:15

Subtasks

Related issues

Related to Tails - Bug #11052: Do not suspend when closing lid Rejected 2016-05-03
Related to Tails - Bug #11729: Emergency shutdown triggered after resuming from suspend Resolved 2016-08-26
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by intrigeri 2019-06-07 10:43:58

#2 Updated by intrigeri 2019-06-07 10:44:08

  • related to Bug #11052: Do not suspend when closing lid added

#3 Updated by intrigeri 2019-06-07 10:44:12

  • related to Bug #11729: Emergency shutdown triggered after resuming from suspend added

#4 Updated by intrigeri 2020-05-04 14:19:04

  • Description updated

#5 Updated by intrigeri 2020-05-08 15:04:50

We worked on this today with anonym, boyska, and kibi; here’s the output.

The problem is caused by commit e4e7f8, which disables the systemd tails-shutdown-on-media-removal.service just before systemd, and restarts it after suspend. This means that the udev-watchdog misses all the events occurred during suspend.

A simple solution is modifying udev-watchdog-wrapper to immediately stop (without even running the udev-watchdog) if the boot device does not exist when starting the service

Code is [link to somewhere or some git ref]

If you want to simulate it in virsh, you need to do this
in the guest:
systemctl stop tails-shutdown-on-media-removal.service

On the host:

1. grab the relevant section of `virsh dumpxml $DOMAIN` and paste it into /path/to/drive.xml
2. virsh detach-device $DOMAIN /path/to/drive.xml

On the guest:
systemctl start tails-shutdown-on-media-removal.service

#6 Updated by intrigeri 2020-05-08 18:31:15

Thanks again @boyska :)

> Code is [link to somewhere or some git ref]

Here it is, attached.

One limitation of this proposed fix is that it only works for USB sticks: if the user started from a DVD, $BOOT_DEVICE represents the DVD reader, whose block device will still be present regardless of whether the DVD was ejected while the system was suspended. IIRC our tentative conclusion was that it’s no big deal, under a reasoning that looked like this:

  • Nowadays we only support starting Tails from the ISO-as-a-virtual-DVD in a VM — we don’t advertise booting from DVD on bare metal anymore. Even if a user puts a VM to sleep (from the perspective of the guest OS, not as in pausing the QEMU process or suspending it via virt-manager), then ejects the DVD, they probably don’t expect anything particular to happen on resume.
  • Even if someone starts Tails from a DVD on bare metal, it was not clear to us that it’s possible, while the system is in suspend-to-RAM, to eject the DVD. So it could be that the problem this issue is about is simply not applicable in this case. Either way, it’s an unsupported corner case.

Next steps could be along these lines:

  1. Test suspend/unplug/resume on bare metal to ensure it works as expected: emergency shutdown is triggered on resume.
  2. Test suspend/resume on bare metal to ensure it works as expected: emergency shutdown is not triggered on resume.
  3. Run our test suite on a branch with this patch applied, to see if it breaks anything.

#7 Updated by anonym 2020-05-09 11:52:33

intrigeri wrote:
> One limitation of this proposed fix is that it only works for USB sticks: if the user started from a DVD, $BOOT_DEVICE represents the DVD reader, whose block device will still be present regardless of whether the DVD was ejected while the system was suspended.

So blkid /dev/cdrom outputs something non-empty if and only if a disc is present, so it could be that the check we need for “is the CD/DVD drive empty?” is just: test -z "$(blkid ${BOOT_DEVICE})"

I have no idea if this is robust when the media is removed while suspended.