Toolkit: Use systemd-detect-virt instead of /.dockerenv to detect container builds.

[dmcilvaney]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./LICENSES-AND-NOTICES/SPECS/data/licenses.json, ./LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md, ./LICENSES-AND-NOTICES/SPECS/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

There have been several issues with a mismatch between the build environment and the detected state by the toolkit. When running in docker, the chroots generally need to be configured externally with their mounts and re-used. This can be done via setting CHROOT_DIR=/path/to/reusable/chroots, and if the toolkit thinks it's in a container, it will switch modes.

See https://github.com/microsoft/azurelinux-tutorials/tree/main/build-in-container for more details.

Some builds are currently failing because what is ostensibly a container environment does not have /.dockerenv present.

In the opposite direction, there are also situations where WSL images (which should work fine as a normal build) are reporting as docker because they have a /.dockerenv file present.

systemd has a tool (systemd-detect-virt) which is designed to detect what sort of virtualization is being used to run the current environment. Instead of designing a new system to re-implement this behavior, we can just use this tool. We already have an implicit build dependency on systemd (we run the docker service etc.) so adding it as an explicit requirement shouldn't change anything.

Also, to help people self-diagnose, sanity check the configurations and warn the user:

• If the CHROOT_DIR is set, but the tool thinks it's in a normal environment, print a warning. A fatal error will follow immediately after if this is actually broken.
• If the systemd-detect-virt tool is not present, print a warning but fallback to the old behavior.

To validate this we will need to add a new testcase to the toolkit sanity test pipeline that ensures the chroots keep working.

We will need to back-port this to 2.0 as well.

Change Log

• Prefer systemd-detect-virt over /.dockerenv for container detection
• Print warnings if misconfiguration is detected

Does this affect the toolchain?

NO

Associated issues

• https://microsoft.visualstudio.com/OS/_workitems/edit/55008881
• https://microsoft.visualstudio.com/OS/_workitems/edit/54578711

Test Methodology

• New sanity test (pipeline PR soon): https://dev.azure.com/mariner-org/mariner/_build/results?buildId=675755&view=results
  • PR for new pipeline: https://dev.azure.com/mariner-org/mariner/_git/CBL-Mariner-Pipelines/pullrequest/21071
• Full build: https://dev.azure.com/mariner-org/mariner/_build/results?buildId=676056&view=results

[dmcilvaney]

Pipe line to validate this keeps working: https://dev.azure.com/mariner-org/mariner/_git/CBL-Mariner-Pipelines/pullrequest/21071

[jslobodzian]

Note sure what "PrintMessageBox" is doing, but it seems to me the code would be a little simpler here if we just emitted the "Failed to detect" message before we call "checkIfContainerDockerEnvFile" first, then composed the result

[dmcilvaney]

PrintMessageBox is a really obvious warning to the user with big borders. I try to add these when I think there is a non-obvious thing that the user should fix that might cause confusing errors later. I think I see what you mean with the ordering though, I'll give it a go.