On Fri, Feb 26, 2021 at 5:12 PM Chris Murphy <lists(a)colorremedies.com> wrote:
On Fri, Feb 26, 2021 at 1:36 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> Well, we'd want nspawn to work properly since Mock uses it by default...
OK so this regression is likely already affecting desktop users who do
local mock builds? Or is it somehow only affecting Server edition?
Eventually the problem is going to end up in Fedora infrastrastructure
if it doesn't get fixed, correct? So it needs to be fixed no matter
what.
Answering a bit of my own questions...
This method of starting does not work:
systemctl start systemd-nspawn@{containername}
This method of starting does work:
systemd-nspawn -b -D /var/lib/machines/{containername}
Mock is probably using the latter. It's a guess, but I'd expect that
if the 'systemctl start' method fails, that 'systemctl enable' and
subsequent boot->startup or .timer unit triggering would also fail.
Therefore a release criterion would need to be written to cover both
cases, and make it clear that the required functionality is the
mechanism (the manager) must be capable of starting containers; not
that arbitrary containers must also work. We can't be blocking on
arbitrary containers. But we might be able to block on the container
manager not being able (or allowed) to start any container.
--
Chris Murphy