Oleksandr ShyshatskyiandClaude Opus 5
fae26a85e5
The software component existed to give the mod one exec hook. It is not needed for that any more, so a release now carries our installer and our payload and nothing else: 26MB smaller, 21MB of which was FlashForge's own firmwareExe travelling back to the partition it was already on, along with their klippy tree, their wifi module and their configs. WHAT IT GIVES BACK. /usr/prog/PROGRAM/software is no longer rewritten, so the version directory there stays FlashForge's with their genuine firmwareExe inside it -- and app_startup.sh's five-second watchdog, which copies one out of that directory when nothing by that name is running, has something to copy again. A printer whose payload fails to install now comes up on the stock UI instead of a blank screen. That recovery has been broken since we started deleting their binary out of a component we shipped; docs/how-it-works.md claimed it worked throughout. THE ROOT PASSWORD moves with it, because it used to ride in the component's shadow file. bin/pack.sh bakes ROOT_PW_HASH into the installer, single-quoted -- an unquoted $6$... would have the printer's shell expand $6 as a positional parameter and ship a truncated hash -- and the installer writes it to /usr/prog/etc/shadow. The random-password path asks one question instead of four: FlashForge ship the same root hash on every machine, so a live shadow still carrying it means nobody has set a password and it is ours to set. The .prev-root-hash recording, the shipped-vs-live comparison and the restore-it- afterwards step were all machinery for surviving a file that nothing overwrites any more, and are gone. pack.sh checks the hardcoded constant against the stock package it built from, because getting it wrong is silent and total: every printer would read as "already set" and none would ever get a password. bin/patch.sh is bin/payload.sh. It patched nothing any more -- no splice, no shadow edit, no firmwareExe deletion -- and what is left is the payload: the feed installed by the printer's own opkg, the seeded config, the manifest. Its sections are renumbered 1-5 with no gaps, and the five tombstone comments marking where removed sections used to be are gone with them. test_recipe_layout.py loses six of its nine tests. Each compared the tree against a description of the tree -- no fourth directory kind, each kind still used, 3rdparty carries no files of ours, installer/ holds exactly two named files -- and none could go red for a reason a printer would notice, while all six went red the moment the layout legitimately changed. The two that bite are kept: a payload/ path escaping $MODDIR, and a recipe name at both levels, which makes pkg_dir silently build the wrong package. SW_VER is deleted from config.env.example and both workflows: it stamped a component that is not built. Gates: 112 static tests pass. The generated installer is verified after substitution -- all four lines present, and `sh -n` over the result, because a hash with a stray character in it would otherwise reach a printer as a syntax error whose only symptom is a package that installs nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CH7Yb4wuPhnppHAB25UX7e
3.7 KiB
Upgrading, and your files
A newer release installs exactly like the first flash: stick in, power on. Nothing you have set is asked for again. This page is the line between the files that are yours and the files the mod overwrites without asking, because that line is what makes an update safe.
Your files and the mod's files
| File | Whose |
|---|---|
/usr/data/config/printer.cfg |
Yours — never overwritten. Overrides go here, after the includes: restate only what you change, the last value wins. |
moonraker-custom.conf |
Yours — created once, never rewritten, included last so your settings win. Do not delete it. |
ff-*.cfg, printer.base.cfg, moonraker.conf |
The mod's — overwritten on every update; do not edit. |
anvil/helixscreen/config/settings.json |
Yours — everything you set on the screen. Written by HelixScreen itself; carried across updates along with helixscreen.env and its spool map. |
Upgrading
A newer release installs exactly like the first flash: stick in, power on.
Your printer.cfg with its saved calibration, moonraker-custom.conf, your
root password and everything you set on the screen survive; the ff-*.cfg
family is replaced. If a release changes helixscreen.env, yours is kept and
the new one is left beside it as helixscreen.env.mod-new.
The config files in detail
The .cfg includes are wired up for you: printer.base.cfg ends with
the seven [include ff-*.cfg] lines, so a flash brings the mod up by itself.
Your printer.cfg is not touched. The factory dock and nozzle numbers are
pulled in for you too: on the first boot after the flash, [ff_legacy] imports
firmwareExe's per-unit JSON and persists it with its own SAVE_CONFIG, so
Klipper restarts once, right after coming up — before the screen is on its
feet. TOOL_OFFSET_STATUS afterwards should show a nozzle triple for every
tool and no NOT CALIBRATED.
The included files are the mod's, and every update overwrites them without
asking — ff-*.cfg and printer.base.cfg alike. Do not edit them. Put changes
at the end of printer.cfg, restating only the option or macro you are
changing: Klipper merges same-named sections and the last value wins, so
everything you leave out keeps the shipped value and your overrides survive
every flash. Each of those files opens with a header saying as much.
moonraker.conf is mod-owned too — it is overwritten on every update, which
is how the [webcam] block and the API lockdown reach the printer. Its seam is
moonraker-custom.conf beside it: created once, never written again, and
included at the end of moonraker.conf, so anything you set there wins.
Do not delete it — Moonraker treats an include that matches no file as fatal
and will refuse to start. An empty one is fine.
If you edit moonraker.conf itself anyway, the installer notices and keeps
your copy, landing the new version beside it as .mod-new.
A FlashForge OTA update is a different thing
Everything the mod installs is under /usr/data/anvil on the data partition,
the klippy tree and its extras included, so an OTA cannot delete them. What it
does rewrite is /usr/prog, and with it the firmwareExe the mod boots
from — so re-flash the mod after a firmware update. The #*# block in
printer.cfg survives either way.
Going back to stock
Flashing the stock FlashForge package for your model is the uninstall — it installs the same way, and it restores every file the mod touches. The one thing it cannot bring back is FlashForge's Moonraker, which the stock package does not carry: the mod's build stays, it works, and Mainsail is happy with it. The details, and the ladder below it, are in Support.