Mount a dedicated tmpfs on /run/initramfs instead of trying to remount /run with...
commit290620df4d1992598e45deda015ec85518c89ed6
authorintrigeri <intrigeri@boum.org>
Thu, 10 Jan 2019 21:57:31 +0000 (10 21:57 +0000)
committerintrigeri <intrigeri@boum.org>
Sat, 12 Jan 2019 20:02:53 +0000 (12 20:02 +0000)
tree3b8e7ad80d6f9983f75869d8527fe107889c100b
parent634e5a6d20fa9236c1cf67e76f7879287c2e6bdf
Mount a dedicated tmpfs on /run/initramfs instead of trying to remount /run with the "exec" option (refs: #16097).

My previous approach, i.e. "let's remount /run with the exec option via a unit
file started as part of the shutdown procedure", worked just fine for clean
shutdown. But it does not work for emergency shutdown, i.e. when the boot medium
is physically removed: for some reason (possibly missing bits in the memlockd
configuration), this service is not started, and then systemd-shutdown won't
return to the initramfs because /run/initramfs/shutdown is not executable.

So let's instead disregard /run and extract the initramfs into a dedicated
tmpfs, that we mount on /run/initramfs (where systemd-shutdown will look for
it), and that we mount without the "noexec" option.

Also, remove manual calls to eject(1):

 - They increase chances that the shutdown process breaks due to missing
   files locked in memory by memlockd.

 - Their sole benefit is to ensure we physically eject the DVD. It's unclear if
   this code is still needed nowadays. Regardless, starting with Tails 3.12, the
   only supported use case for ISO and DVD is virtual machines, which are not
   targeted by the emergency shutdown feature, which is about removing the
   *physical* boot medium.
config/chroot_local-hooks/52-update-rc.d
config/chroot_local-includes/lib/systemd/system/run-initramfs.mount [new file with mode: 0644]
config/chroot_local-includes/lib/systemd/system/tails-remount-run-exec.service [deleted file]
config/chroot_local-includes/usr/local/lib/udev-watchdog-wrapper
wiki/src/contribute/design/memory_erasure.mdwn