依赖循环错误源于包管理器无法解析a依赖b、b又依赖a的闭环，解决关键是清理残留、隔离源、显式安装containerd.io等最小依赖集，禁用epel等冲突源。

依赖循环错误在安装 docker engine 时并不罕见，本质是包管理器（如 yum 或 apt）在解析依赖关系时发现 a 依赖 b、b 又依赖 a，或多个包互相强约束版本，导致无法自动决策安装顺序。这不是配置错误，而是仓库元数据不一致或系统残留干扰的典型表现。解决关键在于“打破循环”而非强行跳过——通过清理、隔离、显式控制版本来重建可解的依赖图。

彻底清除历史残留组件

旧版 Docker 包（尤其是 docker-engine、docker.io、containerd.io 低版本）常自带冲突的 selinux-policy 或 fuse-overlayfs 依赖声明，引发循环。必须一步清空：

• CentOS/RHEL：执行 yum remove docker* containerd* runc，再运行 yum clean all && rm -rf /var/cache/yum
• Ubuntu/Debian：执行 apt purge docker* containerd runc，再运行 apt clean && rm -rf /var/lib/apt/lists/*
• 删除所有 Docker 相关 repo 文件：rm -f /etc/apt/sources.list.d/docker*.list（Ubuntu）或 rm -f /etc/yum.repos.d/docker-ce.repo（CentOS）

分步加载源与指定最小依赖集

不要用一条命令同时添加源 + 安装全部组件。循环常发生在 docker-ce-cli 和 containerd.io 版本协商阶段。应手动拆解：

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

• 先只添加 Docker 官方源（或阿里云镜像源），但不立即安装；
• 运行 yum list available --showduplicates | grep containerd.io（CentOS）或 apt list -a containerd.io（Ubuntu），确认可用版本；
• 查官方兼容矩阵（如 Docker CE 20.10.8 要求 containerd.io >= 1.4.12, ），然后<strong>只安装 containerd.io**一个包**</strong>：<code>yum install -y containerd.io-1.4.12；
• 再安装 docker-ce-cli 和 docker-ce，此时依赖已满足，不再触发循环校验。

禁用自动依赖解析（仅限紧急场景）

当明确知道循环由某个非核心包（如 docker-selinux）引发，且系统未启用 SELinux 时，可临时绕过：

• CentOS 7：yum install --setopt=obsoletes=0 -y docker-ce-20.10.8 docker-ce-cli-20.10.8 containerd.io-1.4.12
• Ubuntu：下载对应 .deb 包后，用 dpkg --force-depends -i *.deb 安装，之后立即运行 apt --fix-broken install 补全其余依赖。
• ⚠️ 注意：此法不推荐作为常规流程，仅用于验证是否为某特定包导致循环。

检查并修正系统级冲突源

某些发行版（如 CentOS 7.9 最小化安装）默认启用了 epel 源，其中的 podman 或 buildah 包会提供同名但 ABI 不兼容的 containers-common，与 Docker 的 containerd.io 冲突：

• 运行 yum repolist 查看是否启用了 epel；
• 若启用，临时禁用：yum-config-manager --disable epel；
• 或显式排除冲突包：yum install --exclude=podman*,buildah* docker-ce docker-ce-cli containerd.io。