上周在龙芯 3B6000 上部署 AnolisOS 23.4，准备用 Docker 跑几个服务，结果在默认仓库装完 Docker 后，docker run hello-world直接卡住，容器死活创建不出来。这场景太典型了：国产 CPU + 国产操作系统 + 主流容器技术，看似每一步都走通了，却在最后一步卡壳。问题不在 Docker 本身，而在于一个容易被忽略的底层依赖——runc。很多人遇到类似问题，第一反应是去折腾 Docker 配置、换镜像源、或者怀疑系统兼容性。但如果你顺着这个思路去排查，大概率会走弯路。真正的问题，往往藏在默认仓库提供的软件包版本里。AnolisOS 23.4 默认仓库里的 Docker 和containerd版本，可能与龙芯 3B6000 的硬件架构（LoongArch）存在一些尚未完全磨合的兼容性问题，尤其是负责容器生命周期管理的runc组件。这篇文章，我们就来彻底拆解这个问题。我会带你走一遍完整的排查路径，从问题现象、根因分析，到最终的解决方案和长期部署建议。目标不只是解决“容器无法创建”这一个报错，而是帮你建立一套在类似“新硬件+新系统”环境下部署复杂服务的通用排查框架。1. 问题现象：为什么docker run会卡住或失败？当你执行docker run hello-world时，命令没有立刻返回“Hello from Docker!”的成功信息，而是长时间挂起，最终可能超时，或者返回一个关于runc或containerd的模糊错误。在系统日志（如journalctl -u docker或/var/log/messages）里，你可能会看到类似下面的线索：level=error msg="Container start failed: runc create failed: unable to start container process: error during container init: error running execve ..."或者更直接地，runc本身执行出错。这时，一个常见的误区是去反复重启 Docker 服务 (systemctl restart docker)，或者重装 Docker。这些操作通常无效，因为问题的根源不在 Docker 服务进程是否运行，而在于创建容器的“执行引擎”出了问题。这里的关键认知转变是：Docker 是一个高层管理工具和 API 网关，它依赖containerd作为容器运行时守护进程，而containerd又依赖runc这个符合 OCI 标准的底层工具来实际创建和运行容器。当docker run失败时，故障可能发生在 Docker Client、Docker Daemon、containerd或runc任何一层。在龙芯 3B6000 + AnolisOS 23.4 这个组合下，历史数据表明，默认仓库的runc版本是高频嫌疑点。所以，我们的排查起点不是 Docker，而是向下看。首先确认整个容器运行时栈的安装情况和版本。2. 环境诊断：确认你的容器运行时栈在尝试任何修复之前，先摸清家底。打开终端，执行以下命令：# 1. 检查 Docker 版本 docker --version # 2. 检查 containerd 版本（如果独立安装） containerd --version # 3. 检查 runc 版本 runc --version # 4. 查看 Docker 服务状态和详细日志 systemctl status docker journalctl -u docker --since "1 hour ago" | tail -50 # 5. 查看 containerd 服务状态（如果独立运行） systemctl status containerd在 AnolisOS