Docker version is currently 20.10.5+dfsg1 which is less than 18.2.0 error message #447
Comments
|
Long story short, there are some problems with the various IOTstack-provided installation mechanisms, by which I mean the so-called:
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:
Next, do a quick read through this gist Installing Docker for IOTstack. Then:
As an alternative, for the commands given in #2 above, there's a script in this response to Issue 442. If you:
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. |
|
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" For "scripts/deps/version_check.py" |
|
@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.
However, I still don't understand the original cause of the problem. This is what I see on my own system:
I ran those commands both before and after a The and that explains why I'm now seeing: But I'm not seeing any 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 My main concern is that if we don't understand the cause, we (a) won't know whether the simple presence of |
|
@Paraphraser Agree with you that we should probably investigate why in some cases the Here's my environment details for reference. |
|
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. |
|
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 uname -a grep "PRETTY_NAME" /etc/os-release docker -v I also have several other Pi3/4s and they all report docker @ 20.10.5+dfsg1 |
|
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 The next two usermod steps when fine After this competes |
|
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 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. |
|
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": which is what PiBuilder and the Issue 442 script are doing. Going back one step to the Install on Linux link gets us: 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,
For the purposes of this discussion, I rewrote the "install compose on Linux" command as a script named #!/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" | headFor reference, here's a test on macOS: That's a Mach-O 64-bit executable. I can work with that: Let's repeat the trick with version 2.1.1 which, according to GitHub is the latest: Well, that's a bit weird. Comparing/contrasting the URLs to the two assets pages:
reveals a pesky "v" has shown up. The same for the direct URLs on those pages:
OK. Retry with a "v". Cookin' with renewably-produced hydrogen! 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. The direct URL is: Now we have a pesky missing "l" from the end of "armv7l". A script mod is called for: Retry: Bingo! Next cab is Buster with 64-bit kernel: And, finally, Bullseye with 64-bit kernel: 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. |
Debian apt installs docker version with a postfix. E.g. "20.10.5+dfsg1" Ignore this when checking for version. Fixes SensorsIot#496 Fixes SensorsIot#447
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
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
The text was updated successfully, but these errors were encountered: