В этом материале
No matching manifest при pull и exec format error после запуска могут указывать на разные проблемы platform selection. Проверьте image index, CPU architecture и фактический executable. Наличие подходящего GPU не делает бинарник amd64 совместимым с arm64 автоматически.
No matching manifest при pull и exec format error после запуска могут указывать на разные проблемы platform selection. Проверьте image index, CPU architecture и фактический executable. Наличие подходящего GPU не делает бинарник amd64 совместимым с arm64 автоматически.
Определите стадию отказа
Сохраните image reference, node architecture, OS и полный текст события. Если runtime не нашёл manifest для platform, приложение ещё не запущено. Если executable уже выбран, но ядро не может его выполнить, исследование переходит к содержимому образа. У shell-script exec format error также возможны причины, не связанные с архитектурой, например некорректный interpreter declaration. Поэтому не назначайте платформу только по двум словам ошибки; сопоставьте фактический файл и способ его запуска.
Прочитайте опубликованный index
Docker multi-platform image содержит manifest list/index с вариантами для разных OS/architecture. Engine выбирает подходящий вариант для среды. Через buildx imagetools inspect можно увидеть опубликованные platforms и digests. Сохраните исходный index digest и выбранный platform-specific manifest, если он применим. Это разные уровни identity, полезные при воспроизводимом deployment. Не считайте tag с названием multiarch доказательством наличия нужного варианта: проверяйте реальные metadata опубликованного объекта.
Разберите два учебных случая
В первом registry содержит только linux/amd64, а узел работает на linux/arm64: при отсутствии подходящего варианта pull не обязан успешно выбрать нужный image. Во втором index объявляет arm64, но в слое ошибочно лежит amd64 executable. Pull может пройти, а запуск завершится ошибкой. Сравните build provenance, platform metadata и actual binary. Эти случаи иллюстрируют диагностику публикации; они не утверждают поддержку конкретной CUDA-сборки на любой архитектуре и любом устройстве.
| Уровень | Что проверить |
|---|---|
| Узел | OS и CPU architecture |
| Image index | Наличие нужного platform варианта |
| Manifest | Выбранный digest и configuration |
| Executable | Реальная архитектура и interpreter |
Исправьте публикацию или размещение
Соберите и опубликуйте проверенный вариант либо разместите workload на поддерживаемой платформе с явными ограничениями. Не используйте —platform как обещание нативной совместимости: принудительный выбор может потребовать emulation и не решает доступ GPU. Для multi-stage build проверьте, откуда скопирован binary и какой target platform реально использовался. Сохраните версии base image и dependencies. Корректная CPU platform не отменяет отдельную проверку driver libraries и поддерживаемого compute path.
Проверьте новый образ по содержимому
Повторите inspect опубликованного reference, затем запуск минимального executable на нужном типе узла. Сохраните index/manifest digests и результат compute проверки отдельно. Успех загрузки образа подтверждает доступность выбранного варианта, а не всего приложения. Артефакт поможет после следующего build отличить regression публикации от несовместимости runtime. Если ошибка остаётся только у script, вернитесь к interpreter, line endings и permissions по фактическим признакам вместо повторной смены CPU architecture без основания.
Связанные разборы: arm vs x86 inference; software stack reproducibility.