Docker version is currently 20.10.5+dfsg1 which is less than 18.2.0 error message

[Paulzie]

New build of an IOTMenu Stack on new hardware running a fresh install of Bullseye 32 bit.

Brand new install of IOTMenu, docker installed by IOTMenu

IOTMenu is notifying me of an out of date Docket install

Message:-
############################
Docker version is currently 20.10.5+dfsg1 which is less than 18.2.0
consider upgrading or you may experience issues. You will not be prompted
again. You can manually upgrade by typing:
sudo apt upgrade docker docker-compose

Attempt to upgrade now?
###########################

If I click yes, an install is run, but after a reboot, the same message appears again

If I exit IOTMenu
###########################
Checking for project update
From https://github.com/SensorsIot/IOTstack

• branch master -> FETCH_HEAD
  Project is up to date
  Python Version: 'Python 3.9.2'. Python is up to date.
  ruamel.yaml Version: 'ruamel.yaml 0.16.12'. ruamel.yaml is up to date.
  Blessed Version: 'blessed 1.19.0'. Blessed is up to date.
  Please enter sudo pasword if prompted
  Command: docker version -f "{{.Server.Version}}"
  Project dependencies not up to date. Menu may crash.
  To be prompted to update again, run command:
  rm .docker_notinstalled || rm .docker_outofdate || rm .project_outofdate
  ###########################

###########################
~/IOTstack $ sudo apt upgrade docker docker-compose
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
docker is already the newest version (1.5-2).
docker-compose is already the newest version (1.25.0-1).
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
libfuse2 libslirp0 slirp4netns
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
###########################

Not causing me any issues but thought should raise it

[Paraphraser]

Long story short, there are some problems with the various IOTstack-provided installation mechanisms, by which I mean the so-called:

• "automatic" method (curl piped to bash); and
• "manual" method (letting the menu do the work of both the initial install and routine maintenance).

It's not so much that there's anything really seriously wrong. It just seems to me that the actual result you get depends on where you start (clean system vs migrated system vs re-installing in an existing system) and the order in which you do things subsequently.

Here is what I recommend. First, make sure IOTstack is up-to-date against GitHub:

$ cd ~/IOTstack
$ git checkout master
$ git pull

If you get any errors because files of yours are blocking updates coming from GitHub, you need to resolve those. I generally advise moving your own file out of the way. As an example, let's suppose you had changed the menu. The approach would be:

$ mv menu.sh menu.sh.old
$ git pull
$ diff menu.sh menu.sh.old

and then, figure out from the diff whether you needed to re-apply any of your own changes.

Next, do a quick read through this gist Installing Docker for IOTstack.

Then:

1. Follow the instructions for uninstalling docker and docker-compose
2. Follow the instructions for reinstalling everything properly

As an alternative, for the commands given in #2 above, there's a script in this response to Issue 442. If you:

• want to run Supervised Home Assistant, call the script as shown in Issue 442:

   $ export HOME_ASSISTANT_SUPERVISED_INSTALL=true
   $ ./install-the-lot.sh
  

• don't want to run Supervised Home Assistant, call the script as:

   $ export HOME_ASSISTANT_SUPERVISED_INSTALL=false
   $ ./install-the-lot.sh
  

What we are actually doing by clobbering everything and then installing everything outside of the menu is creating the conditions where the menu thinks everything has been installed properly so it won't try to do anything. That gives you a stable, reliable and predicable basis to work from.

At the moment, I'm focusing on updating PiBuilder because that's something I control and it doesn't need to be the subject of Pull Requests. The Issue 442 script came from that work. One day I'll try to find the time to ferret through everything the menu does and sort it out but it won't be "soon". That's probably not what you wanted to hear. Sorry.

Anyway, I hope this helps you overcome these problems.

---

