Pulling microsoft/dotnet:2.1-runtime responds with "No matching manifest for linux/arm64 in the manifest list entries"


#1

Not sure where the issue is because dotnet dockerfiles are multiarch since 2.1. When building in local mode it works fine. Any idea?

[Info] Starting build for simulated-dev, user gh_bnjmn83
[Info] Dashboard link: https://dashboard.balena-cloud.com/apps/xxxx/devices
[Info] Building on arm03
[Info] Pulling previous images for caching purposes…
[Success] Successfully pulled cache images
[simulateddevice] Step 1/20 : FROM microsoft/dotnet:2.1-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


#2

bump


#3

Anyone?


#4

Hey @bnjmn83, I will investigate it and get back to you asap.

Cheers


#5

Hey @bnjmn83, beacuse you said it worked in local mode, I’m assuming you have an armv7 device? I checked the manifest for that image, and there indeed is not one for armv8.

What this looks like to me is that our docker daemons (which run on armv8/aarch64 servers) are trying to pull the aarch64 version that does not exist, even though we have some infrastructure in place to run builds as the correct architecture. There are some other places where this infrastructure falls down, but we’ve not seen this before.

I’ll raise this internally to see what we can do about it, but in the meantime, could you trying force-running an emulated build?

balena push simulated-dev --emulated

If this also fails, you could biuld locally on a device and balena deploy the result, but this is less than ideal.

Cameron


#6

Thank you for getting back at me.

Yes I do have a RPI3 running locally to verify that the dotnet runtime works on this architecture.

Results in:

[Info]     Uploading images
[Success]  Successfully uploaded images
[Success]  Release successfully created!
[Info]     Release: 0b69e45877eefc30107b0866bfa106fe (id: 739894)
[Info]     ┌─────────┬────────────┬────────────┐
[Info]     │ Service │ Image Size │ Build Time │
[Info]     ├─────────┼────────────┼────────────┤
[Info]     │ main    │ 177.00 MB  │ 36 seconds │
[Info]     └─────────┴────────────┴────────────┘
[Info]     Build finished in 1 minute, 8 seconds

So this prooves the image can be created in general but does not take into account the appropriate architecture right?

I also tried

>> balena build --deviceType raspberrypi3 --arch armv7hf --emulated
Docker seems to be unavailable. Is it installed and running?

If you need help, don't hesitate in contacting us at:

  GitHub: https://github.com/balena-io/balena-cli/issues/new
  Forums: https://forums.balena.io

I tried this but on the device itselft it does not invoke the cli but the container engine:

root@676b116:~# balena deploy
balena-engine: 'deploy' is not a balenaEngine command.
See 'balena-engine --help'

#7

any ideas? suggestions?


#8

sry to bother you guys again, but this issue is pretty serious and urgent. I’d be awesome if someone could get back at us soon.


#10

Hey,

So the balena push simulated-dev --emulated worked succesfully, and this is a build for your architecture. Did you try to run this release?

The balena build command requires a local docker daemon to be running - which operating system are you using?

The balena deploy command needs to be ran on your computer, not on your device, but again this requires a docker daemon.

It looks to me that your best bet for the time being is to use our emulated builders for now.


#11

Did you try to run this release?

It was uploaded right? How can I access it?

The balena build command requires a local docker daemon to be running - which operating system are you using?

I am on a Win10 Enterprise and the latest Docker version is running.

The balena deploy command needs to be ran on your computer, not on your device, but again this requires a docker daemon.

You said you could build locally on a device and "balena deploy" the result.
So I built it on a device (RPI) with success. But not sure where to get there from here. How can I build on the device and deploy this image from my workstation?

It looks to me that your best bet for the time being is to use our emulated builders for now.

yeah sure whatever works… but as I said above I got no idea how to access the built image and how to deploy it to my application? How do I reference to Release: 0b69e45877eefc30107b0866bfa106fe as my image in the compose file?


#12

@bnjmn83 My mistake, I had assumed that the balena build which you ran was with the balena-cli tool. Regardless, the image that you built using balena push --emulated (the CLI tool) should now be set as your application commit. Any device which is part of the applicaiton simulated-dev should now start downloading and running that image, is that not the case?


#13

Yes, the image was deployed on the device but there were some errors regarding the architecture.

From the device’s log:

25.01.19 09:47:05 (+0100) Creating network ‘default’
25.01.19 12:04:06 (+0100) Creating volume ‘resin-data’
25.01.19 12:04:06 (+0100) Downloading image ‘registry2.balena-cloud.com/v2/25bcb4e1d2c0a0557f3c241ce2ec48**@sha256:dc1512d3665ab7c344244ab94fc1720819b9e91baca3a54f9aefc319714eaf**
25.01.19 12:05:06 (+0100) Downloaded image ‘registry2.balena-cloud.com/v2/25bcb4e1d2c0a0557f3c241ce2ec48**@sha256:dc1512d3665ab7c344244ab94fc1720819b9e91baca3a54f9aefc319714eaf**
25.01.19 12:05:06 (+0100) Installing service ‘main sha256:aa00a39b95027783b621c34fb5d9ccde316af0ff81e2be16bcc524409a5bfc**’
25.01.19 12:05:07 (+0100) Installed service ‘main sha256:aa00a39b95027783b621c34fb5d9ccde316af0ff81e2be16bcc524409a5bfc**’
25.01.19 12:05:07 (+0100) Starting service ‘main sha256:aa00a39b95027783b621c34fb5d9ccde316af0ff81e2be16bcc524409a5bfc**’
25.01.19 12:05:09 (+0100) Service exited ‘main sha256:aa00a39b95027783b621c34fb5d9ccde316af0ff81e2be16bcc524409a5bfc**’
25.01.19 12:05:09 (+0100) Restarting service ‘main sha256:aa00a39b95027783b621c34fb5d9ccde316af0ff81e2be16bcc524409a5bfc**’
25.01.19 12:05:08 (+0100) main standard_init_linux.go:195: exec user process caused "exec format error


#14

any clue?