I cannot deploy a .Net Core 2.2 App via the Balena cloud on my device.
What I did on my local console:
**git push balena master**
[Info] Starting build for simulated-dev, user gh_bnjmn83
[Info] Dashboard link: https://dashboard.balena-cloud.com/apps/1337718/devices
[Info] Building on arm03
[Info] Pulling previous images for caching purposes...
[Success] Successfully pulled cache images
[simulateddevice] Step 1/15 : FROM microsoft/dotnet:2.2-runtime AS base
[simulateddevice] no matching manifest for linux/arm64 in the manifest list entries
[Error] Some services failed to build:
[Error] Service: simulateddevice
[Error] Error: no matching manifest for linux/arm64 in the manifest list entries
[Error] Not deploying release.
remote: error: hook declined to update refs/heads/master
To git.balena-cloud.com:gh_bnjmn83/simulated-dev.git
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'gh_bnjmn83@git.balena-cloud.com:gh_bnjmn83/simulated-dev.git'
In the dashboard I get an error regarding the architecture:
06.04.19 17:26:15 (+0200) Restarting service ‘main sha256:d10203c8a72b8e8d622d5e2628562b1a4a83fa677352148dd59ae2e1541b807e’
06.04.19 17:26:15 (+0200) main standard_init_linux.go:195: exec user process caused “exec format error”
06.04.19 17:26:16 (+0200) Service exited ‘main sha256:d10203c8a72b8e8d622d5e2628562b1a4a83fa677352148dd59ae2e1541b807e’
Since .net Core’s docker repos are multi arch this should not happen.
Also I can deploy my project perfectly using local deploy on my raspberry pi
[Info] Starting build for simulated-dev, user gh_bnjmn83
[Info] Dashboard link: https://dashboard.balena-cloud.com/apps/1337718/devices
[Info] Building on arm01
[Info] Pulling previous images for caching purposes...
[Success] Successfully pulled cache images
[simulateddevice] Step 1/15 : FROM microsoft/dotnet:2.2-runtime AS base
[simulateddevice] no matching manifest for linux/arm64 in the manifest list entries
[Error] Some services failed to build:
[Error] Service: simulateddevice
[Error] Error: no matching manifest for linux/arm64 in the manifest list entries
[Error] Not deploying release.
remote: error: hook declined to update refs/heads/master
To git.balena-cloud.com:gh_bnjmn83/simulated-dev.git
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'gh_bnjmn83@git.balena-cloud.com:gh_bnjmn83/simulated-dev.git'
Host OS reports:
root@30ac154:~# uname -m
aarch64
root@30ac154:~# uname -a
Linux 30ac154 4.14.98 #1 SMP PREEMPT Mon Apr 1 15:47:35 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
Hey @bnjmn83 I just tried out running an ASP.NET Core app on my Pi and I thought it would help to share my findings with you.
So the error in your logs above is due to the Microsoft docker image not containing a manifest for linux/arm64 (AARCH64) so it cannot produce an an image for that platform. I have solved that myself by creating my own BalenaLib-based image for AARCH64 and then including the DotNetCore binaries for ARM64 from Microsoft. This works on my Pi 3b+ running the 64bit OS but with a few caveats…
Currently the DotNetCore libs do not work well on AARCH64 when it comes to compiling the projects; the runtime seems OK though, What I did is build my images around the v3.0 preview 3 of DotNetCore and that allowed me to build/run an ASP.NET application fine. If you don’t require 64bit, then the latest 2.2.3 release will work fine on a Pi 3 too, again I made images for this in the same way.
I am talking to the internal team responsible for our base images, to see if we can put out a supported DotNetCore SDK and Runtime (w/ASP.NET) set of images, but until then I will happily share my project once I have pushed it to Git
Yes would be nice if you could share your findings!
one more question regarding the RPI’s architecture and .Net Core:
When I run my project directly on the device which runs Balena OS and build my image based on microsoft/dotnet:2.2-aspnetcore-runtime and microsoft/dotnet:2.2-sdk everything works as expected. How does this correlate with your assumptions? I am still a little confused…
I presume here you mean that you built your images on your workstation? and pushed them to dockerhub and then balena run... on the device?
So each image has a manifest which defines which architectures it can be used on, or which image blob to return based on the host which is asking for it. In your logs it is clear that the image doesn’t support the architecture of the host trying to use it as a layer in the image build process…
Can you confirm the following:
your application’ device type (Raspberry Pi 3 etc)
your desired arch type (armv7hf or aarch64)
your docker-compose,yml and/or the Dockerfile.template (you can omit sensitive stuff if you need)
FYI - The --emulated forces the build process to invoke the RUN elements of your Dockerfile through a qemu process which targets your application type’s arch.
I presume here you mean that you built your images on your workstation? and pushed them to dockerhub and then balena run... on the device?
No, I run docker-compose up --build on the target. Everything builds natively and it works perfectly. Hence, there is no general issue with .Net Core running on RPI3.
OK, so when you do this, the native docker process asks dockerhub for the image and the host’s arch is passed over. So you get a working base image. If you used this same compose file with our builders, then they would do the same thing - and this is probably why there is some disconnect in arch’s/manifests etc.
I am not sure if this is resolvable using Microsoft’s container images directly, and isn’t the way I resolved it personally. Let me get my setup pushed to GitHub and you can see what I did
Here is a link to a repo I just put up which is using ASP.NET Core 2.2.3 and it will work fine on armv7hf and amd64 targets. I haven’t included the code to support aarch64 as it would mean that:
the framework is still PREVIEW from Microsoft.
the ASP.NET project would need to use v3.0.0 libs instead of v2.2.0 ones, so it’s not backwards compatible.
It uses a multi-stage build to make a suitable SDK images able to publish the project, then pulls that artifact out into a runtime image which will serve the application. I used ASP.NET for this, but you could adapt it as needed if you wanted just a console app etc.
