Preconfig Doctor
Read a failed setup, name the cause, fix the spec
Pick a failure recorded on a clean Ubuntu 24.04 machine, or paste a log of your own: the output of preconfig verify, the setup script, a Docker build or a GitHub Actions job. Doctor finds the step that broke and the lines that show why, and when the fix belongs in preconfig.yaml, it writes the change and rebuilds every platform's file. It all runs in this page.
Starting the engine...
preconfig.yaml the setup was built from (optional; Doctor fills in values from it)
0
lines in the log
0
lines that show the cause
none yet
where the fix belongs
The fix, in preconfig.yaml
Pick a recorded failure above, or paste a log and press Diagnose.
preconfig.yaml
The files build rewrites
How Doctor decides
Rules, and no guessing
- Doctor reads the log's step markers to find the step that failed, then tries its rules on that step's lines, the most specific first: a blocked download before a missing package, a missing package before a failed test.
- Each rule was written for a real kind of failure. When none fits, Doctor says it doesn't know and shows the lines that look like errors. It never changes the spec on a guess.
- Only causes that live in the spec come with a change. A blocked network, a stale lockfile, an unset secret or a test that fails on the code get an explanation and where to fix it instead.
What is real here
- Every recorded log above is what the machine printed during a real run of
preconfig verify, or a real Docker build, on the test machine on . Eight of the nine failures were made on purpose, and the ninth comes from the test machine's network; each has a known cause. - The diagnosis and the rebuilt files come from the engine's own Go code, compiled to WebAssembly for this page. A test compares every answer with the command line's.
- Where a fix says it was proven, the changed spec was run again on a clean machine, and the result shown is that run's.