New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supervisor doesn't start Core in certain cases #5050
Comments
Thanks for the report and the extensive investigation!
Hm, yeah so this change essentially assumes Supervisor arch == Core arch.. 🤔 . 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 🤔 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.
Without judging weather that behavior is "correct" or can be improved, I think the reason for it is so that |
I found out that there are "generic" images for all architectures - they're called I'm not sure what the
I agree that the |
That seems to be another bug in the Supervisor code - # Evaluate current CPU/Platform
if not self.sys_machine or self.sys_machine not in arch_data:
_LOGGER.warning("Can't detect the machine type!")
self._default_arch = native_support
self._supported_arch.append(self.default)
return
# Use configs from arch.json
self._supported_arch.extend(arch_data[self.sys_machine])
self._default_arch = self.supported[0]
# Make sure native support is in supported list
if native_support not in self._supported_arch:
self._supported_arch.append(native_support)
self._supported_set = set(self._supported_arch) Notice how it doesn't populate |
Hello, my friend. My CPU has an aarch64 architecture, and since May, I've been experiencing the same issue as you. Every time I reboot and download a new Core image, or enter recovery mode, it tells me to wait for 20 minutes. |
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.json
looks as follows:check_image()
was recently introduced in Allow adoption of existing data disk #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
The text was updated successfully, but these errors were encountered: