Re: [Buildroot] [PATCH v1 1/1] package/containerd: bump version to v1.6.22

From: Stefan Agner <stefan@agner.ch>
To: Christian Stewart <christian@aperture.us>
Cc: "Yann E . MORIN" <yann.morin.1998@free.fr>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Buildroot Mailing List <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH v1 1/1] package/containerd: bump version to v1.6.22
Date: Mon, 25 Sep 2023 12:08:53 +0200	[thread overview]
Message-ID: <eb94fb2be140a706ce4797df9cb56d63@agner.ch> (raw)
In-Reply-To: <CA+h8R2o9eAVZBrzU1E8wbh_eoQfhWv+0JsH11_N4hrkPKqKCXg@mail.gmail.com>

Hi Christian,

Finally came around looking into this a bit more closely. It seems that
containerd just didn't send the sd notification READY=1.

It seems that the problem is caused by the CRI plug-in. The plug-in
reports the following error:
time="2023-09-24T21:43:20.958509027Z" level=warning msg="failed to load
plugin io.containerd.grpc.v1.cri" error="failed to create CRI service:
failed to create cni conf monitor for default: failed to create the
parent of the cni conf dir=/etc/cni: mkdir /etc/cni: read-only

We are running containerd on a read-only squashfs. I guess this explains
also why you haven't seen this issue.

After disabling the plug-in via /etc/containerd/config.toml
disabled_plugins = [ "cri" ], the issue disappeared (containerd service
starts up correctly and prints the message "containerd successfully
booted in ...s"

Checking the changelog of v1.6.22 brings up this change:
https://github.com/containerd/containerd/pull/8826

The error above was already present before, so I didn't give it much
attention. But I guess the change to use atomicfile really changed the
behavior and now seems to cause the hang on startup.

In any case, from my point of view, nothing which needs to be addressed
in Buildroot.

Best regards,
Stefan

On 2023-09-15 23:48, Christian Stewart wrote:
> Hi Stefan,
> 
> Did you find a solution to this? Just following up.
> 
> On Thu, Sep 7, 2023 at 11:21 PM Stefan Agner <stefan@agner.ch> wrote:
>> > I hate to say "works on my machine," but with both versions on aarch64 it works for me.
>> >
>> > Maybe the filesystem you are using is different? I'm using ext4. Or is the kernel config not set up quite right? Maybe old kernel?
>>
>> The root file system is a squashfs, but the data is stored on ext4.
>>
>> We are using the latest vanilla Linux kernel 6.1.52.
>>
>> It seems to hang here:
>> WARN[2023-09-08T06:17:38.515218691Z] waiting for response from boltdb
>> open         plugin=bolt
>>
>> From what I can tell it's some IPC mechanism or similar which is
>> hanging.
>>
>> I can also reproduce it on x86-64. I guess it must be unique to our
>> operating system configuration in some way...
> 
> Best,
> Christian
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot