mirror of
https://github.com/Ayymoss/Plutainer
synced 2026-08-24 14:32:06 -04:00
99c33be701
A clean volume with auto-update at its default fetches
r2.ezz.lol/boiii/boiii.exe and produces a container that is Up, silent and
useless. That build has two independent faults, both fixed in the client's
source and neither in the artifact being served:
* the launcher-UI check runs before the client/server split, so a server
fails a check for a file only a client downloads and exits rc=1 blaming
the network, which is not the cause.
* the headless console calls AllocConsole() at static-init. Under Wine with
no display that starts conhost.exe and the process blocks on its pipe:
one thread, 0% CPU, 36MB RSS, wchan pipe_read, no UDP socket, and nothing
in `docker logs` for the container's whole lifetime.
The obvious workaround does not work. The first check is a bare file_exists
on %LOCALAPPDATA%/boiii/data/launcher/main.html, so an empty stub clears it -
verified - and the run then lands on the console hang, which no file can
satisfy.
The second fault is why this refuses rather than warns. A warning would be
followed by exactly the silent container described above, which is the least
debuggable thing this image can produce; hold_indefinitely at least says why.
Pinned by the sha256 of the known-BAD artifact rather than of a known-good
one, so the day anything else is published the check stops firing on its own
and no release of this image is needed to unblock it.
Measured both directions on 10.10.1.22: published binary on a clean volume
refuses with the explanation and holds, restarts=0; a build carrying both
fixes is untouched by the check and reaches healthy, hosting zm_tomb. Also
fills the "No cod_validate_* hook for: boiii" warning, which was real.
|
||
|---|---|---|
| .. | ||
| cod.sh | ||
| core.sh | ||
| fs.sh | ||
| steam.sh | ||