Oleksandr ShyshatskyiandClaude Opus 5
56b5b6c334
`make rootfs` unsquashed rootfs.squashfs out of the stock package into
work/rootfs, and a thin container bind-mounted it with PROG_DUMP supplying
/usr/prog from the factory image. Every caller set PRINTER_IMAGE anyway --
both workflows wrote it into test.env BEFORE running `make rootfs`, so CI
unpacked a 93MB package, unsquashed a rootfs and downloaded a 182MB factory
image on every push and read none of it. build-printer-image.sh never used
work/rootfs either: Dockerfile.full does its own extraction from the same
public firmware and needs no stock package at all.
So the fallback went, and PROG_DUMP with it -- it was only ever read when the
replica was built locally, and both implementations already passed it empty
otherwise. Gone: the target, extract-rootfs.py, gates.extract_rootfs and its
two tar helpers, the thin printer/Dockerfile, the `prebuilt` flag threaded
through both Replica implementations, and Replica.start's want_output, whose
only message was that the local build was about to be slow.
PRINTER_IMAGE is pinned to 1.9.7-1.2.9-20260810 rather than :latest. It is
now the entire substrate the brick-safety gates run on and the only input
nothing checksums, so a floating tag would let it change under a green suite
-- the drift the sha256 pins in both workflows exist to prevent.
THREE THINGS THAT COULD NOT HAVE PASSED, found while doing it:
* Neither workflow built the feed. bin/patch.sh has refused to start
without one since a1b4ea6, 45 commits after ci.yml was last touched.
Both ran unpack/patch/pack straight into that guard.
* `make release` ran bin/build.sh on $(RUN), which has no docker socket,
while patch.sh assembles the payload inside the replica. `build` has
used RUNBUILD all along; `release` was left behind. It also built no
feed. It now builds one, once, outside the per-model loop -- nothing in
it is model-specific.
* ci.yml's shellcheck gate named pkgs/*/payload/init.d/S* and
pkgs/*/prog/*.sh, neither of which exists any more; shellcheck exits 2
on a path it cannot open. It is a `find` with an asserted count now,
because the opposite failure is worse: a glob that quietly matches
nothing checks nothing and still reports green.
Both workflows now go through `make` instead of hand-rolling `docker run`.
Hand-rolling meant CI exercised entry points no human uses, which is exactly
why the `release` runner bug could sit there unseen; it also ran as root and
left a work/ that the later `make release` could not write to.
ci.yml's test job builds the feed before the static lane. A good part of that
lane asks what is inside an .ipk and those questions do not fail without one
-- they return, and the lane reports a pass having never opened a package.
build-packages.sh needs no stock firmware, which is what makes that possible.
Docs, and the packages skill, which still documented pkg_buildopkg and
work/.opkg-host as how the payload is assembled -- the host opkg went in
dcd037c and the printer's own installs the feed now -- and still claimed
qa/static holds an ABI gate over every ELF in every package. It does not:
qa/replica/test_abi.py is the only one, and qa/static asserts a seventh does
not grow back.
Verified: qa/static is 122 passed / 110 errors here, identical to master --
every error is `vendor/opkg-utils is missing` in a checkout that has not run
`make vendor`. mkdocs build --strict passes. The new shellcheck gate was run
as written. The workflows themselves were not executed.
tools/replica/printer/*.sh live inside the published image, so those edits
take effect on the next `make printer-image`; behaviour is unchanged either
way, because nothing sets PROG_DUMP any more.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TrhjKabxDihvVjNQGGT4MK
4.6 KiB
Hardware testing
CI installs the package into a replica of the printer -- the real
rootfs.squashfs running under qemu-mipsel, on the printer's own busybox and
unTar (see printer-replica.md) -- and proves the
machine would still boot. What it cannot do is drive the screen, the MCUs, the
toolchanger or a print. This is the on-hardware procedure.
There is one flash: the firmware package for your model.
Rule: have the stock FlashForge package for your model on a spare stick before you flash anything. Flashing it back is the uninstall, and it is the only recovery step that needs nothing but a USB port — no ssh, no screen.
It used to be proven by make test-recovery, which installed the mod into the
replica and flashed the stock package over it. That gate has been retired
and nothing has replaced it yet — see
qa-migration.md. It passed on its last run, but treat the
rollback as unverified against the current build.
Step zero: check the model gate
Every package carries a gate. Its runFirmwareExe.sh has MACHINE= / PID=
baked in, and compares them against the values app_startup.sh passes from
the firmware already on the printer. A mismatch is refused with
"Firmware does not match machine type" — it will not install, and it is not a
valid recovery image either.
| Model | MACHINE | PID |
|---|---|---|
| Creator 5 | Creator5 |
0028 |
| Creator 5 Pro | Creator5Pro |
0029 |
The gate is not cosmetic: the two models ship different firmwareExe
binaries, so a package must be built from the stock package for its own
model. make release builds both.
Find yours in Settings → About, or in
/usr/data/firmwareRes/config/general.json (machineName), and set
TARGET_MACHINE in config.env. Then:
make build # one model
make release # both, into dist/
You must start from a stock package built for your own model — the mod
inherits the gate from whatever package you unpack, so a package built from
the wrong stock file carries the wrong gate and your printer will refuse it
with "Firmware does not match machine type". Nothing on the build host warns
you first; make qa-replica catches it by installing the package the way the
printer does.
Before the first flash
- Put a copy of the stock FlashForge package for your model on a spare USB stick and keep it physically separate. That is your recovery image: flashing it restores every file the mod touches. Check it is the right model first — see above.
- Note your printer's serial number (Settings → About). The factory image restores a placeholder serial and you may need to put yours back.
- Confirm you can reach the printer's IP.
make qapasses.make qa-replicapasses — needsPRINTER_IMAGEintest.envand a package frommake build; this parses every script that will run on the printer using the printer's own busybox ash.
Two USB sticks, FAT32, both packages at the root of the stick (not in a
folder). Ship both filenames (Creator5-* and Creator5Pro-*): the Pro's
boot script globs Creator5Pro-*.tgz, the non-Pro globs Creator5-*.tgz.
The flash
One flash brings up everything: a root password you know, Mainsail and moonraker, the forked Klipper with the toolchanger extras, and HelixScreen on the touchscreen in place of FlashForge's UI.
From here the procedure is the one an owner follows, and it is written for them rather than repeated here:
| Installing | the flash itself, the first boot, the root password |
| Your first print | the go/no-go checks, calibration, and the two files under gcode/ |
| Support | the logs, and the way back to stock |
What follows is the part that is ours rather than theirs: keeping those two verification files honest as the macros change.
Keeping the verification files honest
Nothing checks them automatically any more. make test-py used to: every
command in them had to be one the mod's Klipper config or
pkgs/klipper/payload/klipper/klippy/extras/ defines (bar an explicit
allowlist of Klipper built-ins, currently just SET_PRESSURE_ADVANCE),
TOOLS= had to list every tool the feature print uses, and the safe file's own
lines had to stay cold and above Z50. That check went with the test/ tree.
So a renamed macro now breaks the print rather than the suite. If you rename or
remove a macro, read gcode/creator5-safe-moves.gcode and
gcode/creator5-feature-test.gcode before you ship it.