First, thank you for the recent fixes to nvidia-driver-assistant.
I’m writing to ask about the long-term maintenance strategy for the 580xx or 575xx NVIDIA driver series and its associated toolchain (cuda, cudnn, nvidia-container-toolkit, etc.) within Manjaro.
Context:
I maintain a public, custom Manjaro Awesome ISO. I use it for my own systems (laptops, future server) and, as it’s public, others may use it too. A key requirement is that it includes the 580xx driver series and the CUDA 12.x stack from the Manjaro extra repository. These components are essential for various tasks, including working with AI/ML development tools on supported hardware.
The concern:
NVIDIA has moved Maxwell, Pascal, and Volta architectures into “legacy” support (security updates only until 2028). It’s logical to assume the 580xx packages may eventually be removed from Manjaro’s main repositories. When that happens, any setup or ISO depending on these packages will break, forcing users into complex manual builds from AUR or source.
Questions:
Timeline: Is there an internal estimate for how long the 580xx driver series will remain in the extra repository?
Community maintenance: Is there a plan (e.g., a community/legacy repo) for community-driven maintenance of these legacy drivers and their ecosystem? How could contributors participate?
Technical guidance: For those who need to ensure continued availability of these packages, what’s the recommended path? Forking and rebuilding the existing PKGBUILDs from packages/extra/, or another approach?
Goal:
I want to plan ahead to ensure my custom ISO (and similar projects) can continue to provide an out-of-the-box experience for systems using older NVIDIA GPUs. If a coordinated community maintenance effort is the way forward, I am willing to contribute.
570xx and 575xx where either short-lived drivers or discontinued production drivers. 570xx got some updates but I think NVIDIA stopped supporting them. I think cuda still works with the given 575xx series. I’m sure when NVIDIA is putting 580xx into legacy drivers we may pick them up again. For now these are totally broken, especially for XFCE users. Still have to make my mind up if temp dropping the driver makes sense for the upcoming Anh-Linh release: [pkg-upd] 0.23.48.01-5 (18e8d371) · Commits · Packages / extra / nvidia-driver-assistant · GitLab
Yeah… Was weird when I try one of the ISO 580 driver version was stuttering,…
And was slow while entering… In live environment… I see a black screen for 1.5-2 sec… So this is why asked the 575 series becouse that was sanppy as F compared for the experience what I see on 580…
I guess because NV try to abandon this version will never be fixed…
To me its weird with my old device they can’t implement well into a never v driver…
BTW I never used this build with GUI in Debian couse using as a headless server.
So this was the reason why you say on the other topic… “Then all good. Just have to decide what to do about 580xx driver series”
I think NV has a reason to abandon this driver… They just go forward and don’t look back…
Thank you for your response! I now understand the dilemma: the newer driver series (570xx/575xx/580xx) may already be unstable on older, and new-er cards, in xorg and mainstream support is uncertain.
Therefore, I’ve concluded that the best approach for me is to create my own long-term strategy. My goal is an ISO that relies solely on stable, independently maintainable components and provides an excellent out-of-the-box experience.
My plan:
Kernel:linux66 (6.6 LTS) – long support cycle.
Driver: The nvidia-535xx branch (built from AUR into my own repo). This is an older but likely more stable version that also supports CUDA 12.
ISO Profile: Remove all newer NVIDIA drivers and integrate only the 535-series environment with the appropriate CUDA 12 compatible toolchain.
This way, I won’t depend on changes in mainstream driver support and can build a predictable, long-term usable foundation.
My question for you: Do you see any technical obstacles with this configuration? In your opinion, is the 535-series branch suitable as such a stable base, or are there known compatibility issues I should be aware of?
If you don’t see any fundamental issues, I will proceed down this path. Thanks for your help!
The regular ISO approach with mhwd might be the wrong idea. For the special use case of a gaming console, the OrangePi Neo, we developed Manjaro Summit: Manjaro Summit public Alpha now available
It is image based and if needed with branches. Based BTRFS you will load tested OS images and keep the user data. Additional you can add package overlays or flatpaks as applications. Alpm (pacman) is not used. Updates are handled via arkdep.
So you configure the image as needed with the proper drivers preinstalled. And when an update is ready the whole system is changed.
Even updates after 3 months not touching the device should work, plus you can configure how many old images the system should keep for rollback.
What you need is a package repo for your additionally added packages not provided by Manjaro and a file server for the images.
Install media can be a live ISO or a disk image.
This way you configure it for the specific usecase. OS is read only with the option to unlock the rootfs.
Thank you for the Summit suggestion – I see the logic for a fixed-purpose device. However, for my own workflows and the flexibility of the system, I’d prefer to stick with the traditional ISO approach .
Instead, I’d like to work on a modified version of the nvidia-driver-assistant that allows finer control over driver recommendations for legacy setups. My plan is to implement this for my own needs, but I’ll keep it public so others can adapt it if useful.
The main features I’d add:
Version control: A configuration file or command-line option to specify which driver branch (e.g., 535xx , 470xx or whatever you want) should be recommended for legacy GPUs, overriding the default database. -->This is just an idea for now, the other 2 already Done, chilling on my OLD Laptop.
SLI and mixed‑system handling: Smarter logic for multi‑GPU setups. For example: if any GPU is legacy, recommend the closed driver for all; if all GPUs are modern, recommend open.
Hybrid scenarios: When both legacy and modern cards are present, recommend the closed driver to ensure the legacy card works.
This way the tool stays automatic for most users, but custom‑ISO builders and advanced users can tailor it to their hardware.
Sure, why not. Manjaro is a great project and if sub-projects can base their ideas on top of it, why not. It is always good to keep the work open and maybe upstream the results, if they make sense.
I’ve completed the enhanced version of nvidia-driver-assistant as discussed. Please note that the code is currently in an “it works for me” state and would benefit from broader testing. Recognize all simulated GPUs
The script now includes the features we talked about:
Fine-grained driver recommendations for legacy setups with configuration options.
Improved handling of multi-GPU systems (SLI, mixed legacy/modern).
Safety checks to prevent incompatible driver installations.
… and much more.
You can find the complete modified script in the repository: MOD-NDA.py. I’ve also updated the README with detailed documentation.
Important notes on licensing and credits:
All modifications are made under the original MIT license terms.
The script header includes the original NVIDIA copyright and added the downstream modifications by the Manjaro Team.
I’ve added in the README in the credits section, as well as my own maintenance work.
If I’ve missed anything in terms of proper attribution or if there are any issues with the licensing, please let me know the preferred format and I’ll update it immediately.
Please review the code and the README when you have time. I’m open to any suggestions or changes you might have.
Thank you for your guidance and support!
..Btw i have more ideas, how to make this complex thing, more simple, and future proof, im back to drawing board right now.
*done
— maybe need to clean some early ideas, which is not safe… but, im done…done