Make work on arm64 (aka Raspberry Pi) about starlink-grpc-tools HOT 15 CLOSED

I'll have a look. It shouldn't be a problem unless some of the required pip modules are not available for that arch.

from starlink-grpc-tools.

It shouldn't be a problem unless some of the required pip modules are not available for that arch.

I don't think it should be a problem, as meanwhile I installed it directly (ie outside of any container) in the same machine (following your instructions on README.md) and it's working. More specifically the pip install [...] requirements.txt command ran with a single warning, nominally that I already had paho-mqtt installed.

I'll have a look.

Thanks! I've already started using it, but would much prefer having it run inside a container.

from starlink-grpc-tools.

I build ARM64 for a separate project (https://github.com/sponsianus/dishy_grafana). It's a little behind the main project but might work for your use case.

https://hub.docker.com/repository/docker/sponsianus/starlink-grpc-tools

from starlink-grpc-tools.

The GitHub action for publishing a multi-arch docker image looks pretty straightforward, so I will test that out in a branch.

I did test a linux/arm64 image build locally, and it built OK, but it took a couple hours because the Dockerfile has all the pip packages pinned to specific versions, some of which did not have arm64 binary wheels on pypi. It looks like later versions of those packages do, though, so I'm going to update to current versions for all of them. I probably should have been doing that periodically, anyway.

from starlink-grpc-tools.

OK, it has published and is tagged with the branch name, so you should be able to access it with:

docker pull ghcr.io/sparky8512/starlink-grpc-tools:docker-arm64

I have only sanity tested it, and only with emulation for the ARM64 image. I will test it more thoroughly in a bit, given that I updated all the pip-installed package versions, but if someone could give the linux/arm64 image a try on an actual ARM64 device, I'd appreciate it.

from starlink-grpc-tools.

Note that some Raspberry Pis (mine is a 4B rev 1.1) aren't going to run an arm64 OS. Mine is armv7l (which looking at setup-qemu-action would be linux/arm/v7).

I also have to add the pypng package to the Dockerfile when I build it.

from starlink-grpc-tools.

Note that some Raspberry Pis (mine is a 4B rev 1.1) aren't going to run an arm64 OS. Mine is armv7l (which looking at setup-qemu-action would be linux/arm/v7).

I can add a linux/arm/v7 image easily enough, but was only planning to do so if someone requested it. The images are kinda big to be leaving around if nobody is going to use them. I take it you would use them if they were being published?

On a related topic: Is the >1GB image size going to be a problem for RPi users? Nothing in starlink-grpc-tools needs the full Debian base image, so the Dockerfile could be changed to use the slim version, which comes out to about 200MB. However, every time I look into doing so, I am reminded that using the full base image could actually use less storage overall if it shared with other images due to not having to add missing packages back into those other images. I don't actually use Docker much, other than testing for this project, so I don't really have an opinion on this myself.

I also have to add the pypng package to the Dockerfile when I build it.

Oops, thanks for pointing that out. I guess I missed that when I added the obstruction map script. I will correct it.

from starlink-grpc-tools.

I can add a linux/arm/v7 image easily enough,

So... it turns out this was only half true. I can add building of that image easily enough, but when I test doing so locally, all the scripts fail trying to load the grpc module due to a shared library issue. googling around leads me to believe this has been a persistent problem with the armv7l binary wheel for the grpcio package posted on PyPI.

The most commonly recommended solution is to pass an option to pip to build that package's wheel from source. I tested that and it takes a long time (running via qemu) to build a Docker image, but it does result in a working image. I would want to conditionalize that so it only does that for linux/arm/v7. Before I do that, though, I really would like to see if anyone would actually use it.

from starlink-grpc-tools.

Yep, it's this issue: https://groups.google.com/g/grpc-io/c/vjbL3IdZ2Vk/m/EcKSeD4eAgAJ

I had to install it with the --no-binary option:
pip3 install grpcio==1.44.0 grpcio-reflection==1.44.0 --no-binary=":all:"

I did not try with version 1.50.0, but it is working for me now.

from starlink-grpc-tools.

OK, I finally got around to actually generating the image in the main branch. I had to update my procedure for updating the "latest" tag after testing, too, but as of now, the "latest" tag points to an image that supports both linux/amd64 and linux/arm64.

If anyone wants a 32-bit ARM image to be included, please file a separate issue. Otherwise, I will look into changing the Dockerfile to add the appropriate pip flag so it works if someone makes their own image, but may or may not add it to the images posted to the repository here.

from starlink-grpc-tools.

Note that some Raspberry Pis (mine is a 4B rev 1.1) aren't going to run an arm64 OS. Mine is armv7l (which looking at setup-qemu-action would be linux/arm/v7).

This, of course, depends on the specific OS. In my case, I run Devuan Chimaera 4.0 (systemd-less Debian Bullseye) and it's arm64 alright:

uname -a
    Linux REDACteD 5.15.74 #1 SMP PREEMPT Mon Oct 31 13:02:05 EDT 2022 aarch64 GNU/Linux

from starlink-grpc-tools.

OK, it has published and is tagged with the branch name, so you should be able to access it with:

docker pull ghcr.io/sparky8512/starlink-grpc-tools:docker-arm64

The above command is showing me the following error:

Error response from daemon: manifest unknown

from starlink-grpc-tools.

Before I do that, though, I really would like to see if anyone would actually use it.

Yep, I'm really going to use it (and BTW, sorry for the delay in coming back to this).

I just would like to note that my architecture is arm64/aarch64 as mentioned in the issue's title.

from starlink-grpc-tools.

The above command is showing me the following error:

Error response from daemon: manifest unknown

Yes, I deleted that image in order to avoid people thinking they need to use that one for ARM support. The regular one (the "latest" tag) should now be usable using the standard command from the README.

Before I do that, though, I really would like to see if anyone would actually use it.

Yep, I'm really going to use it (and BTW, sorry for the delay in coming back to this).

I just would like to note that my architecture is arm64/aarch64 as mentioned in the issue's title.

No problem. The 64-bit ARM image is already there now, and I was asking about the 32-bit one in that comment.

from starlink-grpc-tools.

The 64-bit ARM image is already there now, and I was asking about the 32-bit one in that comment.

Thanks for the clarification.

In fact, I just docker pulled it as per the README and it seems to be working perfectly.

I will keep testing it as I integrate it into my telemetry environment, and if I detect any problems I will open a more specific issue.

Closing this one now, and thanks again,

from starlink-grpc-tools.