The underlying issue we are experiencing is that our DUTs in the CrOS test lab are accessing the prod Omaha server, downloading and installing an mp-signed image, and then becoming untestable (since test lab requires dev-signed test images). This is possible for all CrOS devices in theory, but is only observed on our device (veyron_rialto) because it reaches the OOBE Update Screen without waiting for user input. All other devices will reach the OOBE Welcome Screen and not progress any further without user input. This is due to our use of Hands-Off Zero Touch Enrollment, a feature which will be used by other Chrome OS devices in the future.

When reaching the OOBE Update Screen, the Chrome Browser contacts the Update Engine over DBUS and asks it to check for an update, and if an update is present, to download it. The Chrome Browser does not specify an Omaha URL, so the Update Engine uses the default, https://tools.google.com/service/update2, which is the production server.

I am proposing that on test images, we use a different default, such as localhost:8080/update. This way, mp-signed images will not be affected and will continue working as normal. On test images, developers can still access the prod Omaha server by specifying the Omaha URL when making the dbus call to Update Engine. It is just that the default will no longer be the prod Omaha server.

What are your thoughts? Of course, we are open to other solutions as well.