supervisor icon indicating copy to clipboard operation
supervisor copied to clipboard
verified publisher icon home-assistant

Deprecate i386 and armhf Supervisor architectures

Open agners opened this issue 11 months ago • 1 comments

Proposed change

Deprecate i386 and armhf Supervisor architectures. According to analytics there are 38 armhf and 6 i386 installation at this point. This PR implements a simple mechanism through the Supervisor's unsupported mechanism to inform the remaining users. If merged, in a second step we can then remove all the references from the codebase.

Type of change

  • [ ] Dependency upgrade
  • [ ] Bugfix (non-breaking change which fixes an issue)
  • [ ] New feature (which adds functionality to the supervisor)
  • [x] Breaking change (fix/feature causing existing functionality to break)
  • [ ] Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:
  • Link to cli pull request:
  • Link to client library pull request:

Checklist

  • [ ] The code change is tested and works locally.
  • [ ] Local tests pass. Your PR cannot be merged unless tests pass
  • [ ] There is no commented out code in this PR.
  • [ ] I have followed the development checklist
  • [ ] The code has been formatted using Ruff (ruff format supervisor tests)
  • [ ] Tests have been added to verify that the new code works.

If API endpoints or add-on configuration are added/changed:

agners avatar Feb 11 '25 13:02 agners

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.

github-actions[bot] avatar Mar 13 '25 14:03 github-actions[bot]

In discussion internally we were wondering what happens to instances which are offline, and come back online after we shipped the last release (with this PR included) for these deprecated architectures. In that case, an old Supervisor yet unaware of the deprecation, will simply try to update to the latest Supervisor. But that latest Supervisor does not exist for its architecture :scream: .

We currently do not have per architecture versions, the version files, e.g. stable.json for the stable channel, have a single entry for Supervisor. So a system which comes online in the future, will try to fetch a non-existing image, e.g. ghcr.io/home-assistant/armv7-hassio-supervisor:2025.12.0.

In quick tests, Supervisor seems to give up after a single try and create an issue:

2025-11-21 12:14:26.375 INFO (MainThread) [supervisor.supervisor] Update Supervisor to version 2025.11.5                                                                                                       
2025-11-21 12:14:26.379 INFO (MainThread) [supervisor.docker.interface] Downloading docker image ghcr.io/home-assistant/armv7-hassio-supervisor with tag 2025.11.5.                                            
2025-11-21 12:14:27.185 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/home-assistant/armv7-hassio-supervisor:2025.11.5: DockerError(404, 'manifest unknown')                          
2025-11-21 12:14:27.188 INFO (MainThread) [supervisor.resolution.module] Create new issue update_failed - supervisor / None                                                                                    
2025-11-21 12:14:27.191 CRITICAL (MainThread) [supervisor.supervisor] Update of Supervisor failed: Can't install ghcr.io/home-assistant/armv7-hassio-supervisor:2025.11.5: DockerError(404, 'manifest unknown')

This will happen approximately every 7.5h (tasks RUN_RELOAD_UPDATER and RUN_UPDATE_SUPERVISOR). They will continue to do so forever :cry: . Note that when these errors happen in the update tasks currently they are unhandled leading to large stack traces. PR #6328 addresses this issue.

One possible way to avoid this is to continue release (re-tagged) version of the last Supervisor release for these architectures. However, the Supervisor itself knows its version from supervisor/const.py stored inside the container. With that the Supervisor realizes the update did not succeed:

2025-11-21 14:52:18.647 INFO (MainThread) [supervisor.docker.supervisor] Attaching to Supervisor ghcr.io/home-assistant/armv7-hassio-supervisor with version 2025.11.4
...
2025-11-21 14:52:18.795 ERROR (MainThread) [supervisor.core] Update '2025.11.5' of Supervisor '2025.11.4' failed!
2025-11-21 14:52:18.795 INFO (MainThread) [supervisor.resolution.module] Create new issue update_rollback - supervisor / None
...

This triggers a protection in supervisor/core.py:connect(), where the current image version is compared to what should have been updated to (we store the target version after successful update, before restarting Supervisor). Since the expected version does not match the version in the (retagged) image, the update_rollback issue is raised (since it looks as if the update got rolled-back), and the system is marked unhealthy. This will stop any further updates.

2025-11-21 15:10:04.050 INFO (MainThread) [supervisor.jobs] 'Tasks._update_supervisor' blocked from execution, system is not healthy - supervisor
...
2025-11-21 15:10:03.923 INFO (MainThread) [supervisor.updater] Fetching update data from https://agner.ch/stable.json
2025-11-21 15:10:04.050 INFO (MainThread) [supervisor.jobs] 'Tasks._update_supervisor' blocked from execution, system is not healthy - supervisor
2025-11-21 15:10:23.895 INFO (MainThread) [supervisor.jobs] 'Tasks._update_supervisor' blocked from execution, system is not healthy - supervisor

So things seem to work out really nicely.

On reboot, the system will try another Supervisor update, running into the same issue again. Since the image is just a retagged version, it is rather cheap to fetch that image (in fact, it seems the tagged image even remains in local image storage). So this is an acceptable situation.

agners avatar Nov 21 '25 14:11 agners