Migrating this as we would like to see native support for Fedora CoreOS in this project.
See - https://gitlab.com/nvidia/container-images/driver/-/issues/34

Avoiding uppercase letters in Git repository names is generally a good practice for several reasons:

• Consistency with Git Conventions: Git itself is case-sensitive, meaning that "MyProject" and "myproject" would be considered different repositories. Consistently using lowercase letters aligns with Git's conventions and reduces the likelihood of confusion or errors related to case sensitivity.
• Uniformity in URLs and File Systems: URLs and file systems are often case-sensitive as well, especially in Unix-like systems. Using lowercase letters exclusively ensures consistency in URLs (e.g., when accessing repositories hosted on platforms like GitHub) and file paths, which can prevent issues related to casing discrepancies.
• Readability and Aesthetics: Lowercase letters are generally easier to read and aesthetically pleasing, especially when combined with hyphens or underscores to separate words. This enhances the readability of repository names in command-line interfaces, URLs, and documentation.
• Avoidance of Platform Limitations: Some platforms or services may have limitations or conventions regarding uppercase letters in repository names. By sticking to lowercase letters, you can ensure compatibility with a wide range of platforms and tools without running into unexpected restrictions.

Add support for Ubuntu 24.04 LTS.

https://wiki.ubuntu.com/Releases

Please fix the issue in the nvidia-driver script for Sle15.
The function _resolve_kernel_version() has an issue as described in nvidia-driver fails to parse correct kernel version on SLES15 SP5
where
| grep "Basesystem" should be added into the version variable otherwise it won't find a proper kernel version and the build process will fail.

Also, a Dockerfile should be updated for CUDA_VERSION to 12.4 and golang version to 1.22 (it was validated with a driver version 550.54.15)

Migrating this issue from GitLab https://gitlab.com/nvidia/container-images/driver/-/issues/31:

Good Afternoon,

I have had success following the instructions for getting this running on flatcar: https://gitlab.com/nvidia/container-images/driver/-/tree/master/flatcar
The only issue I am having is that I am unable to use the --gpus flag. Any advice on how to get this resolved?

Thanks!

Juan

https://github.com/NVIDIA/GPU-Driver-Container/blob/main/fedora/nvidia-driver#L132

'-' is missing between 'kernel-modules-core' and '${KERNEL_VERSION}'

If one is using vGPUs it's currently required to manually download vGPU guest drivers and to build a custom image.
While the steps are explained at https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/install-gpu-operator-vgpu.html#using-nvidia-vgpu this creates quite some friction in starting to use vGPUs on K8s and also is a constant burden for driver updates.

I understand there are some licensing issues (EULA) that does not allow to host vGPU guest drivers publicly:

Uploading the NVIDIA vGPU driver to a publicly available repository or otherwise publicly sharing the driver is a violation of the NVIDIA vGPU EULA.

But the driver in itself does not do much without individual client configuration token. So I am wondering if there really is no path to also provide current vGPU drives in the gpu-driver-container images?

For OS versions without official support, e.g. FedoraCoreOS, it may sometimes (^1) be necessary to apply an NVIDIA-forum-recommended patch(es) to overcome compilation issues to deliver a working environment. The current driver container does not expose a means to easily apply patches via the installer's --apply-patch switch.

Having a means toinit the driver-container with an --apply-patches switch that searched a specified directory for applicable patches would be a convenience feature for teams running non-supported OS versions. In the situation where the driver container is running on the host one could imagine mounting patches to the container via systemd units etc. However, this method might not extend easily to a gpu-operator scheduled driver container (whether there exists an injection point for a) additional command switches, b) additional config files into the k8s/gpu-operator scheduled driver pods needs investigation).

^1 For at least a month it has been known that driver compilation for Fedora40 (which was in beta at the time, but is now released) fails affecting anyone running environments based on FedoraCoreOS's next and now testing streams. It is expected that in two weeks unless a formal new driver version is released incorporating the patch, that these failures will migrate to the FedoraCoreOS stable stream.