При попытке чекпойнта (podman container checkpoint) контейнера с CUDA-приложением (llama.cpp на Tesla V100) CRIU падает на стадии сбора маппингов памяти процесса: cuda-плагин не может обработать VMA, подкреплённую устройством /dev/nvidia0, и возвращает No such file or directory.
При этом доказано, что сама внешняя утилита cuda-checkpoint полностью работоспособна на данном железе и драйвере — ручной прогон полного протокола lock → checkpoint → restore → unlock проходит успешно с реальной эвакуацией и возвратом памяти GPU. Таким образом, GPU-примитивы исправны, а сбой локализован внутри criu-plugin-cuda.
Дополнительно: пакета cuda-checkpoint (внешней утилиты NVIDIA, без которой плагин нефункционален) в репозитории ALT нет, и criu-plugin-cuda не выражает на него зависимость. Плагин фактически неработоспособен «из коробки».
Окружение:

ALT p11 JeOS (alt-p11-jeos-systemd-x86_64), ядро 6.18 (обновлено с 6.12 через update-kernel)
GPU: NVIDIA Tesla V100-SXM2-32GB (Volta, CC 7.0)
Драйвер NVIDIA 580.142 (kernel-модуль closed), user-space управляется через /etc/libnvidiacurrent -> /usr/lib64/nvidia_580.142/. Активный драйвер 580.142 подтверждён (см. примечание про связанный баг #59352).
criu 4.2-alt1, libcriu2 4.2-alt1, libcompel1 4.2-alt1, criu-plugin-cuda 4.2-alt1 (из Sisyphus)
cuda-checkpoint — установлен вручную из NVIDIA/cuda-checkpoint (в репозитории ALT отсутствует), поддерживает интерфейс --action (lock|checkpoint|restore|unlock)
podman + OCI runtime: проверено и под crun, и под runc — поведение идентично
containers с GPU пробрасываются через CDI (nvidia-ctk cdi generate)


Steps to Reproduce:

Установить и активировать драйвер NVIDIA 580.142 на хосте с GPU Volta (Tesla V100). Убедиться, что nvidia-smi работает, nvidia-ctk cdi list находит устройства.
Установить из Sisyphus: criu, criu-plugin-cuda (4.2-alt1).
Установить утилиту cuda-checkpoint из NVIDIA/cuda-checkpoint (в репозитории отсутствует), положить в /usr/bin/cuda-checkpoint.
Запустить контейнер с CUDA-нагрузкой:

   podman run -d --name llama --runtime runc \
       --device nvidia.com/gpu=all --security-opt=label=disable \
       -p 8080:8080 -v /opt/llm/models:/models:Z \
       localhost/llama_cpp:numa_cuda12.6.3-V100 <args>
Дождаться загрузки модели в VRAM (nvidia-smi показывает занятую память процессом).
5. Выполнить чекпойнт:
   podman container checkpoint llama --export=/var/lib/llm-checkpoints/llama.tar.gz

Actual Results:
CRIU dump.log:
(00.156361) Collecting mappings (pid: 3957)
(00.156782) Handling VMA with the following smaps entry: 200000000-200400000 ---p 00000000 00:00 0
(00.156809) Handling VMA with the following smaps entry: 200400000-200600000 rw-s 00000000 00:37 15  /dev/nvidia0
(00.156841) Error (criu/proc_parse.c:118): handle_device_vma plugin failed: No such file or directory
(00.156847) Error (criu/proc_parse.c:663): Can't handle non-regular mapping on 3957's map 200400000
(00.156854) Error (criu/cr-dump.c:1587): Collect mappings (pid: 3957) failed with -1
(00.156940) net: Unlock network
(00.156948) Unfreezing tasks into 1
(00.157161) Error (criu/cr-dump.c:2128): Dumping FAILED.
CRIU checkpointing failed: -52: Invalid exchange

Существенно: между получением device-VMA на обработку (строка с /dev/nvidia0) и ошибкой проходит ~32 микросекунды. Это исключает форк/запуск внешней утилиты cuda-checkpoint (которая работает миллисекунды-секунды) — плагин падает синхронно, внутри handle_device_vma, до вызова утилиты, на файловой операции, возвращающей ENOENT.

Expected Results:
cuda-плагин должен корректно обработать device-VMA /dev/nvidia0: оркестрировать через cuda-checkpoint перевод CUDA-состояния процесса в checkpointed (эвакуация device-памяти в host), после чего CRIU сериализует маппинг. Дамп должен завершаться успешно, podman container checkpoint — создавать экспортный архив, podman container restore — восстанавливать контейнер с рабочим GPU-состоянием.

Доказательство исправности GPU-примитивов (ручной прогон cuda-checkpoint по тому же PID):
# cuda-checkpoint --action lock --pid 3957 --timeout 10000 ; echo $?
0
# cuda-checkpoint --action checkpoint --pid 3957 ; echo $?
0
# nvidia-smi   →  0MiB у процесса 3957 (device-память эвакуирована в host)
# cuda-checkpoint --action restore --pid 3957 ; echo $?
0
# cuda-checkpoint --action unlock --pid 3957 ; echo $?
0
# nvidia-smi   →  31231MiB, процесс 3957 снова держит модель

То есть утилита выполняет весь протокол, включая критичную фазу checkpoint с реальной эвакуацией VRAM. Архитектура Volta и драйвер 580.142 поддерживают операцию. Сбой — исключительно в интеграции плагина.
Что исключено в ходе диагностики:

Путь к утилите: cuda-checkpoint доступен в /usr/bin (в $PATH процесса criu) — ошибка не меняется.
Версия утилиты: интерфейс --action присутствует; откат на ревизию эпохи criu 4.2 (r555–r560) — ошибка идентична.
OCI runtime: воспроизводится одинаково под crun и под runc.
User-space NVIDIA: libnvidia-ml резолвится через ldconfig на managed-ветку 580.142, посторонних путей нет.
Ядро: criu check (без --all) → "Looks good"; криу стартует и доходит до конкретного device-VMA, общая совместимость с ядром 6.18 есть.

Вероятная причина (для исследования мейнтейнером):
В smaps device-нода отображается с major:minor 00:37, тогда как хостовый /dev/nvidia0 обычно имеет major 195. Маппинг разбирается в контексте контейнерного mount namespace (устройство проброшено через CDI). Предположительно handle_device_vma при резолве устройства обращается к пути в хостовом контексте (кандидаты: /sys/dev/char/0:37, /proc/<pid>/map_files/200400000-200600000, /dev/char/...), которого в этом контексте нет — отсюда синхронный ENOENT. Возможна связь со способом проброса устройств через CDI (создание device-нод вне ожидаемого плагином major:minor).