With Ubuntu on arm64 apt/sources.list.d/docker.list specifies wrong architecture by default

[damonmaria]

What you expected to happen?

On a Raspberry Pi 3 with Ubuntu 18.04 I expected this to be able to install Docker.

What happened?

Docker fails to install. The base error is that /etc/apt/sources.list.d/docker.list specifies the wrong architecture:

# This file is managed by Puppet. DO NOT EDIT.
# docker
deb [arch=aarch64] https://download.docker.com/linux/ubuntu bionic stable

For apt the correct architecture for 64-bit ARM is arm64.

How to reproduce it?

class { 'docker':
  version => '5:18.09.6~3-0~ubuntu-bionic',
}

Anything else we need to know?

To workaround this I have to add:

class { 'docker::repos':
  architecture => 'arm64',
}

docker::repos gets the default value of architecture from $facts['architecture']. Looking through all the facts returned on a Raspberry Pi 3 I cannot see any fact returning arm64. So I'm not sure what the correct fact would be or how other modules handle this.

Versions:

$ puppet --version
5.4.0

$ docker version
Client:
 Version:           18.09.6
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        481bc77
 Built:             Sat May  4 02:40:48 2019
 OS/Arch:           linux/arm64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.6
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.8
  Git commit:       481bc77
  Built:            Sat May  4 02:00:10 2019
  OS/Arch:          linux/arm64
  Experimental:     false

$ facter os
{
  architecture => "aarch64",
  distro => {
    codename => "bionic",
    description => "Ubuntu 18.04.2 LTS",
    id => "Ubuntu",
    release => {
      full => "18.04",
      major => "18.04"
    }
  },
  family => "Debian",
  hardware => "aarch64",
  name => "Ubuntu",
  release => {
    full => "18.04",
    major => "18.04"
  },
  selinux => {
    enabled => false
  }
}

$ puppet module list
/usr/share/puppet/modules (no modules installed)

Logs:

Run with --debug here

[florindragos]

Hi @damonmaria
Unfortunately, we don't officially support Raspberry PI. From what you described, it looks like the issue is not really related to the docker module.
If the $facts['architecture'] value is not correct, you can override it by using your workaround. Not sure if we can or should fix this in the module.

[damonmaria]

I think the root problem is Ubuntu (Debian?) using arm64 when the Linux kernel uses aarch64. Probably always going to lead to these issues.

Another potential solution would be puppetlabs-docker to not to specify the architecture in apt::source { 'docker' if none is passed to docker::repos. It seems strange to always override it. I suspect this problem is not Raspberry Pi specific, but will show up on the Debian family on all ARM64 platforms. Not overriding the source arch would fix that.

[fmichea]

@damonmaria Could I ask clarification on how to use the workaround? My manifests include docker which in turn includes docker::repos. I cannot seem to be able to configure the architecture without triggering "duplicate declaration" error of the class (that part I get). My puppet is quite rusty so I cannot seem to remember how to work this out, would appreciate any help :)

[damonmaria]

@fmichea I have a hiera lookup by architecture, from my hiera.yaml:

defaults:
  datadir: "data"

hierarchy:
  [...]
    paths:
      - "domains/%{trusted.domain}.yaml"
      - "%{facts.architecture}.yaml"
      - "common.yaml"

And then in data/aarch64.yaml:

docker::repos::architecture: arm64

[fmichea]

Thanks! I got this to work and am unblocked now, really appreciate the help!

[carabasdaniel]

Closing issue as solution provided by @damonmaria resolved the problem

[zenitraM]

Hi, despite the workaround this is still a bug, even more that aarch64 on Ubuntu 20.04 is now a supported architecture for the Puppet agent.

For our usecase we depend on the docker module from another module, which makes overriding the attribute using Hiera data binding or depending on the docker::repos class tricky.
Wonder if the architecture parameter here could be exposed as a module parameter from the main docker class, the same way: package_location, package_key_source are:

puppetlabs-docker/manifests/repos.pp

Lines 12 to 15 in c741a9c

	$location = $docker::package_location,
	$key_source = $docker::package_key_source,
	$key_check_source = $docker::package_key_check_source,
	$architecture = $facts['os']['architecture'],

Nevertheless this issue would still affect all Puppet modules that are using $facts['architecture'] directly as hardcoded APT architecture as on ARM64 the kernel arch does not match the dpkg arch, as previously mentioned.

Our workaround is maybe a bit of a bigger hammer -- but still works, we're using a resource collector to overwrite all APT sources with a wrong arch to the correct one:

  Apt::Source <| architecture == 'aarch64' |> { architecture => 'arm64' }

[mpdude]

I guess this also impacts users running Linux on AWS Gravitron instances or Linux VMs on Apple M1 hardware.

[mpdude]

Maybe puppetlabs/puppetlabs-apt#1012 can also help address this.

[smortex]

Reopening to link to #898