[XiaoBinGan]

Problem and result

A host whose Docker predates 20.10 starts the image and gets:

[X] The engine in this image does not match this computer's graphics card, or the card is not visible to the container.
    strata: no usable Python found.

The card, the driver, the toolkit and the image flavour are all fine. That daemon's default seccomp profile
denies access(X_OK), so the launcher's "is this Python executable?" test answers no for the bundled
runtime — which is present and runs. docs/DOCKER.md already has a troubleshooting entry that begins with
exactly that first sentence and sends the reader to the card, the toolkit and the image flavour, so a reader
with this cause is sent the wrong way and nothing in the document mentions seccomp.

After this change the section names the case, gives three commands that tell the two apart inside the image
(nothing is downloaded), says what the combination means, and gives the one-option fix with its compose
spelling.

Related discussion: #4309 (the report) and #4312 (the launcher and the entrypoint no longer depend on that
test). Those are code; this is the document a reader on a released image reaches, where the bug is still
present.

Approach

One entry in Troubleshooting, placed directly after the card-mismatch entry so the two are read together.
It does not restate the existing entry and does not change any other section.

Validation

Passed: the three commands exactly as written, against the image the document names
(ghcr.nju.edu.cn/niko1221/strata:0.2.2-cuda13, mirror of ghcr.io), on the host that shows the bug
(Docker 19.03.15, default seccomp):

1) denied
2) present
3) Python 3.12.15

Passed: the documented fix, the same container with --security-opt seccomp=unconfined, prints
strata 0.2.2 (build 0.1.47; python 3.12.15 at /opt/strata/terminal/python/bin/python3). Without the option
the same command prints the two lines quoted above.

Passed: the file keeps the document's style (bold symptom first, then cause, then a command block) and its
Markdown: the new block is inside ## Troubleshooting, uses fences that match the neighbouring entries, and
the file's line endings stay LF, as the repository stores it.

Failed: none.

Not run: docs/DOCKER.md's own checks: the repository has no link checker I could run locally for this
page. The entry adds no link, only inline commands and one issue/PR reference that both exist. I did not
build an image or run the compose file, because the change is prose only.

Limits

• This documents the symptom, not a code change: an image that still carries the old launcher keeps needing
  the option until it is built from [TUI] launcher: start the bundled runtime when access(X_OK) is denied (Docker's default seccomp profile) #4312.
• The three commands pin the image name in the prose (IMAGE) rather than repeating a version, so they stay
  valid for any image; the measured version is named in the text.

[XiaoBinGan]

The entry now names 0.2.7-cuda13 as well, because that is the current image and I could measure it (it appeared after 0.2.7 shipped — 0.2.7-cuda13 and 0.2.7-rocm-gfx120x are the two new tags). Same host, same Docker 19.03.15, default seccomp profile:

$ docker run --rm --entrypoint /opt/strata/terminal/bin/strata ghcr.nju.edu.cn/niko1221/strata:0.2.7-cuda13 --version
  * Reinstall the distribution, which restores the bundled runtime, or      ← the launcher gave up
  * set STRATA_PYTHON=/path/to/python3 (3.10 or newer), or
  * install Python 3.10+ and run this launcher again.

$ docker run --rm --security-opt seccomp=unconfined --entrypoint /opt/strata/terminal/bin/strata ...:0.2.7-cuda13 --version
strata 0.2.7 (build 0.1.52; python 3.12.15 at /opt/strata/terminal/bin/python3)

$ the three commands the entry gives, on the same image
denied
present
Python 3.12.15

So the symptom, the three diagnostics and the fix all reproduce on the current release, not only on 0.2.2-cuda13. The entry says both versions now, with the version line the fixed run prints on 0.2.7.

Also worth knowing for the same sentence: the latest-* tags are still the old ones. latest-cuda13 pulls an image that prints strata 0.2.3 (build 0.1.48; ...) even though 0.2.7-cuda13 exists, so a reader who follows a latest command in the README gets 0.2.3 — which is exactly the state this entry describes and why it is worth having.

[XiaoBinGan]

Correction to my comment above: 0.2.7 published all six variants, not two, and the latest-* tags were moved to 0.2.7 as well. My earlier statement came from a tag listing truncated at the first page and from a cached local image, and both were wrong. Walked to the end:

0.2.7-cuda12  0.2.7-cuda13  0.2.7-rocm-gfx110x  0.2.7-rocm-gfx1151  0.2.7-rocm-gfx120x  0.2.7-sycl
latest-cuda12 latest-cuda13 latest-rocm-gfx110x latest-rocm-gfx1151 latest-rocm-gfx120x latest-sycl

$ docker pull .../strata:latest-cuda13 && docker run ... --version → strata 0.2.7 (build 0.1.52; ...)
$ docker pull .../strata:latest-sycl   && docker run ... --version → strata 0.2.7 (build 0.1.52; ...)

So a reader following the README's latest commands gets 0.2.7 today.

What is unchanged and is the reason this entry still helps: the 0.2.7 image still stops at no usable Python found on an older daemon's default seccomp profile, exactly as this entry describes, and --security-opt seccomp=unconfined still fixes it. What I measured on 0.2.7-cuda13 stands; only the "two new tags" and "latest is stale" sentences were wrong.