|
Cannot compile nvidia driver with 3.7.0-1.dmz.5
I have installed the 3.7.0-1.dmz.5-liquorix-amd64 kerenel and also the sgfxi script. I tried installing the nvidia 304.64 driver (310 does not support my card). It returned with an error. I am pasting the log file here.
:: Code ::
========================================================= START sgfxi LOGGING: ========================================================= Script started: 2013-01-03-09:48:27 Video Card Information: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) Video Card Type: 10de Video Card Number: 03d0 Xorg Version: 1.12 Installing driver to kernel: 3.7.0-1.dmz.5-liquorix-amd64 Running install from Kernel: 3.6.0-10.dmz.1-liquorix-amd64 sgfxi script version: 4.20.13 sgfxi start options: -K 3.7.0-1.dmz.5-liquorix-amd64 -W -k -f SYSTEM_BASE: debian SYSTEM_CODENAME: sid DISTRIB_CODENAME: sid DISTRIB_ID: debian DISTRIB_RELEASE: SIS: debian-sid-64 BITS: 64 FG_DISTRIB_CODENAME: sid FG_DISTRIB_ID: Debian APT_TYPE: apt-get ========================================================= X is Running: true Current Runlevel: 2 Connection is live (0=true): 0 ========================================================= INSTALL_TO_KERNEL: 3.7.0-1.dmz.5-liquorix-amd64 KERNEL_FULL: 3.7.0-1.dmz.5-liquorix-amd64 KERNEL_BASE: 3 KERNEL_NUMBER: 3.7 KERNEL_MATH: 7 B_IS_XEN: true Function: create_x_conf - Primary: Start xorg is present with xorg.conf file Function: create_x_conf - Primary: End Function: check_package_manager_updated - Utility: Start sizeWorking: 44 Function: check_package_manager_updated - Utility: End Function: check_supported_driver - Utility: Start Function: check_supported_driver - Utility: End Function: set_cpu_data - Utility: Start BITS: 64 - arch: _64 Function: set_cpu_data - Utility: End Function: set_driver_install_version - Primary: Start Function: check_supported_driver - Utility: Start Args: last-check Function: check_supported_driver - Utility: End Function: print_information_continue - Utility: Start Args: info You are using the following options: -K - You are installing a graphic driver onto the kernel: 3.7.0-1.dmz.5-liquorix-amd64 -W - Skip wget downloads. Only use if you are having problems connecting but you have the current driver downloaded already. -k - building nvidia kernel module using previously installed driver -f - You are using the forced override option. This will bypass kernel module check/build and force reinstall of your driver (nVidia only). Function: print_information_continue - Utility: End Function: print_information_continue - Utility: Start Args: standard The graphics installer will be building a module for the nvidia driver: 304.64 Function: print_information_continue - Utility: End Installing this driver: 304.64 Function: set_driver_install_version - Primary: End Function: driver_support_tests - Utility: Start Args: supported-driver Function: driver_support_tests - Utility: End Function: check_kernel_headers - Utility: Start Function: check_package_status - Utility: Start Args: linux-headers-3.7.0-1.dmz.5-liquorix-amd64 i Package Version: 3.7.0-4 Function: check_package_status - Utility: End Function: check_package_status - Utility: Start Args: linux-headers-3.7.0-1.dmz.5-liquorix-amd64 c Package Version: Function: check_package_status - Utility: End headerName: linux-headers-3.7.0-1.dmz.5-liquorix-amd64 headerInstalled: 3.7.0-4 headerAvailable: headerFile: Function: check_kernel_headers - Utility: End Function: check_run_package_tools - Primary: Start Function: check_run_package_tools - Primary: End Function: set_download_info - Primary: Start download url: ftp://download.nvidia.com/XFree86/Linux-x86_64/304.64/ - driver file: NVIDIA-Linux-x86_64-304.64 Function: set_download_info - Primary: End Function: build_kernel_module_only - Primary: Start Args: direct Function: remove_module - Primary: Start Args: nouveau operation outcome: unset Function: set_modesetting_off - Primary: End Function: add_grub_nomodeset_blacklist_item - Utility: Start Args: nouveau Function: get_active_grub_files - Utility: Start grub files: /boot/grub/grub.cfg /etc/default/grub Function: get_active_grub_files - Utility: End Function: add_grub_nomodeset_blacklist_item - Utility: End Function: add_modprobe_d_blacklist_item - Utility: Start Args: nouveau Function: add_modprobe_d_blacklist_item - Utility: End Function: set_modesetting_off - Primary: Start Args: nouveau unset Function: remove_module - Primary: End Function: test_module_build_ok - Primary: Start Args: error Function: list_installed_packages - Utility: Start Args: nvidia (libkwinnvidiahack|libgl1-nvidia-glx-ia32|modalias|libvdpau) packageList: Function: list_installed_packages - Utility: End returnValue: 0 Error Data: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Error logs from nvidia install: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - nvidia-installer log file '/var/log/nvidia-installer.log' creation time: Thu Jan 3 09:48:33 2013 installer version: 304.64 PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/software/texlive/2012/bin/x86_64-linux/ nvidia-installer command line: ./nvidia-installer -N --kernel-name=3.7.0-1.dmz.5-liquorix-amd64 --kernel-module-only -a Using: nvidia-installer ncurses user interface -> Only installing a kernel module for a non-running kernel; skipping the "is an X server running?" test. -> Only installing a kernel module for a non-running kernel; skipping the "is an NVIDIA kernel module loaded?" test. -> License accepted by command line option. -> Installing NVIDIA driver version 304.64. -> Would you like to register the kernel module sources with DKMS? This will allow DKMS to automatically build a new module, if you install a different kernel later. (Answer: No) -> Not probing for precompiled kernel interfaces. -> Performing CC sanity check with CC="cc". -> Kernel source path: '/lib/modules/3.7.0-1.dmz.5-liquorix-amd64/build' -> Kernel output path: '/lib/modules/3.7.0-1.dmz.5-liquorix-amd64/build' ERROR: If you are using a Linux 2.4 kernel, please make sure you either have configured kernel sources matching your kernel or the correct set of kernel headers installed on your system. If you are using a Linux 2.6 kernel, please make sure you have configured kernel sources matching your kernel installed on your system. If you specified a separate output directory using either the "KBUILD_OUTPUT" or the "O" KBUILD parameter, make sure to specify this directory with the SYSOUT environment variable or with the equivalent nvidia-installer command line option. Depending on where and how the kernel sources (or the kernel headers) were installed, you may need to specify their location with the SYSSRC environment variable or the equivalent nvidia-installer command line option. ERROR: Installation has failed. Please see the file '/var/log/nvidia-installer.log' for details. You may find suggestions on fixing installation problems in the README available on the Linux driver download page at www.nvidia.com. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ERROR: (171) The kernel module build failed with error code: 1 Please check /var/log/nvidia-installer.log for more information about the failure. A copy of this nvidia error log is also here: /var/log/sgfxi/sgfxi.log Please try to reinstall the driver using: sgfxi -f (force override module build) because sometimes modules cannot be built to new kernels without the source b The compilation works without any problems with 3.6.0-10.dmz.1-liquorix-amd64 kerenl. Regards. Back to top |
|
|
|
:: Code :: Please try to reinstall the driver using: sgfxi -f (force override module build)
because sometimes modules cannot be built to new kernels without the source b that advice is there for a reason, do what it says, run it with sgfxi -f only, then it will fully reinstall the driver, including the patches required. I assume the next 304 release will handle this bump, by the way, and not require the patches. chris, your comment has NOTHING to do with the thread starters issue, you don't have an nvidia card. I always expect dkms to fail, that's why I never use it. Likewise, I KNOW that amd/ati does not support current releases of kernels or xorgs, only stable pool versions like ubuntu or fedora ship with, in general. Given recent budget and staff cuts at amd/ati, expect this situation to get worse, not better. Translation, don't run bleeding edge software and expect amd/ati drivers to work consistently, they have never done so, at least not since I started doing sgfxi, and I see zero sign that they will ever do so, particularly after their latest round of budget cuts. If you want to add dkms to that unstable mess, then you basically guarantee the failure you got. Remember, dkms is really an all in one system, made out distro packaged drivers, kernels, and other components, so they can keep all those in synch. You have to decide: use the advantages of dkms OR use cutting edge kernels/xorgs. You can have one, not both. I don't personally spend any time on dkms bugs or failures, only when the user has fully removed that from the system can you actually verify that that driver, latest, current, which for ati/amd is their 12-11 beta, which they have in typical inane naming fashion decided to release new versions of continuously without changing the actual download file paths, anyway, to verify that, after you remove all traces of dkms video module building, and after you run their LATEST beta, which probably won't work anyway but may on 3.7, then and only then you post a meaningful bug report about liquorix and amd/3.7 drivers, and even then, honestly, we've all been around long enough to really not care or put any energy into debugging why amd drivers fail on latest releases of x or y, we all know why they fail, it's not a mystery, which is why I recommend nvidia for people who want non free driver support that is actually active and reliable to some degree. for sgfxi users stuck with amd cards, the trick to getting around amds silly failure to give their driver versions actual numbers so you can grab them with consistency, is to run this: sgfxi -B then AFTER each install, find the downloaded driver in /usr/src/sgfxi-downloads and delete the file, that forces sgfxi to download the latest actual driver. I quess I couid try working around that by testing the last modified date of the remote file and force download, but honestly, one gets tired of tracking a company that clearly just will never be any good, sad to say. Back to top |
|
:: Quote ::
that advice is there for a reason, do what it says, run it with sgfxi -f only, then it will fully reinstall the driver, including the patches required. Thanks for the reply. If you check the output I had posted, this is what I had done. I will quote the relevant line again: :: Code ::
sgfxi start options: -K 3.7.0-1.dmz.5-liquorix-amd64 -W -k -f Since it did not change anything, I posted the query here. Regards. Back to top |
|
you need to stop using options that serve no purpose, particularly -k, which overrides, I assume, -f
do what I said, boot into the kernel, and run: sgfxi -f nothing else, period. Sometimes there is such a thing as overthinking and thus creating issues where none actually would have existed. -W cancels all wget downloads, and thus, of course, will cancel the patch process. I strongly recommend that you NOT use options whose purposes are not fully clear to you, which is what you are doing, since \-k cancels out -f and -W removes the ability, I think, to get the patch file, your string of options creates an incoherent situation for sgfxi, and which of course it not able to function properly with. Once you run the command, singular, correctly, with the single option, and if that by chance fails to work, do let me know, but that has nothing to do with liquorix I believe. smxi itself may pass options to sgfxi that seem verbose, but that's because sgfxi can trust those options, which do not contradict eachother. I've added in options over time to handle improperly configured user systems, like -W, but feeling you need to ever use that except for highly specific cases actually means you need to fix your networking to work out of X. If you are using it randomly because it just struck you\ as a good idea, let me assure you,, in fact, it's not. Specialized options are just that, specialized. default sgfxi isalways -k, and that's why -f exists, to override that default, which can be called explicitly, but shouldn"t ever by, via -k but really, in general, sgfxi is designed to just work. The only options I use myself are -f, for this exsct type of case, -B, for beta drivers, -o, for testing other drivers, and a handful of others mainly only for dev p;urposes. The other options often were added to handle what are essentially broken distros, with non functioning networking out of x, which is a distro bug, not an sgfxi one, but because I'm nice I made a way for those distros to work around their bugs and still use sgfxi, but the real idea there is for the distros to fix their bugs and deliver systems that actually work. I'm not sure where you came up with this combo, using -K of course is fine, but the rest are not at all fine in that combination. I have to note, sgfxi actually gets very few, if any, pebkac type failure reports, this might be the best one ever, since translated, your actual question is: well, I noted that when I override the override and turn off theability to download patches, the override remains inactive and of course, nothing else of note happens. so sgfxi actually is working nicely, I can never be sure what happens when certain combinations are offered since there is noactual reason to do that for people, but I do like to see that yes, still,t he override of the override in fact does what it should, negates it. so that's good to see. In case your wondering, it was mepis with the broken networking, and although I added -W for them, along a few others along the way to handle some other broken things, in the end, i found the best course was to retreat and let warran and co either fix it or let it fade away, apparently they are opting for the latter. I believe I failed to note in -k help that is the default for sgfxi anyway, sometimes the documenation falls behind the script function. -k turns OFF all patching because it's simply rebuilding the module. rebuilds never patch. Back to top |
|
Thanks for the help. It worked.
But, I do not like the tone of your reply saying that it was a classic case pebkac. Agreed, there might have been some misreading on my part, but that was unwarranted. Just to put things in perspective, I first ran the program on 3.6 kernel. It downloaded the binary and successfully compiled the module. Then, I tried it for the 3.7 kernel. Since, my download speeds are not stellar, I wanted to save 30 minutes of downloading *again* a 65 MB file. Hence used the option -k. The same logic of saving download time made me use -W. As you noted in your reply, the documentation was not in keeping with the program. I do understand and appreciate the efforts of people like you in helping us. Thanks for your help. Regards. Back to top |
|
The basic concept to grasp about sgfxi is that it is designed to work always with this command: sgfxi
There are, with nvidia, a few other options, such as -K, which allow you to install to another kernel. Also with nvidia, to avoid constant reinstalls and to let you have modules built for each kernel, sgfxi years ago always defaulted to building modules, which means no patches, but no uninstalls. You can see as it runs the first steps the tests it does to determine if a module rebuild is possible, if one of the checks fails, it will do a reinstall, which removes all modules from all kernels as well. Only a reinstall will extract the driver package, and run the patches, if any, on it, if required. I briefly contemplated trying to work around that for 304 but decided given it's a once in 5 year situation, and for legacy nvidia as well, and since the error message already told the user exactly what to do to get around the problem, nothing more was needed. If you consider the above, the default sgfxi would have yielded the error: try sgfxi -f. So with -K, that would have yielded sgfxi -f -K... The help menu isn't really documentation per se, it's what the options do, like most help menus in most apps. I think you'll actually find smxi/sgfxi/inxi help a lot more verbose than many apps. Had you not thought, and simply done exactly what sgfxi said to do, everything would have worked immediately. It's only when the kernel stuff actually changes, randomly, and pointlessly, the syntax of certain header paths (the last one to do this was when /generated/ was added, this was just another addition to that old tweak. These changes are of course totally pointless, and almost seem designed purely to mess with certain software that expects a simple path to remain the same. Because this type of event is so rare, sgfxi doesn't have any real internal way to check for it, and offers the solution in the error message (another usability requirement which I wish more app creators would follow, ie, don't tell them it's failed, tell them it failed, and then a possible solution). I suggest however in the future you read much more carefully before using options, that way you can avoid pebkac appearances. The sgfxi help for -k will be updated to note it is already the default for nvidia, but that still wouldn't help when someone choses to tell sgfxi to build the module but not build it. In a sense, I could build in little flags to the option handlers and then after sgfxi runs exit and say the user has selected an impossible combination, but that's a lot of work for avoiding a single case here and there. But I will update the -k explanation. Likewise, for things like -W, I could add a big warning that if anything fails don't blame sgfxi or the author, lol. But I can also add -W help comments warning NOT to use it unless you know exactly why. mepis, for example, was using it to download the junk in x, then exit x, and run sgfxi. Such a convoluted mess just to avoid giving their users working networking, sigh... Situations like this, which is a change in default header paths, happens about every 5 years, and is probably why I added the -f option and its error message to begin with. If I thought there was any hope of getting the kernel guys to stop doing these random path changes, I would suggest you file an issue report with them asking them not to do that, but I've grown to accept that they are going to change whatever they feel like changing whenever, then will explain to you with a straight face that their apis etc never change. Then they will explain to you why they changed, without missing a beat. Good companies, like nvidia, are very fast generally on these changes, both 310 and 313 had the new path handled internally, so the patch simply was needed for the single driver, 304.60/64. I've actually had no reports from 173, but I assume it will fail. so out of the group that uses nvidia now legacy 6xxx cards, one person chose, as far as I know, to run some random options and sgfxi failed. My view is, not worth handling further, but it is worth noting that it was one person selecting options that contradict eachother. If you like some other term to define such situations, feel free to replace the one you don't like with one you do. I don't expect to use that term again this year, didn't last year that I can remember, it actually doesn't happen much. By the way, if you believe there's anything fun or interesting about tracking this eternal mini war between non free drivers and the linux kernel and xorg, as well as the eternal bumbling incompetence of ati/amd group in general with their catalyst drivers, you'd be very wrong, there is nothing fun or interesting at all about it, it's just a general headache that I somehow got stuck into doing because nobody else was around to do it. dkms isn't as bad (read, totally unusable) as it was when dell first shipped that junk, and it does now work for many users on stable pool distros like ubuntu, or pools where users run the distro kernels, xorg, and drivers, but it's still not at the point where I can go, ok, great, it's fine and I can personally trust and use it and finally drop sgfxi. Personally I like running the latest drivers with the liquorix kernels, so I guess that is one plus for doing sgfxi, I can always do that and do it easily. I should warn you, the -! 40 option does NOT patch, so you will not be able to use that with 3.7 kernels and sgfxi / nvidia 304 until you have the next release of 304 installed, whenever that comes, it's a trivlal code patch in their installer, all it does is add the new header path to the list of possible paths to look for, so I know nvidia will ship it whenever they have it ready, then all sgfxi systems will be back to normal and everything will work exactly as you expect. Also, the -! 40 option has a slight bug which I discovered a while ago, but never really handled since I'm the only person to have reported it to me, and that is that -! 40 must be the LAST option listed, the ones after it get ignored, this is particularly important when building beta driver modules or alternate driver modules with -B or -o. Another thing I need to note in documentation, too time consuming to actually test for that and fix it, easier just to tell people to put -! 40 last in the option list. Back to top |
|
masmys, sgfxi is already, by the way, far ahead of your idea. It's built from the ground up to be as efficient on your system and resources as possible. It downloads the driver files to its download directory, and then on subsequent runs, always uses that file if present. When sgfxi starts, it grabs a tiny version file and checks to see if there is a new sgfxi, if there is, it downloads it, if not, it uses the same version. This brings bandwidth use to the absolute minimum possible to have a live dynamic system running in real time. For nvidia, it might also query nvidia files directly at nvidia to see if there is a newer beta version than sgfxi has listed. But these are all miniscule text file requests.
So there is absolutely no need ever to try to optimize anything with sgfxi, it's already built into it as default. It gets one download driver, it extracts that elsewhere, patches it if needed, then deletes the directory, but not the original file, so you are always operating from the same file, same goes for when modules get built, which happens when sgfxi detects that the module exists on a kernel already, that xorg hasn't changed, that the driver installer file exists, and maybe one or two other checks, I don't remember. sgfxi has already thought it out, it's designed to make things efficient, user friendly, and fast, and to not waste your resources. Additional option use should only be carried out once you understand that the core system in sgfxi already is designed to make the end user trip as a smooth and easy and efficient as possible. Just an example: sgfxi has an -X option which lets the installer run in X, but that is useless for most peoplel because the nvidia installer itself has an x detector and it will fail, since you can't install the driver to your current x session if nvidia is running that session already, so that's an example of yes, you can use it, if you know why and how, but don't expect anything to work the way you thought it would. -A was made for an early distro that used sgfxi in its live cd and wanted a seamless install for the user so they could actually boot to nvidia. Hasn't been used for years, and probably doesn't work anymore, but still exists. Back to top |
|
ok, to avoid spending future time on issues like this, here's what the new sgfxi has:
an error handler case for use of -k and -f, sgfxi will exit and tell you you can't do that. That took me a lot less time than posting here, lol, so to avoid future instances, that means nobody can ever do it again. The help menu and the initial parameter comments you see when sgfxi starts were updated. -k is a complicated option to explain I realized, so I tried to clarify a few things, it's not quite, as I believed, default sgfxi behavior, because it does one extra thing, turns off x check. However, that should also have an error case in case the user is installing to current kernel in X, which of course will fail. -W has much stronger warnings against its use, in fact, it now states that unless someone told you to use it, don't do it. There's also some more explanation of sgfxi defaults. On reflection, I realized that you did what I do sometimes, read the words and try to apply them, something very few people do, thus creating an issue where none normally appears. since sgfxi is however supposed to be userfriendly, it's clear it must not allow user errors to occur with options, and it must exit with an error explaining the problem to them, and not permit it to continue. So it now does that. I will thank you for attempting to read and apply the help menu, and thus reveal some hard to understand parts of it. Since sgfxi has no real man page at this point, there's not really anywhere I can put full explanations that don't overrun a user's terminal with excessive information, personally I don't like the wording I used on -W and -k, but those are actually advanced user options and actually should only be used when understood fully, though of course, -k is ok for normal cases. I don't remember what default sgfxi is now for installing to another kernel without -k, not sure if it kills x or not, I don't remember. Back to top |
|
Thanks for taking time to explain the details and add checks to avoid pebkac's :-)
Regards. Back to top |
|
All times are GMT - 8 Hours |