docker/containerd/runc version compatability

docker/containerd/runc version compatability

[Ralph Siemsen]

Perhaps someone here can help point me to relevant documentation. I'm
wondering if there are some guidelines about which version(s) of
docker/containerd/runc are compatible. I've searched through the
docker manuals and release notes, without finding very many details.

Backing up a step further, the dunfell branch of meta-virtualization
has docker-moby 19.03.15, containerd-v1.2.14, and runc-1.0.0-rc8. This
combination seems to work fine, however there are several CVEs
flagged.

In a somewhat naive attempt to fix some of the CVEs, I updated
containerd from 1.2.x to v1.4.12. This version was picked primarily
because it was available in gatesgarth at the time, I could just copy
the recipe over. This compiles and runs hello-world and ubuntu test
images successfully.

However over time, an oddity has emerged: even with no images
downloaded and therefore no containers running (just the daemon
sitting idle), the system log shows a goroutine crashing periodically
with "fatal error: bad symbol table". It can take up to 10 hours, but
usually happens within an hour, on an otherwise idle system.

This did not happen with the original set of versions on the dunfell
branch. So I'm wondering what versions can be combined? What other
tests (besides downloading and starting a container) could be run to
check that the chosen versions are working together correctly?

Any hints or advice would be appreciated!
Ralph

Re: [meta-virtualization] docker/containerd/runc version compatability

[Bruce Ashfield]

On Mon, Jul 11, 2022 at 2:13 PM Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
>
> Perhaps someone here can help point me to relevant documentation. I'm
> wondering if there are some guidelines about which version(s) of
> docker/containerd/runc are compatible. I've searched through the
> docker manuals and release notes, without finding very many details.
>
> Backing up a step further, the dunfell branch of meta-virtualization
> has docker-moby 19.03.15, containerd-v1.2.14, and runc-1.0.0-rc8. This
> combination seems to work fine, however there are several CVEs
> flagged.
>
> In a somewhat naive attempt to fix some of the CVEs, I updated
> containerd from 1.2.x to v1.4.12. This version was picked primarily
> because it was available in gatesgarth at the time, I could just copy
> the recipe over. This compiles and runs hello-world and ubuntu test
> images successfully.

FWIW, that's more than just bug fixes, so we wouldn't want that
much of a version bump on any of the -stable branches. They'd
stay within the .x series of a release.

>
> However over time, an oddity has emerged: even with no images
> downloaded and therefore no containers running (just the daemon
> sitting idle), the system log shows a goroutine crashing periodically
> with "fatal error: bad symbol table". It can take up to 10 hours, but
> usually happens within an hour, on an otherwise idle system.
>
> This did not happen with the original set of versions on the dunfell
> branch. So I'm wondering what versions can be combined? What other
> tests (besides downloading and starting a container) could be run to
> check that the chosen versions are working together correctly?

What you are describing is exactly why you'll see me in the list archives
telling folks that there's no need to send updates to the individual
packages in master. I do unified testing on all the various components
in about the m3 timeframe of a release. The -stable branches are
updated for CVEs/bugs only and get updates at a much slower cadence.

The dependencies/versions are documented within the projects
themselves, but they aren't tightly coupled (for the most part) so
there is some flex.  But honestly, it is often that the latest of all the
projects work together at any given point, so when I do the updates
that is fundamentally the known set of working versions. Otherwise,
you are into looking at the project and their documented dependencies
on the various components. (or looking at what other distros are doing,
etc).

The larger stacks (i.e. k3s) are what I use to drive more complex
and end to end testing with the components. But fetching a container
and running it is a good test and covers a lot of ground.

Bruce


>
> Any hints or advice would be appreciated!
> Ralph
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#7435): https://lists.yoctoproject.org/g/meta-virtualization/message/7435
> Mute This Topic: https://lists.yoctoproject.org/mt/92316357/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II