CRIU项目在ARM64架构下的检查点恢复问题解析与解决方案

问题背景

在ARM64架构设备（如树莓派4/5）上使用CRIU（Checkpoint/Restore In Userspace）进行容器检查点操作时，用户可能会遇到检查点失败的情况。本文将以一个典型场景为例，详细分析问题原因并提供解决方案。

环境配置

• 硬件平台：树莓派4/5（ARM64架构）
• 操作系统：Fedora 41/Fedora IoT
• 容器运行时：Podman
• 测试容器：Alpine Linux运行sleep命令

问题现象

当用户尝试对一个简单容器执行检查点操作时，系统返回错误信息：

CRIU checkpointing failed -52. Invalid exchange

同时CRIU生成的dump.log文件中会显示关键错误信息。

根本原因分析

通过分析dump.log文件，可以确定问题根源在于系统缺少必要的iptables组件。CRIU在进行容器检查点操作时需要访问网络命名空间的相关信息，而这一功能依赖于iptables工具链。

在ARM64架构下，特别是基于rpm-ostree的系统（如Fedora IoT），iptables可能不会默认安装，导致CRIU无法完整获取容器的网络状态信息。

解决方案

1. 安装iptables-nft软件包：

sudo rpm-ostree install iptables

2. 重启系统使更改生效：

systemctl reboot

3. 验证安装：

rpm -q iptables-nft

技术细节

在容器检查点过程中，CRIU需要保存以下关键信息：

• 进程树状态
• 内存页内容
• 文件描述符
• 网络命名空间配置

其中网络命名空间的保存需要iptables提供以下支持：

• 网络规则转储
• 连接跟踪表保存
• 网络设备状态捕获

在ARM64架构上，由于历史原因和发行版差异，这些依赖可能不会自动满足，需要手动安装。

最佳实践建议

1. 在ARM64设备上部署CRIU前，应预先安装以下软件包：

   • iptables-nft
   • criu
   • crun（或runc）

2. 对于基于ostree的系统，注意使用正确的包管理命令（如rpm-ostree）

3. 检查系统内核配置是否包含以下选项：

   • CONFIG_CHECKPOINT_RESTORE=y
   • CONFIG_NETFILTER=y

4. 测试环境验证：

podman run -d --name test alpine sleep 1000
podman container checkpoint test
podman container restore test

总结

ARM64架构下的容器检查点操作需要特别注意系统依赖的完整性。通过确保iptables组件的正确安装，可以解决大多数检查点失败问题。对于嵌入式设备或定制Linux发行版，建议在部署前仔细检查CRIU的所有运行时依赖。

此问题的解决不仅适用于树莓派设备，也适用于所有基于ARM64架构的Linux系统，特别是在使用Podman或CRIU进行容器状态保存和恢复的场景中。