How to build a precompiled driver image that is identical with one built by the GPU operator?

[dlipovetsky]

To build a precompiled driver image, I can follow the documentation (https://instinct.docs.amd.com/projects/gpu-operator/en/latest/drivers/precompiled-driver.html). The documentation references a Dockerfile for Ubuntu, and a BuildConfig custom resource for OpenShift Red Hat CoreOS targets.

The GPU operator, by comparison, derives a Dockerfile for its target based on embedded templates (found in https://github.com/ROCm/gpu-operator/tree/v1.5.1/internal/kmmmodule/dockerfiles).

When I use a precompiled driver image, I want it to be identical with the image that the GPU operator would create if I did not provide a precompiled driver image.

Would you consider exposing a CLI for the operator that someone could use to create a precompiled driver image? This CLI could reference the same Dockerfile templates that the operator uses to build in the cluster, and it would build the same image that the operator builds in the cluster.

[sbryngelson]

Short answer: there isn’t currently an offline CLI for this in v1.5.1. The documented Dockerfile should produce a compatible driver image, but it isn't guaranteed to match every choice the operator/KMM build would make.

The closest workaround is to let the operator reconcile a representative DeviceConfig, then grab the build inputs it generated.

The operator puts its selected Dockerfile in a ConfigMap named:

<os-name>-<DeviceConfig name>-<namespace>

For example:

NS=<namespace>
DC=<deviceconfig-name>
OS=ubuntu-24.04

kubectl -n "$NS" get configmap "${OS}-${DC}-${NS}" -o jsonpath='{.data.dockerfile}' > Dockerfile

The generated KMM Module uses the same name and namespace as the DeviceConfig:

kubectl -n "$NS" get module "$DC" -o yaml

The useful part is under:

spec.moduleLoader.container.kernelMappings

That gives you the kernel version, image name, Dockerfile ConfigMap, build arguments, and any signing configuration. The operator assembles that mapping in getKM:

https://github.com/ROCm/gpu-operator/blob/v1.5.1/internal/kmmmodule/kmmmodule.go#L466-L630

The Dockerfile selection happens in resolveDockerfile:

https://github.com/ROCm/gpu-operator/blob/v1.5.1/internal/kmmmodule/kmmmodule.go#L273-L341

One small catch: the Module is not quite the final command. KMM still fills in things like KERNEL_FULL_VERSION, MOD_NAME, and MOD_NAMESPACE, then configures Kaniko, registry credentials, TLS, and signing. If you want to see the literal command KMM was about to run, the build Pod is the final source of truth:

kubectl -n "$NS" get pods -l "kmm.node.kubernetes.io/module.name=${DC},kmm.node.kubernetes.io/pod-type=build" -o yaml

So basically:

• Existing representative cluster: export the ConfigMap, Module, and build Pod.
• Building before the cluster exists: manually reproduce the resolver or use the documented Dockerfile.
• Exact offline reproduction using the operator’s own logic: not currently supported.

Also, “ident” can only realistically mean “same generated recipe.” A byte-identical image digest is not guaranteed because the templates use base-image tags and install packages from live repositories.

A CLI that takes a DeviceConfig plus representative Node YAML and emits the Dockerfile, resolved image tag, build arguments, and signing configuration would fill the gap nicely. Right now those results are only available after reconciliation.