OK, looks like some changes are needed;

0.345 + go build -mod=vendor -modfile=vendor.mod -o /tmp/bundles/dynbinary-daemon/dockerd -tags ' journald' -buildmode=pie -ldflags '-w -X "github.com/docker/docker/dockerversion.Version=dev" -X "github.com/docker/docker/dockerversion.GitCommit=HEAD" -X "github.com/docker/docker/dockerversion.BuildTime=2024-04-03T12:29:20.000000000+00:00" -X "github.com/docker/docker/dockerversion.PlatformName=" -X "github.com/docker/docker/dockerversion.ProductName=" -X "github.com/docker/docker/dockerversion.DefaultProductLicense="   ' -gcflags= github.com/docker/docker/cmd/dockerd
57.03 # github.com/docker/docker/daemon
57.03 daemon/oci_linux.go:828:29: undefined: cgroups.GetInitCgroup

Relates to opencontainers/runc@fd5debf

• libct/cg: rm GetInitCgroup[Path] opencontainers/runc#3810

Trying to figure out what the replacement would be; it looks like we're currently checking both a parent path and "own";

This commit / comment may be related as well; opencontainers/runc@54e2021

libctr/cgroups: don't take init's cgroup into account

Sometimes, the init process is not in the root cgroup.
This can be noted by GetInitPath, which already scrubs the path of init.scope.

This was encountered when trying to patch the Kubelet to handle systemd being in a separate cpuset
from root (to allow load balance disabling for containers). At present, there's no way to have libcontainer or runc
manage cgroups in a hierarchy outside of the one init is in (unless the path contains init.scope, which is limiting)