Raspbian trixie - #1106
Raspbian trixie#1106SteveMicroNova wants to merge 57 commits into
Conversation
…ure.py to better handle installs from point 0 as well as better handle updates with this new OS
Update check_pass to explicitly use python 3.8 instead of python 3.13 add with_alsa flag to configure.py to optionally forcefully override
…k in configure script
…ports that don't work
…e point when activating linger for pi user
Add "dep filter" repeatable flag for the deploy script for rapid iteration while working on specific dependency install steps
Update NEW_RELEASE.md with a personal reminder
Update check_pass to explicitly use python 3.8 instead of python 3.13 add with_alsa flag to configure.py to optionally forcefully override
Fix alsa option in deploy script
…py with optional verbose logging during the debian upgrade portion
…ions and saving the file properly
Fix asgi.py image consumption endpoint to only modify boot when needed as well as patch the fstab and journal entries for bootability
There was a problem hiding this comment.
I've just considered that this file needs a greater explanation
The official docs are a bit sparse (or were when I first read them months ago), so I'll also explain myself:
tryboot_a_b=1 activates the tryboot mechanism, something supported in the raspbian kernel that allows for partition swapping using the command sudo reboot "0 tryboot". Using specifically that "0 tryboot" arg is how you boot into the partition listed under the [tryboot] boot_partition section.
That "0 tryboot" arg simply loads the boot partition listed under the [tryboot] header, it does not toggle anything in this file to make that partition the new default (which is handled by the amplipi-postflash service I've made), so doing a simple sudo reboot from the tryboot partition will send you back to whatever partition is listed under the [all] header
All the actual lifting is done by the individual boot partitions, which have their own kernels and mappings to their own root partitions
…re in by just running `ls`
Improve asgi.py documentation, variable names Make update flow less error prone with more validation
Add progress bar(s) to updater
| <!-- | ||
| Progress bar, dynamically sized depending on if the update needs to be downloaded first as well as if the boot image is present | ||
| this translates to there being a minimum of two segments if the update is already downloaded and is only for root, or 5 if it isn't downloaded and contains boot | ||
| --> | ||
| <div class="p-3 pb-0"> | ||
| <div class="progress" style="position: relative;"> | ||
| <div id="update-progress-bar" class="progress-bar progress-bar-striped progress-bar-animated bg-info" role="progressbar" style="width: 0%" aria-valuenow="0" aria-valuemin="0" aria-valuemax="100">0%</div> | ||
| </div> | ||
| <div class="d-flex text-center mt-1"> | ||
| <small class="update-progress-label d-none" data-label="Downloading root image" style="width: 0%;">Download Root</small> | ||
| <small class="update-progress-label d-none" data-label="Downloading boot image" style="width: 0%;">Download Boot</small> | ||
| <small class="update-progress-label d-none" data-label="Verifying root image" style="width: 0%;">Verify Root</small> | ||
| <small class="update-progress-label d-none" data-label="Verifying boot image" style="width: 0%;">Verify Boot</small> | ||
| <small class="update-progress-label d-none" data-label="Flashing root" style="width: 0%;">Flash Root</small> | ||
| <small class="update-progress-label d-none" data-label="Flashing boot" style="width: 0%;">Flash Boot</small> | ||
| <small class="update-progress-label d-none" data-label="Downloading manifest" style="width: 0%;">Manifest</small> | ||
| <small class="update-progress-label d-none" data-label="Downloading release" style="width: 0%;">Download</small> | ||
| <small class="update-progress-label d-none" data-label="Applying update" style="width: 0%;">Apply</small> | ||
| </div> |
There was a problem hiding this comment.
I added a weighted progress bar during these changes to help make the updater feel more responsive and less like a black box of sorts
This is possible now that we're dealing with files of known size, and the system knows how far along the flashing process it is.
Here's an example of what it looks like:
| class SSEChannel: | ||
| """ Bundles the queue/in-progress-flag/latest-status trio a long-running background job reports | ||
| its progress through, plus the polling generator that serves it as SSE to a native EventSource. | ||
| /update/flash and /update/download/images each run their own job in a background thread, | ||
| separate from the SSE connection itself, so a dropped/reconnecting browser can't interrupt or | ||
| duplicate the actual work - progress is watched via a paired GET .../progress endpoint instead. """ |
There was a problem hiding this comment.
I needed to ensure that there could only be one update running at a time (a problem with our current updater, but even more important to handle here) and thus I had to make a progress tracking channel.
While doing so, I also had the idea of having a visible progress bar on the frontend that this now also feeds
There was a problem hiding this comment.
This is probably going to be the most useful file during PR review, keeping this up to date will prove easier than keeping the actual PR description up to date especially since I can easily link to specific files from this
98ea67f to
3bbb544
Compare
3bbb544 to
e4d9a70
Compare
…hanges in files referencing moved scripts
…scripts to ensure proper routing
…hat always pass the assertion that the tests are worried about
2 participants
What does this change intend to accomplish?
This is a reworking of AmpliPi to function in a 64 bit raspbian trixie A:B tryboot setup with the goal of having a more robust system overall and a cleaner update flow with full image updates
Keep an eye on the docs/a_b_update_design.md file for a good rundown of the high level design and purpose of the new components within this PR
A few things that need to be worked on yet:
Checklist
./scripts/test