mirror of
https://github.com/home-assistant/supervisor.git
synced 2026-08-13 08:22:36 +01:00
* Respect user-overridden Core image for install and update The override_image setting was only honored by load(): the landingpage install, the initial Core install and Core updates always pulled the image from the update information and wrote it back to the Home Assistant config afterwards, discarding the user override on the next install or update. Add a HomeAssistant.install_image property that returns the user-overridden image if set and the image from the update information otherwise. Use it in the landingpage install, Core install and Core update paths, and persist that same image afterwards so the override is kept. Version resolution is unchanged. With an override set, a fresh install now pulls <image>:landingpage from the overridden image as well. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Mark system unsupported when a custom Core image is used As raised in review, running a Home Assistant Core fork should be visible: add an evaluation that marks the system unsupported when the configured Core image differs from the default image for the machine. The evaluation compares the configured image against the default image instead of checking the override_image flag, so it also catches images recorded through container adoption or manual configuration edits where the flag is not set. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Capture install image once per Core install and update As raised in review, the install image was read separately for the image pull and for persisting it to the Home Assistant config. If the image option changes while an install or update job is running, the pulled and the persisted image could diverge. Capture the value once per install attempt respectively once per update job (covering the rollback path) and use it for both the pull and set_image(). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>