And one more feature that -k enables: a new option: -! 40
this will automatically install nvidia modules to all your non-running kernels, or show errors as it loops through them explaining why it failed.

this means you can now run nvidia on all your kernels and boot into any one of them, with no fuss or bother.

Driver must be current, or must be triggered by -o option to use alternate.

You can also install to an older driver if you have that installed, for example:

sgfxi -o 190.53 -! 40
would create modules for your current driver 190.53 but not the current nvidia driver 195.36.08

And that's that, full support.
Back to top

Latest feature: on direct installer failure from the fglrx or nvidia run package, sgfxi will insert the run package installer log into sgfxi.log so you have a copy. Those rewrite themselves on every install, without backups, so now you'll have a copy of whatever failed.
Back to top

Coming soon: I'll be inserting the testing logic used in the module builder into the driver installer itself, and if the driver being requested matches the driver you have installed, and if you have already installed that driver with sgfxi, and if you don't have the distro driver stuff installed, then sgfxi will probably simply build a module for your new kernel instead of ripping it all out and starting from scratch.

And that's it for now, I'll wait for some feedback I think to decide to put in the module builder instead.
Back to top

I already posted this at Mepislovers.org but I think I'll post it here also

I like the -! 40 option, but I've found that if you have virtualbox installed (32bit anyway) that the -! 40 option will build and install the nvidia driver for kernels that aren't really installed.

Virtualbox (32bit) creates the following directories during its installation:

/lib/modules/2.6.26-2-486/misc
/lib/modules/2.6.26-2-686/misc
/lib/modules/2.6.26-2-686-bigmem/misc

in which it places precompiled vbox modules.

I didn't actually have any of those kernels installed, but when I ran sgfxi with the -! 40 option it downloaded and installed the linux-headers-2.6.26-2-* and linux-kbuild-2.6.26 packages for each of the 2.6.26-2-* kernels (-486, -686 and -686-bigmem)

The nvidia driver built okay for each of those nonexistent kernels but I feel that unnecessary cruft has been added to my install.

I wonder if some testing can be done to see if a kernel is actually installed, perhaps checking for the presence of a populated /lib/modules/<kernelname>/kernel folder or something similar, before trying to build and install the nvidia driver for a particular kernel.
Back to top

Can you start a separate thread on any issues you fine, or use the bug reporting thread?

For such a new feature, let's treat each issue one by one, but in its own thread, that way it's easier to track them.

this one won't be hard to fix, but it will require some data from arch/fedora/debian ubuntu users.

<update>the kmathern is fixed or should be fixed now.</update>
Back to top

fglrx 10-2 patch for 2.6.33 kernels added, tested and patch works.

No idea if the driver works of course, reports are that it does with the patch.
Back to top

Some small changes: I have changed -s to -d and -F to -D, which makes more sense.

-s and -F will still work for about the next year, but they show a message when you use them alerting you to change to -d and -D.

Overall -s stopped making sense a few years ago when sgfxi started supporting more than sid, and -F, while referring to fglrx, never really clicked in my head. Now all distro package install methods will be done by d/D, which I think is easier for people to remember because it's for distro, which is nice and generic.

So just think: -d is distro driver, and -D is Distro Package Builder (for fglrx, the method that never works anyway for most systems).

I also added in -f as force override of module check/build and just (re)install driver.

I did a few other internal changes but they only affect how sgfxi and smxi interact and nobody uses those options anyway since they are only for that purpose, but that's where I got the spare -D from (hint, remember when smxi was du-fixes? heh heh).

There won't be any further changes, although I may keep following the course of letting options deprecate for a year before removing them to recycle the letters.
Back to top

sgfxi now checks the remote version using the data file from smxi.org against its own current version number, and if the versions match, sgfxi skips the self updater part and just runs. This makes it a bit faster and more elegant. Just a tweak, nothing earth shaking.

-U will always override this version test and just force the update no matter what.
Back to top

The nvidia auto check/build of kernel modules instead of forcing reinstall every time feature is now default and active for Nvidia cards.

What this will mean is that if say you install a new kernel, you can simply build a new module with your existing nvidia driver.

sgfxi will run this test by default always for new kernels and all installs, if all that is required is a module build, not driver reinstall, it will simply rebuild your kernel module.

You can override the module build step and force a driver reinstall with the new -f option, which when used with nvidia will always install / reinstall the driver, which also removes all the kernel modules that were in your system.

To reinstall all kernel modules each time, do: sgfxi -! 40 [-o <driver version> - optional, only if you want to use a different default than current default offered by sgfxi]

You can also do only a module rebuild with -k (that ignores the -f option), if the module rebuild fails, it will exit with a more verbose error message, telling you why it happened more explicitly.

A serious bug in these cases is if the module build tests pass with no error but the module build fails, then we'll need to collect data and see what went wrong with the process.

Some more testing and debugging, and hopefully some more Arch and Fedora testers (so far the response from both distros has been less than spectacular...) will take the time to do some testing of all the new features.

fglrx is untested in Fedora and Arch because both have xorg 1.7 now.

Known problems that are looming or are here with latest kernels:

nouveau/radeon drm/kms is causing problems for removal of those modules because they are hard locked into the kernel. This is somewhat handled now in fedora, but it's going to take a lot more work to get these methods solid and reliable in the other distros, so I'm going to consider these features the main blocks to the new 5.0.0 release.

Since this is a very big change, I'd appreciate any testing people are willing to do.

Here's the kinds of tests you can run:

install a new kernel, in X. Then, assuming you have the latest nvidia driver installed (sgfxi will check all these things), run this command, say your new kernel is: 2.6.32-1-686

that will force only a module build
or:

will run the module check/build step and build module if it passes the test. If it fails the test, and if you are in X, it will exit with an error message, if you are not in X, it will install the driver and uninstall all current modules.

If you are in X, the -X option gets rid of the X check and lets you run the process. -k overrides the x check automatically.
Back to top

Tweaked colors ( -j 0-4). Now script has usable colors for either light or dark background consoles.

sgfxi -j 1 is default colors, blue
sgfxi -j 2 is pale colors, for dark backgrounds
sgfxi -j 3 is earth colors for either light or dark backgrounds
sgfxi -j 4 is dark colors, for light backgrounds

To set these permanently, see sgfxi sticky prefs
Back to top