Comment 47 for bug 1913421

I discussed this in realtime with Christian earlier, from an SRU review perspective.

My opinion on what we should do follows. I'd like to be clear though that this isn't necessarily a final decision. If there's a flaw in this plan, please point it out so that we can reconsider. And if there are improvements to be made or aspects we haven't considered, then I'd appreciate feedback explaining that too. But if nobody else objects, then if you implement my description of Option B below then I will accept it on behalf of the SRU team without asking you to change the approach taken again.

Common ground I think we're all generally happy with: 1. The general mechanism to use /run/qemu after a package upgrade to temporarily store executable stuff until the next reboot that qemu will look at to load when required. 2. [Maybe not Dan's preference though, but out of scope for this SRU review] The current state of Debian unstable and Impish: using /run/qemu with a shipped systemd mount unit to mount it noexec.

What I think is in question is what we do for SRUs in Ubuntu. Option A: we add the mount units to the stable releases. An alternative is Option B: Dan's suggestion to just mount /run/qemu manually in the postinst on upgrade.

To expand on Option B, I suggest that it be done with "mkdir -p /run/qemu" and then a test to see if /run/qemu/ is exec (eg. write "#!/bin/sh\nexit 0\n" inside it and see if it will run and exit 0). If the test succeeds, then do nothing. Otherwise, mount /run/qemu -o exec -t tmpfs || true.

Option A has the disadvantage that it might collide with what users might have already done to work around the issue, such as adding their own mount unit, and this may require manual intervention from those users. However, if done this way the result will be clean, discoverable, debuggable using the usual systemd means that administrators are used to, and the same as what is in Debian and in the development release already.

Option B has the advantage that it should automatically fit in with any workarounds users might have implemented already with no intervention required. It's also really minimal, so carries very little regression risk - for example there's no concern about whether debhelper/maintscripts are doing the right thing wrt. upgrade failures, existing mount units, etc. With Option A I'm concerned that there's some corner case in maintainer script handling that might regress existing users. It's harder to ensure that this isn't the case compared to Option B.

Additionally, Option B could write to /run/qemu/README with a quick explanation and link to further details to mitigate the concern that users will not understand what is going on. I suggest keeping this text minimal since it's hard to change in an SRU, and put the details in the link destination (wiki or bug reference or whatever) so that it can be updated as needed.

For an SRU, my current opinion is to favour Option B, because that is most easily verifiable against edge cases. I favour testing for exec by actually trying to exec, because that should also reduce the possibility that the test is wrong somehow.

Option B does mean that the fix in the stable releases will not be the same as in the development release, but this fits in with existing policy that explicitly suggests that this might be appropriate. I think this makes sense in this case.

Feedback appreciated, but if there is none, I think Option B as detailed above is the way forward.