Skip to content
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

Set Raspberry Pi 2 Supervisor architecture correctly #3012

Merged
merged 1 commit into from
Dec 26, 2023

Conversation

agners
Copy link
Member

@agners agners commented Dec 21, 2023

The Raspberry Pi 2 was based on Cortex-A7 in first revisions, then Cortex-A53. However, both ar armv7 architectures, and that is also how the Operating System itself is configured. Use the correct architecture for Supervisor.

The hassos-supervisor script should recreate the container automatically on first boot after update.

Since Supervisor itself is written in Python this shouldn't affect much. However, the Supervisor uses it's architecture as default architecture when building local add-on and uses it as default architecture for multi-arch container images. This is also where this error got noticed (see home-assistant/supervisor#4402 (comment)).

The Raspberry Pi 2 was based on Cortex-A7 in first revisions, then
Cortex-A53. However, both ar armv7 architectures, and that is also how
the Operating System itself is configured. Use the correct architecture
for Supervisor.

The hassos-supervisor script should recreate the container
automatically on first boot after update.

Since Supervisor itself is written in Python this shouldn't affect much.
However, the Supervisor uses it's architecture as default architecture
when building local add-on and uses it as default architecture for
multi-arch container images. This is also where this error got noticed
(see home-assistant/supervisor#4402 (comment)).
@jens-maus
Copy link
Contributor

Please note that we had similar issues in the RaspberryMatic project in summer where suddently ghcr was returning with 404 errors. We could also solve that by changing our docker container generation from armhf to armv7 as well and also adapted our HA addon definitions. (cf. jens-maus/RaspberryMatic@e872869, jens-maus/RaspberryMatic#2393)

Good to see that this is now also hopefully solved in the rpi2 builds which AFAICS were the last build targets with armhf in the meta files.

@agners
Copy link
Member Author

agners commented Dec 21, 2023

Please note that we had similar issues in the RaspberryMatic project in summer where suddently ghcr was returning with 404 errors. We could also solve that by changing our docker container generation from armhf to armv7 as well and also adapted our HA addon definitions. (cf. jens-maus/RaspberryMatic@e872869, jens-maus/RaspberryMatic#2393)

Hm, the issue seems slightly different: The problem was at installation time, and was on the Tinkerboard. The Tinkerboard seems to use armv7 Supervisor by default, so this should have worked fine from HAOS/Supervisor perspective.

However, armhf in Debian is arm/v7, whereas Supervisor defined it to be arm/v6 (see https://github.com/home-assistant/supervisor/blob/2023.12.0/supervisor/docker/interface.py#L56). This is because we aligned more with Raspbian/Raspberry Pi OS in that perspective which defined their armhf architecture to be ARMv6 (see https://forums.raspberrypi.com/viewtopic.php?t=4256#p55723). I guess the problem in your case was simply that the multi-arch arm/v6 image did not exist.

@agners agners marked this pull request as ready for review December 21, 2023 14:22
@agners agners requested a review from sairon December 23, 2023 08:08
@agners agners merged commit 6c549c1 into dev Dec 26, 2023
2 checks passed
@agners agners deleted the fix-rpi2-compatibility branch December 26, 2023 16:53
agners added a commit that referenced this pull request Jan 3, 2024
The Raspberry Pi 2 was based on Cortex-A7 in first revisions, then
Cortex-A53. However, both ar armv7 architectures, and that is also how
the Operating System itself is configured. Use the correct architecture
for Supervisor.

The hassos-supervisor script should recreate the container
automatically on first boot after update.

Since Supervisor itself is written in Python this shouldn't affect much.
However, the Supervisor uses it's architecture as default architecture
when building local add-on and uses it as default architecture for
multi-arch container images. This is also where this error got noticed
(see home-assistant/supervisor#4402 (comment)).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants