Docker reports wrong Architecture

Single Board Computers Odroid N2/N2Plus/C4
1

Hi Guys,

Happy with all great code and tuning provided by the team behind CoreELEC - big thanks.

Docker is great addition to CoreELEC unlocking full power of Odroid N2, unfortunately did run into issue.

Docker on CoreELEC reports wrongly as OS/ARch linux/arm, whilst it should be linux/arm64.

This changes highly type of images which can be run under Docker and causes it to try to find images wrong images. Whilst some most popular will work fine, but others won’t. Took me quite a bit of time to identify the difference.

Same system running ubuntu with Docker shows proper linux/arm64.

If you could suggest at least quick workaround how to force it to report arm64 if not detected automatically that would be grant. Let’s just take the advantage of arm64 vs arm.

Thanks!

Output of docker version on CoreELEC:
Client:
Version: 18.09.7
API version: 1.39
Go version: go1.12.6
Git commit: 18.09.7
Built: Mon Feb 3 04:56:39 UTC 2020
OS/Arch: linux/arm
Experimental: true

Server:
 Engine:
  Version:          18.09.7
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.12.6
  Git commit:       18.09.7
  Built:            Mon Feb  3 04:56:39 UTC 2020
  OS/Arch:          linux/arm
  Experimental:     true

# docker info
Server Version: 18.09.7
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: journald
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 1.2.7
runc version: v1.0.0-rc8
init version: fec3683b971d9c3ef73f284f176672c44b448662
Kernel Version: 4.9.113
Operating System: CoreELEC (official): nightly_20200214
OSType: linux
Architecture: aarch64
CPUs: 6
Total Memory: 3.622GiB
Name: n2test
ID: S33D:XLKT:VLXJ:L5UN:YYCB:22BI:QBWR:E2SC:VHAQ:B4UB:V6W3:L5XM
Docker Root Dir: /var/media/storage-hdd/docker/var
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 52
 Goroutines: 81
 System Time: 2020-02-23T23:46:02.890880856Z
 EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support

On Ubuntu
#docker version
Client:
Version: 18.09.7
API version: 1.39
Go version: go1.10.1
Git commit: 2d0083d
Built: Fri Aug 16 14:20:24 2019
OS/Arch: linux/arm64
Experimental: false

Server:
 Engine:
  Version:          18.09.7
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.1
  Git commit:       2d0083d
  Built:            Wed Aug 14 19:41:23 2019
  OS/Arch:          linux/arm64
  Experimental:     false

Thanks!

p.s. not sure what’s wrong with formatting, but it doesn’t cooperate with me.

2

Looks ok to me. CoreELEC is a 32bit userspace on top of 64bit kernel system.
So essentially it’s a 32bit system, and this is represented correctly in Docker.

3

Thank you.
Any chances it will be brought up to 64bit userspace?

For records - running arm64v8 containers works just fine though need to be specifically pulled as by default v7 are pulled - hence thought it could be somehow fixed.

1 Like
4

Unlikely. We keep userspace at 32bit because that’s the best way to keep addons and other stuff compatible and running without issues.

6

Hi, I’m having a problem related to this: I’m running a docker container and, if I don’t specify the platform manually it’s getting arm build instead of arm64. I wouldn’t care if the arm build worked but it doesn’t, the arm64 does.

To bypass this issue I have to use the --platform option, but this requires the docker server to be set to experimental and I’d rather avoid it.

Is there another way to tell docker to pull arm64 images?

7

I wish this was mentioned on wiki (coreelec:docker [CoreELEC Wiki]). Have run into this issue recently: scanimage terminates with segmentation fault (#15039) · Issues · alpine / aports · GitLab

TL;DR; for alpine(-based) images make sure you put aarch64 insto /etc/apk/arch before pulling anything from repositories (i. e. apk add ..)

8

noticed that, I opted to use linuxserver.io from dockerhub using tags :arm64v8version

I am looking to potentially work around it… oddly running 64bit is supported…

CONTAINER ID NAME > CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
20945feb5979 code-server 0.00% 0B / 0B 0.00% 0B / 0B 0B / 0B 0
t-CoreELEC:~ # docker inspect linuxserver/code-server:arm64v8-4.16.1 | grep Architecture
“Architecture”: “arm64”,
t-CoreELEC:~ # docker inspect portainer/portainer-ce | grep Architecture
“Architecture”: “arm”,

is the docker compiled for 64??? and its just the configs that haven’t be adapted to use the os to determine what image to select? instead hardcoded for 32bit?

9

I’m having this problem too.

I only know how to add dock by stacks

For exemple:

version: “2.1”
services:
medusa:
image: lscr.io/linuxserver/medusa:latest
container_name: medusa
environment:
- PUID=1000
- PGID=1000
- TZ=America/Sao_Paulo
volumes:
- /storage/.config/dockers/medusa/config:/config
- /var/media/LIXO/COMPLETOS:/downloads
- /var/media/NAS1/Seriados:/tv
- /var/media/NAS1:/NAS1
- /var/media/LIXO:/LIXO
ports:
- 8081:8081
restart: unless-stopped

displays the following error message:

failed to deploy a stack: medusa Pulling no matching manifest for linux/arm/v8 in the manifest list entries

10

I asked about this a little while back and i believe the switch to 64bit is planned but I’ve no idea how hard that is so no idea when. You can still find and pull the older containers for as long as they work.

11

Any solutions?

12

Hi, I think there is a simple workaround/solution, you just have to specify the platform in your compose file, I’m using it like this and it’s working great:

 version: '3.9'
 services:
   pihole:
     platform: linux/arm64
     image: pihole/pihole:latest

The platform tag may not be available with old versions of docker compose but you can update it by using the binaries provided here: Releases · docker/compose · GitHub
I can even provide a script to automatically update it (using crontab), feel free to use it:

#!/usr/bin/bash
installVersion=$(/storage/.local/bin/docker-compose version | awk '{print $4}')
currentVersion=$(curl -s "https://api.github.com/repos/docker/compose/releases/latest"  | /opt/bin/jq -r '.name')
echo installVersion: $installVersion
echo currentVersion: $currentVersion

if [ "$installVersion" != "$currentVersion" ]
then
    echo "update found"
    # echo $currentVersion > /storage/.local/bin/compose.version
    wget "https://github.com/docker/compose/releases/download/$currentVersion/docker-compose-linux-aarch64" -O /storage/.local/bin/docker-compose.new
    if [ "$?" != "0" ]
    then
        /storage/telegram.sh N2 "N2+ Docker compose update - WGET ERROR"
    else
        mv /storage/.local/bin/docker-compose /storage/.local/bin/docker-compose.old
        chmod +x /storage/.local/bin/docker-compose.new
        mv /storage/.local/bin/docker-compose.new /storage/.local/bin/docker-compose
        /storage/telegram.sh N2 "N2+ Docker compose updated to $currentVersion"
    fi
elif [ "$currentVersion" == "null" ]
then
    /storage/telegram.sh N2 "N2+ Docker compose update - CURL ERROR"
fi
1 Like