fix(rpi-image): patch the host OS automatically, unfreeze the Docker engine - #1001
Open
HuggeK wants to merge 2 commits into
Open
fix(rpi-image): patch the host OS automatically, unfreeze the Docker engine#1001HuggeK wants to merge 2 commits into
HuggeK wants to merge 2 commits into
Conversation
…engine Self-update covers only FTW's own containers; the flashed Pi never received an OS security update, and the image build deleted Docker's apt source, so even a manual `apt upgrade` could not patch the engine. - install unattended-upgrades: Debian security + the Raspberry Pi archive (the kernel/firmware source has no security pocket), with automatic reboots pinned off — a reboot stops dispatch - park docker.list as docker.list.disabled during the image build (same export-image OOM workaround) and restore it in ftw-firstboot, so engine patching becomes a normal operator apt action - document the self-update/host boundary and a retrofit for devices flashed from older images Fixes srcfl#770 Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com> Claude-Session: https://claude.ai/code/session_012taMkhFbYYNyVQmCTU26sn
HuggeK
marked this pull request as ready for review
August 29, 2026 17:38
Master moved from srcfl#756 to srcfl#998 under the branch; the only real conflict was firstboot.sh, where srcfl#980-era work made first boot try `docker compose up -d` on locally present images before falling back to the GHCR pull loop. Kept that up-first flow and placed the docker.list restore (srcfl#770) before it, right after cd /opt/ftw. Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com> Claude-Session: https://claude.ai/code/session_012taMkhFbYYNyVQmCTU26sn
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #770.
Pressing Update in the app updates Core, the Optimizer and drivers — and nothing else. A flashed Pi never received a host OS security update, and because the image build deletes Docker's apt source after installing the engine, not even a manual
sudo apt upgradecould patchdocker-ce. This PR implements options 1–3 from #770:unattended-upgradeson the appliance image. Origins: Debian security plus the Raspberry Pi archive, applied daily;Automatic-Reboot "false"is pinned explicitly — a reboot stops dispatch, so a staged kernel waits for an operator-chosen reboot.docker.listasdocker.list.disabled(apt only reads*.list/*.sources, so the pi-genexport-imageOOM workaround is preserved) andftw-firstbootrestores it on the device. Engine patching becomes a normalapt upgrade.docs/self-update.md,docs/operations.mdanddocs/rpi-image.mdnow say plainly that self-update never touches the host, andrpi-image.mdcarries a retrofit block for devices flashed from older images.Why the Raspberry Pi archive is in the origins, but Docker is not
The Raspberry Pi archive (
Origin: Raspberry Pi Foundation) is wherelinux-image-rpi-v8,raspi-firmwareand the bootloader packages come from, and it has no separate security pocket. Restricting unattended-upgrades to Debian's security pocket alone would leave exactly the packages the issue worries about — the kernel — permanently unpatched. Kernel updates install but only take effect at the next operator reboot, so including the archive costs no unplanned downtime.Docker's repository is deliberately not auto-upgraded: a
docker-ceupgrade restarts the daemon and with it every container, which is a dispatch interruption that should happen at a moment the operator picks, not at the apt-daily timer's. Restoring the source makes that manual action possible at all; the fragment's comment records the decision.Verification
bash -npasses on both modified scripts (same check thevalidate installer scaffoldingjob runs).archive.raspberrypi.com/debian/dists/trixie/ReleasereportsOrigin: Raspberry Pi Foundation/Codename: trixie;download.docker.com/linux/debian/dists/trixie/ReleasereportsOrigin: Docker.apt.conf.dfiles, so52ftw-unattended-upgradesextends the Debian defaults in50unattended-upgradesinstead of replacing them.rpi-image-build.ymlwithout publishing to get a flashable candidate.Option 4 from the issue (surfacing host patch state in Update Center) is deliberately left out: it crosses the core-has-no-host-visibility boundary and deserves its own discussion. Existing installations get the documented retrofit, not an automatic migration — core never touches the host.
🤖 Generated with Claude Code
https://claude.ai/code/session_012taMkhFbYYNyVQmCTU26sn