update-cosmos: publish download and install progress for the on-screen updater

[kyleinoregon]

What

update-cosmos now writes its state to /run/cosmos-update.status as a single <state>|<percent> line, with state one of downloading, flashing, rebooting, failed, so a UI can show what is happening. The file is written to a temporary name and renamed, so a reader never sees a partial line, and every write ends in || true, so status reporting can never fail the update itself.

Download progress comes from the asset size (curl -sIL and the last Content-Length; GitHub's release CDN answers HEAD with the real size on the final hop, 124226048 bytes for both the stable and nightly asset) against wc -c of the partial file, sampled once a second while curl runs in the background. If the size is unavailable the percentage simply stays at 0 and the download proceeds as before. A curl failure or a flash failure writes failed before exiting non-zero.

The consumer is pellcorp/grumpyscreen#287, which reads exactly this path by default, so no recipe change is needed on the cosmos side.

Behaviour is otherwise identical: same URLs, same flash, same cleanup, same reboot, same exit codes.

Tested

On a Centauri Carbon running 26.08.0 with a grumpyscreen build that reads the file: live percentage through the whole 124 MB download, "Installing" during the flash, then the reboot; the printer came back with its config untouched. /run is tmpfs on this image and /bin/sh is BusyBox ash with 64-bit arithmetic, so bytes * 100 cannot overflow.

[pellcorp]

If this gets merged, I will merge the Grumpyscreen change :-)

[kyleinoregon]

Trimmed this to just the update-cosmos script. The grumpyscreen side (pellcorp/grumpyscreen#287) now defaults to /run/cosmos-update.status, so no recipe change is needed here.

[pellcorp]

I wonder if it might be nicer to change GrumpyScreen to parse stdout and if it sees special messages echoed from the script it shows them rather than a progress dialog, could just be a forever progress dialog like windows other UIs use where it swishes too and fro until the process finishes but you could be displaying progress textually instead.

[suchmememanyskill]

I don't think this is the right way to go. Why do we need this precise update control/status messaging? Any of this won't work for mainsail/fluidd, and i'd prefer to have consistency across all ui's. I'm open to discussion after i'm back from holiday.

[jamesturton]

I agree with Sims that if we are to make more changes to the update system, I would like to see it done in a way to have consistency across UIs.

I think extending moonrakers update_manager api would be the most logical way for this to be done as there is already and existing api interface to be used. However I haven't looked about how much work it would be to implement in moonraker, or whether @pellcorp would consider implementing the moonraker update_manager interface in grumpyscreen.

[kyleinoregon]

That makes sense to me, and it fixes more than the feedback problem. A cosmos updater in update_manager would replace both the check-for-updates prompt and the shell-command path: Mainsail and Fluidd would show the version badge and the live update log in their existing panel, the update would no longer block Klipper's command queue or run under the 500 s shell-command timeout, and the screen would follow whatever pellcorp decides for the update_manager interface.

I've looked at the Moonraker side: it needs a small addition registering a cosmos updater type, which fits alongside the Moonraker patches cosmos already carries, and the existing update-cosmos script plugs in as the update step with its output streamed. If you're open to it I'll prototype that and test it here, and we can close this PR in favour of it.

On the grumpyscreen side, if @pellcorp is open to it I'm happy to take a run at the update_manager client there too (status query, an Update button that calls machine.update.client, and the streamed log in a dialog) and send it as a PR for him to review.

pellcorp/grumpyscreen#286 stays as the standalone fix for the screen freezing on the button press.

[pellcorp]

The update manager in moonraker does not allow you to call a script, the moonraker update_script flag is used purely to parse for dependencies, I assume at some point it did run the script, last time I checked that is no longer the case.

If we are talking about some mutations cosmos made to moonraker to support an update script, this is getting into territory I am less comfortable with.

So I need more information

[pellcorp]

That makes sense to me, and it fixes more than the feedback problem. A cosmos updater in update_manager would replace both the check-for-updates prompt and the shell-command path: Mainsail and Fluidd would show the version badge and the live update log in their existing panel, the update would no longer block Klipper's command queue or run under the 500 s shell-command timeout, and the screen would follow whatever pellcorp decides for the update_manager interface.

I've looked at the Moonraker side: it needs a small addition registering a cosmos updater type, which fits alongside the Moonraker patches cosmos already carries, and the existing update-cosmos script plugs in as the update step with its output streamed. If you're open to it I'll prototype that and test it here, and we can close this PR in favour of it.

On the grumpyscreen side, if @pellcorp is open to it I'm happy to take a run at the update_manager client there too (status query, an Update button that calls machine.update.client, and the streamed log in a dialog) and send it as a PR for him to review.

pellcorp/grumpyscreen#286 stays as the standalone fix for the screen freezing on the button press.

So if the API for update client is stock moonraker and all the custom stuff for cosmos is behind that I am less concerned, but all that code must be gated inside the UPDATE flag because Simple AF does not use the Update button, that is all Cosmos.

But I really don't want to force you guys to fork GrumpyScreen or maintain patches cos that makes things more complicated, so im willing to entertain this :-)

[kyleinoregon]

Closing in favour of #313, which moves the update into Moonraker's update_manager as suggested here, so Mainsail, Fluidd and the screen all show the same thing. Thanks for the pointers.