Is it possible to stop the sgfxi script from updating itself to the newest version? I'm trying to use the 4.22.06 version to install nVidia 331.20 because I keep getting errors that 4.22.08 does not support 331.20
Back to top

Check sgfxi -h for how to disable updater.

However, the 331.20 was not added as an option (-o) driver because I forgot, that's been corrected.

Note that there may be issues with 3.13 and 331, 331.20 will not work because there is no patch for it, 304 may work. 331.38 is the only 331 driver with a patch.
Back to top

I'm not good with man pages. Likely why I couldn't figure it out. I got as far as -W but that only stopped apt-get.

Yeah, I compiled 3.13 a few days ago hoping to get around the performance and heat issues I have with Liquorix 3.12 and nVidia's 331.38 driver. So I want go back to Liquorix 3.11

As far as I can tell, there are no nVidia drivers that will run with 3.13 without major effort on my part.

I'll try the new script and report back. Thanks.
Back to top

Try, it only takes a few minutes, as I said, I just added the patches for 331.38 - 3.13 kernel.



not a man page, it's a help menu, like any other.
Back to top

I just ran the updated script and successfully installed 331.20 Once I'm finished building this OS, I'll build another as a test platform and see about kernel 3.13 and report back.

I completely missed that -R tag. DOH!

Thanks again for the help.
Back to top

Built a test OS and I've been running 3.13 with 331.38 on my AMD system for several hours now and no problems. The only sgfxi install issue I'll note is that I had to use the -f flag. That doesn't come entirely as a surprise to me though.

I've found that on both my Intel/nVidia laptop and AMD/nVidia desktop, using -f is needed around 75% of the time. That's regardless of OS (Debian based), kernel, driver, or if the OS had ever had nVidia graphics installed or not.
Back to top

-f simply forces override of module build, which means that if the driver needed a patch, and if you update the kernel, the install would fail because rebuilding the module will fail if the run file is not patched.

This wasn't a huge issue in the past, but the recent wave of kernel changes have made nvidia/fglrx unusually problematic.

I consider this an issue that I may try to resolve by adding in fixes/patch support to module rebuild as well, but that takes some work to do.

But that's the only reason using -f would have mattered, and it's the only time that it would be required. For example, if nvidia relaases fixed 331/304 drivers, then -f would not be needed for 3.13 kernel.
Back to top

That's the thing though. There doesn't seem to be any rhyme or reason to it. I could (and have) build 4 OS's starting with a Debian netinst image. The steps I use are identical. Install net image> install via dpkg -i network-manager and appropriate firmware-package from a specific folder> install via dpkg -i kernel 3.11-7> apt-get xorg> wget sgfxi and run it. There's a really good chance that 3 of the 4 will need -f. Same hardware. The only difference is the partition numbers for / and /home.

That's my laptop. I do something similar with my desktop and need -f far more often than not.

The only thing I can think of is the hardware profiles. My laptop is an ASUS G73SW. Not rare but hardly common. Especially with the hardware changes I've made. I built my desktop and it is highly unique. The parts are all commonly available but it's unlikely very many people have the same configuration. I've also done several custom builds for people and seen the same thing with other software and scripts.

My point is that the hardware combinations can have dramatic affects on how things behave. With sgfxi, the difference is negligible and the end result is almost always the same. Working drivers.

Using Plymouth as an example, say 95% of computers will boot fine. The devs could fix one thing for a few computers to work properly and then the first 95% stop working.
Back to top

I believe this is a case of seeing a connection where none exists.

In other words, and I just double checked, -f does ONE and only one thing, in the case where nvidia driver was installed previously on the system, via sgfxi, it will override the rebuild module only option, and force the pre install cleanup, system cleanup, and full nvidia driver install/reinstall. In other words, sgfxi -f is exactly identical to sgfxi with no args if no nvidia driver has been installed, or if there is a new default nvidia driver, which will always force a reinstall of the full driver, not just hte module rebuild.

That is all -f does, there is nothing else in the code that is triggered by -f.

So if it's a first install, then you may believe -f is causing something to happen, but it's not. i have however seen reports from mepis uses, who I no longer track, that you had to run sgfxi twice before it would work, but that is a bug in mepis that doesn't interest me, not in sgfxi.

There may be more to it, but in terms of sgfxi, if nvidia has never been installed with sgfxi, then -f cannot make a difference, unless there is a huge bug somewhere that is hiding from us.

Now, with this said, with a driver that needs patching, so too does a module need patching prior to generating it, and -f will be required to force the patch/other fixes to run prior to installing the driver.

That is a bug which is complicated to fix and which was not a big deal until recently, when fglrx drivers needed almost permapatches, and nvidia/kernel stuff has been out of synch due I believe to the intense frequency of kernel changes.

In an ideal world, sgfxi would run the prep stuff for modules too, run the patches, etc, but that's actually fairly complicated, which is why I avoided it.
Back to top