$ docker version
Client: Docker Engine - Community
 Version:           20.10.10
 API version:       1.41
 Go version:        go1.16.9
 Git commit:        b485636
 Built:             Mon Oct 25 07:42:33 2021
 OS/Arch:           linux/arm
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.10
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.9
  Git commit:       e2f740d
  Built:            Mon Oct 25 07:40:50 2021
  OS/Arch:          linux/arm
  Experimental:     false
 containerd:
  Version:          1.4.11
  GitCommit:        5b46e404f6b9f661a205e28d59c982d3634148f8
 runc:
  Version:          1.0.2
  GitCommit:        v1.0.2-0-g52b36a2
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

$ docker-compose version
docker-compose version 1.29.2, build unknown
docker-py version: 5.0.3
CPython version: 3.9.2
OpenSSL version: OpenSSL 1.1.1k  25 Mar 2021

[slash-aka-eric]

For this particular issue, the problem is due to the trailing "+dfsg1" in the version string particularly the plus sign.

Fix is to modify both bash script and python file to cater for this "new" pattern.

For "menu.sh"
Change:
DOCKER_VERSION_BUILD=$(echo "$DOCKER_VERSION_BUILD"| cut -f1 -d"-")
To:
DOCKER_VERSION_BUILD=$(echo "$DOCKER_VERSION_BUILD"| cut -f1 -d"-" -d"+")

For "scripts/deps/version_check.py"
Add import re to the top of the line (Build-in regular expression library)
Change:
currentBuild = currentSplit[2].split("-")[0]
To:
currentBuild = re.split(r'[+-]', currentSplit[2])[0]

[Paraphraser]

@slash-aka-eric - please go ahead and prepare a Pull Request for this because, regardless of what I'm going to say in a moment, it's a useful protective measure.

If you're unfamiliar with the process, please see this gist.

However, I still don't understand the original cause of the problem. This is what I see on my own system:

$ cat /proc/device-tree/model
Raspberry Pi 4 Model B Rev 1.1
$ uname -a
Linux sec-dev 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux
$ grep "PRETTY_NAME" /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
$ docker version -f "{{.Server.Version}}"
20.10.11

That docker version command is the starting point in the menu - line 258

I ran those commands both before and after a sudo apt update; sudo apt upgrade -y. In the "before" situation, the docker version returned:

20.10.10

The apt upgrade included:

Setting up containerd.io (1.4.12-1) ...
Setting up docker-ce-cli (5:20.10.11~3-0~raspbian-bullseye) ...
Setting up docker-ce-rootless-extras (5:20.10.11~3-0~raspbian-bullseye) ...
Setting up docker-ce (5:20.10.11~3-0~raspbian-bullseye) ...

and that explains why I'm now seeing:

20.10.11

But I'm not seeing any +dfsg1 suffix, either before or after.

This is a fresh Bullseye build (done on Nov 13), Docker installed via the "convenience script", fully up-to-date as of right now.

Why are some people seeing this +dfsg1 suffix? Where is it coming from?

My main concern is that if we don't understand the cause, we (a) won't know whether the simple presence of +dfsg1 should be treated as an indication of an improper installation, or (b) whether tomorrow will see someone else having problems with, say, "=xyz5" being tacked onto the end.

[slash-aka-eric]

@Paraphraser Agree with you that we should probably investigate why in some cases the +dfsg1 appears.

Here's my environment details for reference.
Note that I'm using 64bit OS and I did a direct upgrade from Buster to Bullseye.

cat /proc/device-tree/model
Raspberry Pi 4 Model B Rev 1.4

uname -a
Linux slashhome 5.10.63-v8+ #1459 SMP PREEMPT Wed Oct 6 16:42:49 BST 2021 aarch64 GNU/Linux

grep "PRETTY_NAME" /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"

docker version -f "{{.Server.Version}}"
20.10.5+dfsg1

[Paraphraser]

I did also try the 64-bit kernel but it didn't change the result. I have not tried a Buster-to-Bullseye upgrade so maybe that's the clue. If it were me, I'd be contemplating 20.10.5 vs 20.10.11 and trying an apt upgrade. If that didn't fix the problem, I'd move to uninstall/reinstall Docker.

By "fix", I mean either 20.10.11 or 20.10.11+dfsg1

