On Mon, Jul 11, 2022 at 2:13 PM Ralph Siemsen <[email protected]> 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 > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#7440): https://lists.yoctoproject.org/g/meta-virtualization/message/7440 Mute This Topic: https://lists.yoctoproject.org/mt/92316357/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
