Open damonmaria opened 5 years ago
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.
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.
@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 :)
@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
Thanks! I got this to work and am unblocked now, really appreciate the help!
Closing issue as solution provided by @damonmaria resolved the problem
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:
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' }
I guess this also impacts users running Linux on AWS Gravitron instances or Linux VMs on Apple M1 hardware.
Maybe https://github.com/puppetlabs/puppetlabs-apt/pull/1012 can also help address this.
Reopening to link to #898
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:For
apt
the correct architecture for 64-bit ARM isarm64
.How to reproduce it?
Anything else we need to know?
To workaround this I have to add:
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 returningarm64
. So I'm not sure what the correct fact would be or how other modules handle this.Versions:
Logs:
Run with
--debug
here