agners
commented
5 months ago Thanks for the report and the extensive investigation!
As you can see, the architecture of Supervisor (armv7) doesn't match the architecture of Core (armhf). I've used it like that from the start and it wasn't an issue - check_image() was recently introduced in https://github.com/home-assistant/supervisor/pull/4991. This causes Supervisor to download a new Core image every time it starts. I am aware that this configuration is caused by the unsupported OS, but since armv7 code is compatible with armhf it causes no runtime issues.
Hm, yeah so this change essentially assumes Supervisor arch == Core arch.. :thinking: . For add-on we explicitly want to allow the use of a compatible arch, but for Core there is actually not much reason to use a different arch. You loose out on potential performance improvements of the native arch over the compatible arch. I guess in your case the main reason you picked an armhf arch was because there is no generic armv7 machine. Maybe we should introduce one :thinking:
As a work around you can pick any of the machine which base on armv7 instead (see https://github.com/home-assistant/builder/blob/2024.03.5/builder.sh#L37-L59).
IMHO, we could actually solidify the Supervisor arch == Core arch requirement, I don't see a reason why not to use the same arch. But Supervisor should inform the user more gracefully if there is a miss match.
- Supervisor blindly assumes that Core is running when it detects it has been restarted (without the OS being restarted). As you can see, that's not the case when a new Core image is downloaded for whatever reason (like the arch mismatch).
Without judging weather that behavior is "correct" or can be improved, I think the reason for it is so that ha core stop works across Supervisor restarts. E.g. a user who explicitly wants Core to be stopped (which is probably mostly a development use case), doesn't get surprised by "automatic" restarts.
kuba2k2
gmshiwoge
github-actions[bot]
sunshine-hass
zerychao
Describe the issue you are experiencing
Disclaimer: I am running an unsupported installation - HA Supervised on Alpine Linux - however, I'm reporting the bug because of its nature. It also applies to supported installations in some cases.
Today my Supervisor container restarted (for no reason, I don't know why, but it's hopefully irrelevant). It started back up, then proceeded to remove the HA Core container & image, followed by downloading it again. However, Supervisor didn't start Core after doing that. It just assumed everything was okay and continued its usual setup, showing that the system is Healthy, while the Core wasn't even running at all.
Here are some relevant log lines from the Supervisor:
After around 2 hours of digging in the Supervisor source code I found two issues causing this behavior:
supervisor.docker.interface.DockerInterface.check_image(). It is worth noting that my/etc/hassio.jsonlooks as follows:As you can see, the architecture of Supervisor (armv7) doesn't match the architecture of Core (armhf). I've used it like that from the start and it wasn't an issue -
check_image()was recently introduced in #4991. This causes Supervisor to download a new Core image every time it starts. I am aware that this configuration is caused by the unsupported OS, but since armv7 code is compatible with armhf it causes no runtime issues.I agree that the likelihood of that issue appearing in any of the supported setups is small, however this still looks like a bug worth reporting.
What type of installation are you running?
Home Assistant Supervised
Which operating system are you running on?
Other (e.g., Raspbian/Raspberry Pi OS/Fedora)
Steps to reproduce the issue
Anything in the Supervisor logs that might be useful for us?
System Health information
nothing
Supervisor diagnostics
No response
Additional information
No response