Closed sayhiben closed 7 months ago
I'm going to attempt to pin the docker-in-docker
version back to 2.8.0
- I suspect something with 2.8.1
caused this, but I'm uncertain yet
edit: This didn't work. Apparently I misunderstood what the feature's version
attr references; it seems it actually controls the underlying Moby version:
#28 12.12 Reading package lists...#28 15.25 (!) No full or partial Docker / Moby version match found for "2.8.0" on OS ubuntu focal (amd64). Available versions:
#28 16.30 24.0.9-ubuntu20.04u1
#28 16.30 24.0.8-ubuntu20.04u1
#28 16.30 24.0.7-ubuntu20.04u1
#28 16.30 23.0.7+azure-ubuntu20.04u1
#28 16.30 23.0.6+azure-ubuntu20.04u2
#28 16.30 20.10.25+azure-ubuntu20.04u2
#28 16.30 20.10.25+azure-ubuntu20.04u1
...
I'm going to try changing to 20.10.25+azure-ubuntu20.04u2
and see what happens
edit2: That version is either the same or is similarly not working
Just commenting to document that I'm running into the same issue, but with debian bookworm (arm64). The host machine is an Apple Silicon device. Neither downgrading the docker-in-docker feature or clearing any local caches resolves the issue.
Also running into this issue. Apple Silicon, Debian Bullseye
Also have the same issue
It appears that the issue here is Microsoft's package repository claiming the package should be one size but the downloaded package being another size, and then Ubuntu / apt being unhappy with the mismatch. Some quick searching says this likely has to be fixed on Microsoft's package repo
Here's a bash script that can be run to reproduce this issue locally (at least, on one of my still-working Codespaces in ubuntu focal):
edit: It does not matter what the version suffixes are set to; the issue is moby-buildx 0.12.1 failing its checksum in apt due to a filesize/SHA difference versus what's defined in Microsoft's package registry here. This could be indicative of a supply chain attack (unlikely, but possible)
#!/bin/bash
set -xeuo pipefail
MICROSOFT_GPG_KEYS_URI='https://packages.microsoft.com/keys/microsoft.asc'
VERSION_CODENAME='focal'
ID='ubuntu'
architecture=$(dpkg --print-architecture)
engine_package_name="moby-engine"
cli_package_name="moby-cli"
# Import key safely and import Microsoft apt repo
curl -sSL ${MICROSOFT_GPG_KEYS_URI} | gpg --dearmor > /usr/share/keyrings/microsoft-archive-keyring.gpg
echo "deb [arch=${architecture} signed-by=/usr/share/keyrings/microsoft-archive-keyring.gpg] https://packages.microsoft.com/repos/microsoft-${ID}-${VERSION_CODENAME}-prod ${VERSION_CODENAME} main" > /etc/apt/sources.list.d/microsoft.list
apt-get update
engine_version_suffix='=20.10.25+azure-ubuntu20.04u2'
cli_version_suffix='=20.10.25+azure-ubuntu20.04u2'
apt-get -y install --allow-downgrades --no-install-recommends moby-cli${cli_version_suffix} moby-buildx moby-engine${engine_version_suffix}
Here's where things are going off the rails - docker-in-docker attempts to download the latest version of moby-buildx
which has the following entry in Microsoft's package registry:
Package: moby-buildx
Version: 0.12.1-ubuntu20.04u1
Architecture: amd64
Section: admin
Priority: optional
Installed-Size: 75208
Maintainer: Microsoft <support@microsoft.com>
Description: A Docker CLI plugin for extended build capabilities with BuildKit
Homepage: https://github.com/docker/buildx
Conflicts: docker-buildx-plugin, docker-ce, docker-ee
Depends: libc6 (>= 2.3.4)
Recommends: moby-cli
Replaces: docker-buildx-plugin
SHA256: 0d1c7ac216d2a7d825b6fb0dbdec0f81d88540f1cc074d77abf4c0e7988f3e03
Size: 34091250
Filename: pool/main/m/moby-buildx/moby-buildx_0.12.1-ubuntu20.04u1_amd64.deb
The actual filesize of the downloaded package is 34152700
with SHA 707cfe4a1890e2e368e9b6b845c6d5359221287b2c4bb31873efc60a0ebbd15c
Microsoft needs to look at their registry and fix their Packages manifest. I believe we can fix the docker-in-docker feature by allowing for the moby-buildx package to have its version set via devcontainer.json, but that will require a PR and change in this repo that will likely be temporary
Thanks for reporting and providing a possible solution.
I believe we can fix the docker-in-docker feature by allowing for the moby-buildx package to have its version set via devcontainer.json, but that will require a PR and change in this repo that will likely be temporary
I'd quickly create a PR to temporary unblock everyone. Thanks for your patience.
@sayhiben Beat me to it, thanks for https://github.com/devcontainers/features/pull/838/ Reviewing!
Thanks for the assistance, @samruddhikhandale - for what it's worth, I believe this to also affect GitHub's ability to create their default Codespaces image using devcontainer/images for Universal linux
Thanks for the assistance, @samruddhikhandale - for what it's worth, I believe this to also affect GitHub's ability to create their default Codespaces image using devcontainer/images for Universal linux
The universal
image doesn't pull docker-in-docker
in real time, so I think we are good. We already have a good build of moby-buildx
and we don't plan to release the image until next week.
FYI - Folks who uses the Dev Container lockfiles, would need to manually run the devcontainer upgrade
command. Would recommend using Dependabot to create auto-PRs instead. Read https://containers.dev/guide/dependabot for details
Hey y'all,
just thought I'd mention that I was having the same issue with the docker-outside-of-docker feature but it can be solved with the option:
{
"installDockerBuildx": false // Defaults to true
}
so long as you don't require buildx
@leonitousconforti Good to know! It looks to me like that would only work in docker-outside-of-docker
because docker-in-docker
always uses moby-buildx
when Moby is enabled. I'm not sure if that's by design or just an oversight, however...
Hi there,
I manage a devcontainer config for Codespaces that uses the
ubuntu:focal
image (like the universal image does) alongside the latest docker-in-docker feature. As of around 10am Pacific time today, our Codespaces prebuilds began to fail with the following error:GitHub Actions Prebuild logs:
devcontainer.json:
Dockerfile: