Nvidia installer does everything needed in order to make sure the driver is working properly after install; it has nothing to do with devel/crippled modules. Unfortunately it doesn't last after a reboot, as Porteus resets GL libs and its symlinks, so that's why we should do some tricks. See?Evan wrote:Something interesting i've noticed is that with a standard install of Nvidia drivers at root/text followed by init 4 straight into desktop without creating a module lets step 11 run without any errors?
I'm not sure if this is because (devel.xzm and crippled_sources.xzm) are loaded or if Porteus standard Module creation corrupts something?
How to create a Nvidia driver xzm module
Re: How to create a Nvidia driver xzm module
How to create a Nvidia driver xzm module
<removed>
Last edited by Evan on 17 Feb 2018, 07:55, edited 1 time in total.
How to create a Nvidia driver xzm module
<removed>
Last edited by Evan on 17 Feb 2018, 07:51, edited 1 time in total.
Re: How to create a Nvidia driver xzm module
This is kind of hard to explain, but I'll try.
ldconfig is a program that comes with Linux and it's responsible for configuring symlinks and cache of shared libraries in the system. Every time we run it (and Porteus runs it all the time through its scripts), all shared libs are checked for any inconsistence, like dead symlinks.
Now, Nvidia driver installs some new libs but remember: Porteus already comes with Mesa drivers. So Mesa comes with the file 'libGL.1.2.0' and Nvidia driver comes with 'libGL.1.0.0', however both use 'libGL.so.1' as the symlink. When Nvidia installer ends, it simply deletes Mesa 'libGL.1.2.0' and calls ldconfig to update all symlinks (if you pay attention to the Nvidia installer process you'll notice this). The catch is that Porteus, as an always-fresh OS kind, restores Mesa driver every reboot, so we have an odd situation when both Mesa 'libGL.1.2.0' and Nvidia 'libGL.1.0.0' exist. When ldconfig is called facing this scenario, it thinks that the symlink 'libGL.so.1' should point to the newest version of libGL, which, guessing only by the name, would be the Mesa one, but that's not what we want, of course. Can you see the problem?
My solution is dirty as hell, but it works: I make a new copy of 'libGL.1.0.0' as 'libGL.1.2.0' and keep it inside Nvidia module, so every time Porteus reboots and restores Mesa libGL.1.2.0, Nvidia driver module comes just after it overwriting Mesa 'libGL.1.2.0' with my copy -- which is actually the Nvidia lib we want.
That's it.
----------------------
But, as you like to say, nothing is really simple when dealing with Linux, so this solution depends on your Nvidia card. With my old GTX 650 Ti the solution above works flawlessly, but with older Nvidia cards it's not enough -- and that's why there's a IF/ELSE inside my script, so the script works for both new and old Nvidia cards. But... Maybe your current machine is a new scenario that my script isn't able to deal with. Are you sure you're running as root inside text mode?
ldconfig is a program that comes with Linux and it's responsible for configuring symlinks and cache of shared libraries in the system. Every time we run it (and Porteus runs it all the time through its scripts), all shared libs are checked for any inconsistence, like dead symlinks.
Now, Nvidia driver installs some new libs but remember: Porteus already comes with Mesa drivers. So Mesa comes with the file 'libGL.1.2.0' and Nvidia driver comes with 'libGL.1.0.0', however both use 'libGL.so.1' as the symlink. When Nvidia installer ends, it simply deletes Mesa 'libGL.1.2.0' and calls ldconfig to update all symlinks (if you pay attention to the Nvidia installer process you'll notice this). The catch is that Porteus, as an always-fresh OS kind, restores Mesa driver every reboot, so we have an odd situation when both Mesa 'libGL.1.2.0' and Nvidia 'libGL.1.0.0' exist. When ldconfig is called facing this scenario, it thinks that the symlink 'libGL.so.1' should point to the newest version of libGL, which, guessing only by the name, would be the Mesa one, but that's not what we want, of course. Can you see the problem?
My solution is dirty as hell, but it works: I make a new copy of 'libGL.1.0.0' as 'libGL.1.2.0' and keep it inside Nvidia module, so every time Porteus reboots and restores Mesa libGL.1.2.0, Nvidia driver module comes just after it overwriting Mesa 'libGL.1.2.0' with my copy -- which is actually the Nvidia lib we want.
That's it.
----------------------
But, as you like to say, nothing is really simple when dealing with Linux, so this solution depends on your Nvidia card. With my old GTX 650 Ti the solution above works flawlessly, but with older Nvidia cards it's not enough -- and that's why there's a IF/ELSE inside my script, so the script works for both new and old Nvidia cards. But... Maybe your current machine is a new scenario that my script isn't able to deal with. Are you sure you're running as root inside text mode?
How to create a Nvidia driver xzm module
<removed>
Last edited by Evan on 30 Mar 2018, 08:25, edited 1 time in total.
Re: How to create a Nvidia driver xzm module
OK, I think I know what's going on: you probably formated your USB stick as FAT, and this kind of partition doesn't support symlinks.
Solution 1: copy the script to some Linux folder, like /home/guest, for example, and run it from there.
Solution 2: format your USB stick as NTFS. I recommend this option once you'll soon start to use rootcopy folder (subject for another topic, hahaha) and it'll require symlinks to work properly
Solution 1: copy the script to some Linux folder, like /home/guest, for example, and run it from there.
Solution 2: format your USB stick as NTFS. I recommend this option once you'll soon start to use rootcopy folder (subject for another topic, hahaha) and it'll require symlinks to work properly
-
- Full of knowledge
- Posts: 2564
- Joined: 25 Jun 2014, 15:21
- Distribution: 3.2.2 Cinnamon & KDE5
- Location: London
Re: How to create a Nvidia driver xzm module
You guys seem to be making such heavy weather of it all. Immediately nvidia script finishes, just have to save-changes, I would have thought. 8)
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
Re: How to create a Nvidia driver xzm module
It's not always that simple
How to create a Nvidia driver xzm module
<removed>
Last edited by Evan on 30 Mar 2018, 08:24, edited 1 time in total.
How to create a Nvidia driver xzm module
<removed>
Last edited by Evan on 31 Mar 2018, 07:21, edited 1 time in total.
Re: How to create a Nvidia driver xzm module
Great news!
How to create a Nvidia driver xzm module
<removed>
Last edited by Evan on 03 Apr 2018, 04:53, edited 1 time in total.
How to create a Nvidia driver xzm module
<removed>
Last edited by Evan on 04 Apr 2018, 07:16, edited 1 time in total.
Re: How to create a Nvidia driver xzm module
Hmmmm... If you reboot without loading Nvidia driver module everything went back to normal?
It's strange because I've been testing this script for at least 3 months, in 3 different machines and had no problem so far.
It's strange because I've been testing this script for at least 3 months, in 3 different machines and had no problem so far.
How to create a Nvidia driver xzm module
<removed>
Last edited by Evan on 05 Apr 2018, 07:13, edited 1 time in total.