Strange. It looks like Zircon is trying to start the autorun in that log:

[00002.229] 01044.01398> devmgr: zircon.autorun.system: starting '/boot/bin/sh' '/system/cr_autorun'...

I don't think that does a network wait (?) so the first thing it should be doing is sleeping and then trying to mount the output drive. I'm guess that's failing (?) and so the autorun script is terminating before it even gets to the "Executing..." echo. But it's strange that there's no error output.

I guess we could add a few more echos in the autorun to try to see how far it does make it, if anywhere.

I wonder if we can have also have the host sanity-check that the output
volume was ever mounted?

I'm not sure that the image would necessarily be modified to detect that? Or did you mean sending some sort of a signal somehow?

"minfs: failed to stat ::/output.json" almost tells us that since the test launcher opens the output file pretty early on... but I guess we don't if the mount failed or if the binary failed to launch for some reason. Hmm.

I guess all we really know is that it isn't getting as far as https://cs.chromium.org/chromium/src/build/fuchsia/runner_common.py?rcl=2922c9017fcd63c0a738fff449731b05f9f66419&l=306 so it's something in the setup junk before that, and before the actual test binary is involved.

This bug might become obsolete with  crbug.com/799309 .

I'm Pretty Good with the ignore-it-until-it's-obsolete bug triage tactic!

scottmg: Some filesystems write a timestamp or other marker whenever they
are mounted read/write, is what I had in mind. The other, possibly simpler,
check would be whether the disk image file has a modified time later than
the creation time, perhaps?

kmarshall: Possibly - maybe marked this as blocked-on  issue 799309  so we
remember to review & close out if we think it resolves this too?

SG, now blocking on 799309.