Seems to me if the 5 won't budge to 11 that implies something hosed under the hood.

Just my two cents.

[tcottle]

I did a fresh install on a Pi4 this morning. Downloaded an image using the Pi Imager, updated and ran the automatic script

`cat /proc/device-tree/model
Raspberry Pi 4 Model B Rev 1.1

uname -a
Linux RPi4 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux

grep "PRETTY_NAME" /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"

docker -v
Docker version 20.10.5+dfsg1, build 55c4c88
`

I also have several other Pi3/4s and they all report docker @ 20.10.5+dfsg1

[tcottle]

Interesting. I followed the link and ran the uninstall commands that was referenced earlier. A couple messages that docker-ce-cli and docker-compose was not installed so not removed.

Then followed the install steps
curl -fsSL https://get.docker.com | sudo sh
docker -v yields
Docker version 20.10.11, build dea9396

The next two usermod steps when fine

After this competes
sudo apt install -y docker-compose
Docker -v yields
Docker version 20.10.5+dfsg1, build 55c4c88

[Paraphraser]

Although I can't tell you why installing docker-compose changes the docker version, your last post definitely explains why I am not seeing this problem on my own systems.

The clue is using apt to install docker-compose. I realise that's how the IOTstack installation/update processes have always done it but those are wrong. You have always gotten an obsolete docker-compose if you let apt do it. Maybe I should qualify that statement: apt gets an obsolete version under Buster. I haven't tried it under Bullseye.

Earlier in this issue thread I pointed to Issue 442 which contains a script that shows how to do it with pip so you get an up-to-date version that is being maintained.

