Wondering if anyone knows it there is a aarch64 version of docker alpine ?
The reason being that i am playing with the odroid-c2. Its Arm V8 (aarch64), and can run Docker on the host: https://archlinuxarm.org/platforms/armv8/amlogic/odroid-c2
So I need Arm based docker base image for my containers.
@joeblew99 The aarch64 process of alpine is on the way, see https://www.alpinelinux.org/sponsors/
We have aarch64 server up and running and there are aarch64 packages available now, so it should be possible to create docker base image.
I just created the image owlab/alpine-arm64
Is https://hub.docker.com/r/owlab/alpine-arm64/ satisfiable for now? I don't think we have a good way of building other arches at the moment.
Also related to #70 and #140. I think we would need an external builder for multiple arches first.
When I build a Dockerfile from owlab/alpline-arm64:edge and add a package, I get this error message. @owlab-exp can you look?
WARNING: Ignoring http://nl.alpinelinux.org/alpine/edge/main/aarch64/APKINDEX.tar.gz: BAD signature
WARNING: Ignoring http://nl.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz: BAD signature
Dockerfile follows:
FROM owlab/alpine-arm64:edge
RUN apk --no-cache add go
ENTRYPOINT ["go version"]
it might be related the switch to libressl.
I have access to a fast build machine (96 cores of ARMv8) but don't have a good handle on the build process, happy to help.
Tried to build on ARMv8 according to package directions and got this far:
emv@armv8hello:~/src/gliderlabs/docker-alpine$ ./build versions/gliderlabs-edge/options
Sending build context to Docker daemon 8.704 kB
Step 1 : FROM alpine:3.2
---> 07475f8c6d9d
Step 2 : COPY scripts/mkimage-alpine.bash scripts/apk-install /
---> Using cache
---> ac7d812a324b
Step 3 : RUN /apk-install bash tzdata
---> Running in 19a6dcc14e34
write pipe: bad file descriptor
The command '/bin/sh -c /apk-install bash tzdata' returned a non-zero code: 1
Open issue in Docker at https://github.com/docker/docker/issues/27614 and in Alpine Linux at https://bugs.alpinelinux.org/issues/6372
Today I have tried re-build the image - owlab/alpine-arm64:edge, with the same script I had used, but failed with the same issue of @vielmetti 's.
Upstream is looking at this with a possible fix soon. I will report back as there is news.
Upstream is reporting that this problem has been fixed, and I'm now able to build an Alpine Docker image.
@owlab-exp - can you try another rebuild and see if it works for you as well?
@vielmetti - I also succeeded minutes ago. Thanks for your efforts.
@joeblew99 - can you try @owlab-exp 's image from https://hub.docker.com/r/owlab/alpine-arm64/ ?
I anticipate that eventually we'll have an "official" test image at https://hub.docker.com/r/aarch64/alpine/
While I am rebuilding my other images based on the new alpine image, I had to remove "--no-cache" to install additional packages.
With "--no-cache", "apk add" complaints like this:
/ # apk add --update --no-cache gcc
fetch http://nl.alpinelinux.org/alpine/edge/main/aarch64/APKINDEX.tar.gz
fetch http://nl.alpinelinux.org/alpine/edge/main/aarch64/APKINDEX.tar.gz
WARNING: Ignoring http://nl.alpinelinux.org/alpine/edge/main/aarch64/APKINDEX.tar.gz: BAD signature
fetch http://nl.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz
ERROR: http://nl.alpinelinux.org/alpine/edge/community: BAD signature
fetch http://nl.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz
WARNING: Ignoring http://nl.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz: BAD signature
ERROR: unsatisfiable constraints:
binutils-libs-2.27-r0:
masked in: --no-network
satisfies: binutils-2.27-r0[so:libbfd-2.27.so] binutils-2.27-r0[so:libopcodes-2.27.so]
binutils-2.27-r0:
masked in: --no-network
satisfies: gcc-6.2.1-r1[binutils]
gmp-6.1.1-r0:
masked in: --no-network
satisfies: gcc-6.2.1-r1[so:libgmp.so.10] mpfr3-3.1.5-r0[so:libgmp.so.10] isl-0.17.1-r0[so:libgmp.so.10] mpc1-1.0.3-r0[so:libgmp.so.10]
isl-0.17.1-r0:
masked in: --no-network
satisfies: gcc-6.2.1-r1[isl] gcc-6.2.1-r1[so:libisl.so.15]
libgomp-6.2.1-r1:
masked in: --no-network
satisfies: gcc-6.2.1-r1[libgomp=6.2.1-r1] gcc-6.2.1-r1[libgomp=6.2.1-r1]
libatomic-6.2.1-r1:
masked in: --no-network
satisfies: gcc-6.2.1-r1[libatomic=6.2.1-r1]
libgcc-6.2.1-r1:
masked in: --no-network
satisfies: gcc-6.2.1-r1[libgcc=6.2.1-r1] gcc-6.2.1-r1[so:libgcc_s.so.1] libstdc++-6.2.1-r1[so:libgcc_s.so.1]
pkgconf-1.0.1-r0:
masked in: --no-network
satisfies: gcc-6.2.1-r1[pkgconfig]
mpfr3-3.1.5-r0:
masked in: --no-network
satisfies: gcc-6.2.1-r1[so:libmpfr.so.4] mpc1-1.0.3-r0[so:libmpfr.so.4]
mpc1-1.0.3-r0:
masked in: --no-network
satisfies: gcc-6.2.1-r1[so:libmpc.so.3]
libstdc++-6.2.1-r1:
masked in: --no-network
satisfies: gcc-6.2.1-r1[so:libstdc++.so.6]
gcc-6.2.1-r1:
masked in: --no-network
satisfies: world[gcc]
I'm also running into repo issues, even with --update:
/etc/apk # apk add --update easy-rsa
fetch http://nl.alpinelinux.org/alpine/edge/main/aarch64/APKINDEX.tar.gz
fetch http://nl.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz
ERROR: http://nl.alpinelinux.org/alpine/edge/community: BAD signature
WARNING: Ignoring APKINDEX.49e1404d.tar.gz: No such file or directory
fetch http://nl.alpinelinux.org/alpine/edge/testing/aarch64/APKINDEX.tar.gz
ERROR: http://nl.alpinelinux.org/alpine/edge/testing: BAD signature
WARNING: Ignoring APKINDEX.cbed5262.tar.gz: No such file or directory
fetch http://dl-4.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz
ERROR: http://dl-4.alpinelinux.org/alpine/edge/community: BAD signature
WARNING: Ignoring APKINDEX.e76b60f6.tar.gz: No such file or directory
ERROR: unsatisfiable constraints:
easy-rsa (missing):
required by: world[easy-rsa]
I've filed this bug upstream
https://bugs.alpinelinux.org/issues/6389
regarding the BAD signature issues.
If you do apk add --allow-untrusted it bypasses the signature check.
The upstream bug https://bugs.alpinelinux.org/issues/6389 has been marked as fixed, so this issue should be addressable again.
I'm going to close this as #324 is merged and should allow building of arm rootfs now (using a new -a flag to the builder). The builder itself is still a x86_64 image. Let me know if this doesn't work for your use case.