sgfxi FAQs :: Commonly Asked Questions about sgfxi

Sgfxi is a fairly simple script to run if you use a default, standard system, but sometimes people have special configurations or setups that might trigger a problem. Here's a list of the most frequently asked questions and answers for such issues.

Sgfxi specific questions and technical solutions:

For more general questions, that apply to all the scripts, script descriptions, and other general information, see the FAQs section. If you need to ask a question that isn't answered here, please use the script forums.

ERROR: (224) Your system is missing the required kernel header package:

This mistake can happen in basically one of several ways. Usually this error is easy to fix. The message means that sgfxi was unable to locate any kernel header packages.

Uninstalled standard kernel-headers-package

When sgfxi starts, and finds the kernel-headers data missing from /usr/src, it first searches in apt itself, and will install the header if it can find it, which is all some people need to get the situation resolved automatically.

Then it looks in /usr/src/kernel-downloads/[kernel name] which smxi creates every time you install a kernel using smxi. That's the kernel zip file download directory, where a copy of your header file would have been located. But if you used smxi to install your kernel, you would have the header file already there, so that's very unlikely to be the case. But if it is there and was needed, sgfxi will install that deb package, which will also fix the problem.

If neither of these tests succeed, sgfxi will give up with error 224.

Error 224: Cannot find kernel-headers

If neither of these tests succeed, as noted, sgfxi will give up with error 224. What this means is that sgfxi looked in:
/usr/src/kernel-headers-$(uname -r)
/usr/src/kernel-headers-[latest installed kernel]
if you're installing the driver to a new kernel from an old kernel and saw no header directory for that kernel, and could find none to install.

For the cases that cannot be resolved by the auto install of the missing header package, and if sgfxi exited with error 224, the chances are very good you have one of the two situation:

  1. You have compiled your own kernel. You have the headers, but sgfxi simply cannot find them. To solve this is easy, simply create a symbolic link /usr/src/kernel-headers-$(uname -r) pointing to your existing kernel header directory, where-ever you put them. Then rerun sgfxi and it should be happy.
  2. This second case is harder to solve, because not only do you not have the headers, you cannot get them easily. In other words, you have an older kernel package from your distribution, and you didn't install the kernel-headers package, or didn't get it when you installed your distro.

    Smxi always installs this package when you install your kernel, so this will never be an issue for people who run smxi. But if you have an older kernel, don't want to install a new one, with its kernel-headers package, then you are basically out of luck unless someone has that old kernel-headers package.

But between sgfxi installing the missing headers automatically and creating a symbolic link to the kernel headers, most users who see this error should easily be able to fix it.

ERROR: (229) The FGLRX driver does not work on sidux kernels

Update: the new slh kernels do support FGLRX drivers.

Starting on kernel 2.6.24-6.slh... the old sidux kernels used a flag that fglrx cannot use. AMD/ATI should have resolved this issue, but they never have, and slh likes that flag, so he won't stop using it in his kernel building.

However, you can always install a Debian straight kernel, using either smxi (kernel install, advanced kernel install options, pick the Debian kernel) or by installing the kernel image and headers manually, then fglrx installer will be happy, and the driver will install fine.

Does fglrx support the latest kernel?

The status of fglrx support varies, so make sure to check on this before you upgrade your kernel to latest. Usually however, fglrx drivers will work on kernels that are one major version behind the latest kernel.

For example, if latest kernel is: 2.6.29-1, then 2.6.28-1 is probably going to work, and 2.6.27-1 is almost certainly going to work with the latest fglrx driver.

AMD/ATI has fairly explicitly stated that they will not support bleeding edge latest kernels or Xorg releases, so don't hold your breath waiting for this to change. ATI is the 2nd or 3rd card chip maker out there (and their market share is dropping steadily), and with these tough economic times, don't look for the AMD corporation flooding the basically money losing Linux fglrx driver group with extra cash or support.