Yesterday I committed changes to PiBuilder which use that same approach as Issue 442 (the script in that issue was a stop-gap based on work I had already done for PiBuilder's 04 script).

If you build a Pi using PiBuilder, everything gets set up and the IOTstack repo is cloned, ready to roll. That all happens without running the menu so the menu never gets a chance to stuff things up. The first time you launch the menu, all its tests succeed and it doesn't try to do anything except present you with the opportunity to build a stack. If you already have a backup of a running IOTstack you can restore it and get going without launching the menu at all.

Meanwhile, in what could be considered a classic "open my mouth and blow my whole foot clean off" move, I went looking for a reference URL in the Docker documentation showing the how-to of installing docker-compose using pip. You know - the URL I found and followed waaay back that was the basis for what I'm doing in PiBuilder.

Well, I found that link and, guess what, the pip method is now deprecated for Linux and we have a new curl piped to shell. 🤦 I now have to test that and get it into PiBuilder.

Maybe there will come a period of time where the goal-posts stop moving long enough that I can sit down and fix how IOTstack does it so this whole problem goes away. Get the multiple scattered installation and update scripts down to a single script. I'm not holding my breath.

Anyway, see install compose on Linux.

[Paraphraser]

But wait, there's more…

Starting at Install Compose, we have tabs for Mac, Windows, Windows Server, Linux and "Alternative install options".

Clicking Alternative install options gets us to "if you are not using virtualenv":

$ sudo pip install docker-compose

which is what PiBuilder and the Issue 442 script are doing.

Going back one step to the Install on Linux link gets us:

$ sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

Heading to the root URL github.com/docker/compose/releases yields the information that v2.2.0 is a pre-release with 2.1.1 being the latest.

On all of my systems, docker-compose version returns "1.29.2". Those answers span Buster, Bullseye, 32- and 64-bit kernels, really recent builds (two weeks) and fairly ancient builds where I've done the occasional sudo pip3 install -U docker-compose.

The material point is that "1.29.2" gets a lot of ink. It is mentioned in both the "Install on Linux" formula and is what you get if you install compose on Raspbian using pip. To paraphrase (no pun intended) Doc Brown in Back To The Future, it's like 1.29.2 represents some kind of nexus in the space-time continuum.

For the purposes of this discussion, I rewrote the "install compose on Linux" command as a script named fetch-docker-compose.sh:

#!/usr/bin/env bash

VERSION="${1:-1.29.2}"
SUFFIX="docker-compose-$(uname -s)-$(uname -m)"
TARGET="$SUFFIX-$VERSION"
URL="https://github.com/docker/compose/releases/download/$VERSION/$SUFFIX"

echo "VERSION=$VERSION"
echo "SUFFIX=$SUFFIX"
echo "TARGET=$TARGET"
echo "URL=$URL"
curl -L "$URL" -o "$TARGET"
hexdump -C "$TARGET" | head

For reference, here's a test on macOS:

$ ./fetch-docker-compose.sh 
VERSION=1.29.2
SUFFIX=docker-compose-Darwin-x86_64
TARGET=docker-compose-Darwin-x86_64-1.29.2
URL=https://github.com/docker/compose/releases/download/1.29.2/docker-compose-Darwin-x86_64
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   665  100   665    0     0   1936      0 --:--:-- --:--:-- --:--:--  1933
100  9.9M  100  9.9M    0     0  1652k      0  0:00:06  0:00:06 --:--:-- 1727k
00000000  cf fa ed fe 07 00 00 01  03 00 00 80 02 00 00 00  |................|
00000010  0f 00 00 00 00 07 00 00  85 00 20 00 00 00 00 00  |.......... .....|
00000020  19 00 00 00 48 00 00 00  5f 5f 50 41 47 45 5a 45  |....H...__PAGEZE|
00000030  52 4f 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |RO..............|
00000040  00 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  19 00 00 00 28 02 00 00  |............(...|
00000070  5f 5f 54 45 58 54 00 00  00 00 00 00 00 00 00 00  |__TEXT..........|
00000080  00 00 00 00 01 00 00 00  00 70 00 00 00 00 00 00  |.........p......|
00000090  00 00 00 00 00 00 00 00  00 70 00 00 00 00 00 00  |.........p......|

That's a Mach-O 64-bit executable. I can work with that:

$ chmod +x docker-compose-Darwin-x86_64-1.29.2
$ ./docker-compose-Darwin-x86_64-1.29.2 version
docker-compose version 1.29.2, build 5becea4c
docker-py version: 5.0.0
CPython version: 3.9.0
OpenSSL version: OpenSSL 1.1.1h  22 Sep 2020

Let's repeat the trick with version 2.1.1 which, according to GitHub is the latest:

$ ./fetch-docker-compose.sh 2.1.1
VERSION=2.1.1
SUFFIX=docker-compose-Darwin-x86_64
TARGET=docker-compose-Darwin-x86_64-2.1.1
URL=https://github.com/docker/compose/releases/download/2.1.1/docker-compose-Darwin-x86_64
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100     9  100     9    0     0     24      0 --:--:-- --:--:-- --:--:--    24
00000000  4e 6f 74 20 46 6f 75 6e  64                       |Not Found|
00000009

Well, that's a bit weird. Comparing/contrasting the URLs to the two assets pages:

• https://github.com/docker/compose/releases/tag/1.29.2
• https://github.com/docker/compose/releases/tag/v2.1.1

reveals a pesky "v" has shown up. The same for the direct URLs on those pages:

• https://github.com/docker/compose/releases/download/v2.1.1/docker-compose-darwin-x86_64
• https://github.com/docker/compose/releases/download/1.29.2/docker-compose-Darwin-x86_64

OK. Retry with a "v".

$ ./fetch-docker-compose.sh v2.1.1
VERSION=v2.1.1
SUFFIX=docker-compose-Darwin-x86_64
TARGET=docker-compose-Darwin-x86_64-v2.1.1
URL=https://github.com/docker/compose/releases/download/v2.1.1/docker-compose-Darwin-x86_64
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   665  100   665    0     0   1756      0 --:--:-- --:--:-- --:--:--  1759
100 26.0M  100 26.0M    0     0  4500k      0  0:00:05  0:00:05 --:--:-- 6153k
00000000  cf fa ed fe 07 00 00 01  03 00 00 00 02 00 00 00  |................|
00000010  0c 00 00 00 88 07 00 00  00 00 00 00 00 00 00 00  |................|
00000020  19 00 00 00 48 00 00 00  5f 5f 50 41 47 45 5a 45  |....H...__PAGEZE|
00000030  52 4f 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |RO..............|
00000040  00 00 00 01 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  19 00 00 00 78 02 00 00  |............x...|
00000070  5f 5f 54 45 58 54 00 00  00 00 00 00 00 00 00 00  |__TEXT..........|
00000080  00 00 00 01 00 00 00 00  00 80 6e 01 00 00 00 00  |..........n.....|
00000090  00 00 00 00 00 00 00 00  00 80 6e 01 00 00 00 00  |..........n.....|

Cookin' with renewably-produced hydrogen!

$ chmod +x docker-compose-Darwin-x86_64-v2.1.1
$ ./docker-compose-Darwin-x86_64-v2.1.1 version
Docker Compose version v2.1.1

Let's switch focus to the Pi. There's no point trying version 1.29.2 because the Assets page shows no such thing as armv6, v7 or aarch64. We'll stick to v2.1.1 and see what happens.

First cab off the rank: Buster, 32-bit kernel.

$ ./fetch-docker-compose.sh v2.1.1
VERSION=v2.1.1
SUFFIX=docker-compose-Linux-armv7l
TARGET=docker-compose-Linux-armv7l-v2.1.1
URL=https://github.com/docker/compose/releases/download/v2.1.1/docker-compose-Linux-armv7l
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100     9  100     9    0     0     25      0 --:--:-- --:--:-- --:--:--    25
00000000  4e 6f 74 20 46 6f 75 6e  64                       |Not Found|
00000009

The direct URL is:

• https://github.com/docker/compose/releases/download/v2.1.1/docker-compose-linux-armv7

Now we have a pesky missing "l" from the end of "armv7l". A script mod is called for:

#!/usr/bin/env bash

VERSION="${1:-1.29.2}"
MACHINE="$(uname -m)"
[ "$MACHINE" = "armv7l" ] && MACHINE="armv7"
SUFFIX="docker-compose-$(uname -s)-$MACHINE"
TARGET="$SUFFIX-$VERSION"
URL="https://github.com/docker/compose/releases/download/$VERSION/$SUFFIX"

echo "VERSION=$VERSION"
echo "SUFFIX=$SUFFIX"
echo "TARGET=$TARGET"
echo "URL=$URL"
curl -L "$URL" -o "$TARGET"
hexdump -C "$TARGET" | head

Retry:

$ ./fetch-docker-compose.sh v2.1.1
VERSION=v2.1.1
SUFFIX=docker-compose-Linux-armv7
TARGET=docker-compose-Linux-armv7-v2.1.1
URL=https://github.com/docker/compose/releases/download/v2.1.1/docker-compose-Linux-armv7
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   663  100   663    0     0   1932      0 --:--:-- --:--:-- --:--:--  1938
100 20.6M  100 20.6M    0     0  3888k      0  0:00:05  0:00:05 --:--:-- 5495k
00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 28 00 01 00 00 00  c8 be 07 00 34 00 00 00  |..(.........4...|
00000020  14 01 00 00 02 00 00 05  34 00 20 00 07 00 28 00  |........4. ...(.|
00000030  0e 00 03 00 06 00 00 00  34 00 00 00 34 00 01 00  |........4...4...|
00000040  34 00 01 00 e0 00 00 00  e0 00 00 00 04 00 00 00  |4...............|
00000050  00 00 01 00 04 00 00 00  9c 0f 00 00 9c 0f 01 00  |................|
00000060  9c 0f 01 00 64 00 00 00  64 00 00 00 04 00 00 00  |....d...d.......|
00000070  04 00 00 00 01 00 00 00  00 00 00 00 00 00 01 00  |................|
00000080  00 00 01 00 64 dc a8 00  64 dc a8 00 05 00 00 00  |....d...d.......|
00000090  00 00 01 00 01 00 00 00  00 00 a9 00 00 00 aa 00  |................|

$ chmod +x docker-compose-Linux-armv7-v2.1.1 
$ ./docker-compose-Linux-armv7-v2.1.1 version
Docker Compose version v2.1.1

Bingo! Next cab is Buster with 64-bit kernel:

$ ./fetch-docker-compose.sh v2.1.1
VERSION=v2.1.1
SUFFIX=docker-compose-Linux-aarch64
TARGET=docker-compose-Linux-aarch64-v2.1.1
URL=https://github.com/docker/compose/releases/download/v2.1.1/docker-compose-Linux-aarch64
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   665  100   665    0     0   1900      0 --:--:-- --:--:-- --:--:--  1894
100 23.1M  100 23.1M    0     0  4625k      0  0:00:05  0:00:05 --:--:-- 6634k
00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 b7 00 01 00 00 00  c0 a1 07 00 00 00 00 00  |................|
00000020  40 00 00 00 00 00 00 00  c8 01 00 00 00 00 00 00  |@...............|
00000030  00 00 00 00 40 00 38 00  07 00 40 00 0e 00 03 00  |....@.8...@.....|
00000040  06 00 00 00 04 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000050  40 00 01 00 00 00 00 00  40 00 01 00 00 00 00 00  |@.......@.......|
00000060  88 01 00 00 00 00 00 00  88 01 00 00 00 00 00 00  |................|
00000070  00 00 01 00 00 00 00 00  04 00 00 00 04 00 00 00  |................|
00000080  9c 0f 00 00 00 00 00 00  9c 0f 01 00 00 00 00 00  |................|
00000090  9c 0f 01 00 00 00 00 00  64 00 00 00 00 00 00 00  |........d.......|

$ chmod +x docker-compose-Linux-aarch64-v2.1.1 
$ ./docker-compose-Linux-aarch64-v2.1.1 version
Docker Compose version v2.1.1

And, finally, Bullseye with 64-bit kernel:

$ ./fetch-docker-compose.sh v2.1.1
VERSION=v2.1.1
SUFFIX=docker-compose-Linux-aarch64
TARGET=docker-compose-Linux-aarch64-v2.1.1
URL=https://github.com/docker/compose/releases/download/v2.1.1/docker-compose-Linux-aarch64
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   665  100   665    0     0   7388      0 --:--:-- --:--:-- --:--:--  7471
100 23.1M  100 23.1M    0     0  4421k      0  0:00:05  0:00:05 --:--:-- 5826k
00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 b7 00 01 00 00 00  c0 a1 07 00 00 00 00 00  |................|
00000020  40 00 00 00 00 00 00 00  c8 01 00 00 00 00 00 00  |@...............|
00000030  00 00 00 00 40 00 38 00  07 00 40 00 0e 00 03 00  |....@.8...@.....|
00000040  06 00 00 00 04 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000050  40 00 01 00 00 00 00 00  40 00 01 00 00 00 00 00  |@.......@.......|
00000060  88 01 00 00 00 00 00 00  88 01 00 00 00 00 00 00  |................|
00000070  00 00 01 00 00 00 00 00  04 00 00 00 04 00 00 00  |................|
00000080  9c 0f 00 00 00 00 00 00  9c 0f 01 00 00 00 00 00  |................|
00000090  9c 0f 01 00 00 00 00 00  64 00 00 00 00 00 00 00  |........d.......|

$ chmod +x docker-compose-Linux-aarch64-v2.1.1 
$ ./docker-compose-Linux-aarch64-v2.1.1 version
Docker Compose version v2.1.1

While I could change PiBuilder, the Issue 442 script and, eventually, IOTstack's scripts to do the "if this is armv7l substitute armv7" it seems to me that this is a problem the docker-compose folks should know about. I'm no architecture guru so I don't know whether the releases page should change to use armv7l or if it really needs both armv7 and armv7l.

I've opened Issue 8966 and will wait to see what they come back with.

On a related note, the "v2.1.1" part of the URL can't be replaced with "latest", which means we have another maintenance problem to deal with. Supervised Home Assistant is the same. Sigh.