v0.2.0 released (27 May 2020, 14:54IST)
Made a lot of changes and fixed a lot of bugs to get the v0.2.0.
What has been improved upon?
Cleaned up repeated code using class implemented decorator calls (as per @ferdnyc’s suggestions)
Enforced root access for whole operation instead of sudo implementation (was going to be polkit but it seemed impossible for the other spins to make that)
Added support for x86 libraries of Xorg display server (addressed requests from some reddit user whose name I don’t remember - useful for Steam, DXVK etc)
Added distribution identification with support status display (Thanks for the suggestion @ferdnyc)
Scaled up to accompany Workstation as well as Fedora Spins (Generalized for all as per @kwizart’s suggestion)
What bugs were fixed?
Added dedicated status check for driver installation (The tool previously used to proceed blindly)
Added dedicated status check for kernel module reader (The tool previously used to proceed blindly)
Fixed confirmation choice during package check (Minor bug during Y/N choice)
Fixed typo in RPM Fusion mentions throughout the tool interface (Addressed @kwizart’s suggestion)
I don’t know how far you have been by replacing the sleep after akmods installation. But at least you should be able to poll the availability of the nvidia.ko using modinfo
Please verify to be on the latest kernel or you will need to
On second thought, using python will requires you do lot of bolder plates.
It might be more relevant to move to use “ansible” instead…
It still interesting work!
Got it. I will get the output of modinfo -F version nvidia to start with.
This is my plan of action to ensure if the module has been successfully installed or not.
First I will check the output of modinfo -F version nvidia.
If I get modinfo: ERROR: Module nvidia not found, I will wait for some 5 seconds and check again.
I will wait for a specific timeout to take place, (eg. 5 mins) for detection and I will timeout if not detected.
Not everyone has to wait for a complete 5 minutes. Most would be done with the modinfo check under 5-10 seconds (at max).
In most of the setups, I believe the modinfo check would get passed in the very first attempt - still keeping the timeout for PCs which take time to build modified kernel modules.
I will build the stuff I specified above and will test it against the latest kernel. There is 99.99% chance that it will work.
I did not get what you mean by saying that. Could you please explain?
Also, I am thinking that maybe these two are not needed as the process of building the modified kernel module begins automatically, immediately after the installation is over.
v0.2.5 released (31 May 2020, 10:38IST)
Made very important changes and fixed some bugs to get the v0.2.5.
What has been improved upon?
Removed that nuisance mandatory sleep time for kernel module load. (as per discussion here)
Removed dependency on kernel module loader (as per discussion here)
Removed kernel module force-read altogether (no sudo akmods --force or sudo dracut --force anymore)
Defaulted textual messages to autocolor for better legibility (functionable visibility in themed terminals also)
Bugs fixed
Fixed boolean choices in main function
Fixed boolean choices in package check
Fixed prompt colors for custom-themed terminals
This is what I would work on, down the line. All the issues would be paid equal amounts of attention but there is a dire need of testers for the spins. Feel free to comment under the issue on which you can be assistance.
This is kind of a big update as it does away with the unnecessary wait times for kernel module loading and forced akmods creation after the installation has completed. The five-minute wait was indeed an inconvenience an modified kernel modules are loaded way before that time even in the slower PCs so it is not worth waiting so long. Also, the akmods transaction commences immediately after the installation gets over and does not let you turn off the PC right away before the modules are completely built so there is no reason why you should force building modules via akmods and dracut.
Combined RPM Fusion pinging, checking, installing into a single module
Combined driver installer and existing package checking into a single module
Combined host detection with GPU support checking into a single module
Revamped installation mode using command line arguments
Withdrew x86 libraries from the default installation mode
Added a new x86 libraries mode of installation for Xorg
Added integrated CUDA module for repository checking, adding and installing
Added support for FFMPEG acceleration using NVENC/NVDEC
Added dedicated privilege check for each installation mode
Added video hardware acceleration using VDPAU/VAAPI
Added support for installation of Vulkan renderer
Placeholder added for install everything mode of installation (Yet to be completed)
Converged all low-level module operations into a single file for speed
All print operations have been replaced by click-echo for optimization
Added checks for NVIDIA repository and RPM Fusion repository availability
Added network availability check before pinging respective repo servers
Improved handling of interrupt . halt and suspend system calls for tool
The tool now functions differently based on the command line modes.
Modes of installation
Active internet connection and superuser privilege is required to execute the following installation modes.
sudo ./NVAutoInstFedora32 --rpmadd
This mode enables the RPM Fusion NVIDIA drivers repository.
sudo ./NVAutoInstFedora32 --driver
This mode simply installs the NVIDIA drivers (with x86_64 deps only). Enabling the RPM Fusion NVIDIA drivers repository is mandatory before doing this.
sudo ./NVAutoInstFedora32 --x86lib
This mode installs only the x86 libraries for Xorg. Enabling the RPM Fusion NVIDIA drivers repository and installing the basic drivers are mandatory before doing this.
sudo ./NVAutoInstFedora32 --nvrepo
This mode enables the official NVIDIA repository for CUDA software.
sudo ./NVAutoInstFedora32 --plcuda
This mode installs only the CUDA support softwares. Enabling the RPM Fusion NVIDIA drivers and NVIDIA official repository, and installing the basic drivers are mandatory before doing this.
sudo ./NVAutoInstFedora32 --ffmpeg
This mode installs only the FFMPEG accleration. Enabling the RPM Fusion NVIDIA drivers repository and installing the basic drivers are mandatory before doing this.
sudo ./NVAutoInstFedora32 --vulkan
This mode installs only the Vulkan renderer. Enabling the RPM Fusion NVIDIA drivers repository and installing the basic drivers are mandatory before doing this.
sudo ./NVAutoInstFedora32 --vidacc
This mode installs only the VDPAU/VAAPI acceleration. Enabling the RPM Fusion NVIDIA drivers repository and installing the basic drivers are mandatory before doing this.
sudo ./NVAutoInstFedora32 --getall
This mode installs all the above packages. (Not been implemented yet)
sudo ./NVAutoInstFedora32 --cheksu
This mode allows you to check the current user privilege level. You can use this tool effectively only when you have logged in as a root or sudo user.
sudo ./NVAutoInstFedora32 --compat
This mode allows you to check your hardware and host compatiblity. The tool would check your hardware and host and tell if your device is supported by the tool or not.
sudo ./NVAutoInstFedora32 --version
This mode would show the tool version and exit out.
sudo ./NVAutoInstFedora32 --help
This mode would show the help message and exit out.
This makes this tool almost comprehensive and complete after the fix made by v0.2.5 to remove the troublesome sleep time and kernel module read forcing. I had to work almost 12 plus hours a day to design, test and build the tool to the state it is currently in.
There are tons of issues to work on and any assistance in testing and building things is more than appreciated. Like I said before, I would like to pay equal amounts of attention to all the issues so feel free to comment under the issue you would want to work on.
Cool. I will get to it. Please do take a look as and when you get time. There’s a lot of stuff improved upon and there might be many that might need attention.
P.S. Isn’t copr something which is not recommended? I read it in one of the Fedora Start Page articles.
copr is meant for exactly that purpose. It’s a automated built system that creates a package repository that can easily be enabled (or disabled) using dnf. In case you are familiar with the Ubuntu world, think of it as a ppa (personal package archive)
PPAs, okay I follow you but they are a lot of mess IIRC - adding a PPA for a single application can be cumbersome but once added, they do allow for continuous updates of that specific application.
One more stuff, I wanted to know about. Can the entire build process take place from only the CLI? I’m thinking of using a virtual machine with Fedora in it to make it happen.
Good approach but rather start a new thread instead of PMing me. That way others can benefit from our public discussion. Once you start a new thread I can move some of the copr related posts from here to there so your NVidia thread remains focussed on that topic.
I am considering packaging this in a COPR but this would take some as I am relatively new to it. The project is open for contribution so people are more than welcome if they wish to help packaging it.