I don't want to all real-world macro on you guys here, but let's just say this isn't going to change in the foreseeable future, so just be glad the stuff even works in the first place, and that AMD/ATI has released the card specs and is funding the radeonhd/radeon development process as well.

What distros are supported by sgfxi?

Amazingly, sgfxi now supports apt based Debian Stable, Testing, and Sid, as well as current Ubuntu/Debian derived distros, rpm based Fedora, and finally, pacman based Arch Linux.

Please note that the download location for Arch is: /usr/bin instead of the standard /usr/local/bin because the second isn't in Arch default $PATH.

Not every feature works with every distro, but nvidia direct install works fine in all of them. Fglrx support varies month to month, year to year, distro to distro, but usually one of the methods, either direct binary install (default: sgfxi) or deb builder (sgfxi -F) works, though usually not both.

What does sgfxi mean?

Although sgfxi started its life as a Debian Sid script, it has since evolved to support a variety of distributions and package manager types (like apt, yum, pacman), and to reflect this evolution, its name has been updated, though not the command itself, which of course remains sgfxi.

So to keep it simple, sgfxi means simple gfx (graphics) installer, or, if you prefer, system gfx (graphics) installer.

This name more accurately reflects what sgfxi tries to be, which is simple, clear, and intuitive, hiding all the advanced options but still having them also be easily accessible via the options commands.

Can I build a module for another kernel without reinstalling driver?

Good news for owners of nVidia cards. Yes you can. For ATI/FGRLX, sorry, no luck. The new -k option, coupled with -K [kernel to install module to] lets you do just that. In fact, it was made even easier with the new -! 40 option, which simply tries to install a module for every kernel it can find on your system, except of course the running one.

sgfxi # installs latest nvidia driver
# create a new module for this kernel from your running kernel:
sgfxi -k -K 2.6.32-dmz.3-686
# create nvidia kernel modules for all kernels:
sgfxi -! 40

A few things to note: the module you build must be already installed on your system. If you need to use another driver than current default, you can use the override option (-o [driver]) to do that, for example:

# 190.53 is installed using sgfxi, and you want to install it to
# every other kernel as well. As long as sgfxi still supports that driver
# it will work.
sgfxi -! 40 -o 190.53

Again, this feature only works with nVidia cards and only if you have already used sgfxi to install the driver. The feature tests for all requirements for the module build, and will exit if it is missing one. If kernel headers are missing and are available in your repository, it will install those, if they are missing totally, it will give up.

Note that you can build the kernel modules in X, no need to exit, then you can do what you want, boot into any of the kernels, stay in your current desktop.

This feature only works with the direct run package installer that sgfxi defaults to, it does not work with distro packaged nvidia drivers.

The colors are too hard to read in my console!

You have two ways to set the script colors, -j [color option number] or setting it in /usr/local/bin/sgfxi-values (see sticky options for more information on this method.

Current -j color options are as follows: 1 is somewhat neutral, ok for dark and light consoles, but better for light on dark; 2 is light on dark, 3 works as either dark/light or light/dark, and 4 is dark on light:

# turn off all script colors completely, revert to defaults for console
sgfxi -j 1
# default, standard colors
sgfxi -j 1
# gray/ pale colors
sgfxi -j 2
# earthy, green/brown
sgfxi -j 3
# darker, good for light backgrounds
sgfxi -j 4

You can also set these permanently by creating the file /usr/local/bin/sgfxi-values then adding this to it (to for example make the script default to dark on light colors):


And that's it! Colors set to your liking.

Starting sgfxi with sudo gives an error

That is correct, due to very hard to pinpoint bugs with certain distros, particularly ubuntu / mint, I had to disallow sudo starts for sgfxi, certain things simply fail in that circumstance. Given the time lost on these bugs, this will not be changed, since forcing root login solves most of them.

If you have root login disabled, as happens with some distros who do not trust their users, you can use this trick to get an admin root shell (note the '-' after su, that's important):

sudo su -

All regular users with real root shells just login as root, or su to root.