Package Details: nvidia-beta-all 375.10-1

Git Clone URL: (read-only)
Package Base: nvidia-beta-all
Description: NVIDIA drivers for all kernels on the system (beta)
Upstream URL:
Licenses: custom:NVIDIA
Conflicts: nvidia, nvidia-173xx, nvidia-96xx
Provides: nvidia
Submitter: ngoonee
Maintainer: Det
Last Packager: Det
Votes: 47
Popularity: 0.832100
First Submitted: 2009-10-11 10:35
Last Updated: 2016-10-21 15:32

Required by (17)

Sources (2)

Latest Comments

Det commented on 2016-08-16 17:46

Fixed. I think.

Might warn about missing end of lines, tho.

Det commented on 2016-08-16 17:34


misc commented on 2016-08-16 17:33

Looks like changes in linux-4.7.patch have already been applied, as it's failing for me.

Those for 4.8 haven't. Mine:

misc commented on 2016-08-09 15:27

There's a 367.36.02 at . 367.35 is still listed as latest, though.

Also, patch for 4.8-rc1:

Det commented on 2016-07-16 04:51


Note, you might not wanna clear your Pacman cache from .27:

misc commented on 2016-04-07 16:41

Patch for 4.6 & 364.19:

*note:* 4.6's CONFIG_STACK_VALIDATION requires tools/objtool/objtool in the kernel headers.

Det commented on 2016-02-26 09:49

This was a bug in Pacman itself:

Det commented on 2016-02-25 21:01

@misc: "new makepkg fails with md5sums_* & source_* not being arrays

(no reason to bump the pkgrel)"

Thanks, I'm fully aware how to maintain my packages.

Det commented on 2015-09-15 21:11

Added. Should work.

misc commented on 2015-09-14 22:52
for 4.3-rc1

Det commented on 2015-07-29 06:23

352.30 — Changelog:

✔ Added support for the following GPU:
   ✓ Tesla K80
   ✓ GeForce 910M

✔ Fixed a bug that caused poor video post-processing performance in VDPAU when operating on a large number of video streams simultaneously.
✔ Updated nvidia-installer to use modprobe(8) when leaving the NVIDIA kernel module loaded after installation, instead of insmod(8) or libkmod. This allows the kernel module to honor any configuration directives that apply to it in /etc/modprobe.d when it is loaded.
✔ Fixed a bug that allowed console messages from the Linux kernel to be drawn over the user interface of nvidia-installer.

Det commented on 2015-04-14 13:37


Det commented on 2015-03-25 18:14


Det commented on 2015-03-05 13:51

346.47-2 - Added patch for 4.0 RC:

Det commented on 2015-02-26 09:31

346.47 — Changelog:

• Added support for the following GPUs:
   Quadro K620M
   Quadro K2200M
   GeForce GTX 965M
• Fixed a bug that could cause rendering corruption in GLX clients using PBOs and/or VBOs when using GLX indirect rendering.
• Fixed a bug that caused Xinerama layouts which included X screens with 'Option "UseDisplayDevice" "none"' to be represented incorrectly in the nvidia-settings control panel.
• Fixed a bug that could cause glXSwapBuffer() to block for longer than necessary in multi-threaded GLX applications using the GLX_NV_delay_before_swap extension.
• Fixed a bug that caused OpenGL applications using the NV_path_rendering extension to crash after a modeswitch event.
• Fixed a bug that caused DisplayPort audio to stop working after monitors are hotplugged.

Det commented on 2015-01-16 10:34

Added patches for kernel...:

- 3.18 (Optimus):
- 3.19:

Det commented on 2014-12-08 20:42

346.22 - Changelog:

• Added support for X.Org xserver ABI 19 (xorg-server 1.17).
• Improved compatibility with recent Linux kernels.
• Fixed a bug that prevented internal 4K panels on some laptops from being driven at a sufficient bandwidth to support their native resolutions.
• Fixed a regression that prevented the NVIDIA kernel module from loading in some virtualized environments such as Amazon Web Services.
• Fixed a regression that caused displays to be detected incorrectly on some notebook systems.
• Fixed a bug that could cause X to freeze when using Base Mosaic.
• Fixed a regression that prevented the NVIDIA X driver from recognizing Base Mosaic layouts generated by the nvidia-settings control panel.

Det commented on 2014-08-06 21:15

343.13 - Changelog:

** WARNING: This version drops support for pre-GeForce 400 "Fermi" GPUs: **

This warning is included in a couple of places in the package to (try to) make sure people don't miss it.

Det commented on 2014-07-09 11:58

340.24 Changelog:

I switched the source to the HTTP mirror, which gives me pretty much the full speed of ~10MB/s, while the FTP one is seemingly capped at 886 kB/s (many times much less). The web interface will still show the FTP mirror (overridden in the .AURINFO), as it gives you a much easier access to all the driver downloads.

Det commented on 2014-04-08 15:53

337.12 Changelog:

AnAkkk commented on 2014-04-08 14:44

Det commented on 2014-03-09 18:39

334.21-2 - Added the Unified Memory module (nvidia-uvm.ko).


mikeserv commented on 2013-11-05 06:41


Det commented on 2013-11-03 08:59

Thanks for letting us know.

mikeserv commented on 2013-11-03 06:34

This is bullshit:

"The NVIDIA Linux driver tries to guarantee proper GPU behavior by validating that memory allocated to the driver by the kernel can always be addressed by the installed GPU. A failure to do so can cause the GPU to truncate addresses and access the wrong location in system memory."

As I understand it, the Nvidia driver requires the kernel to report on all kernel addressable memory so that it can choose memory addresses for itself using unreviewed proprietary methods in order to protect and obfuscate its allocation space from reads from other processes and thereby potentially compromising all memory-mapped system resources in the process! Admittedly, my understanding is exceedingly limited, but I always thought it ridiculous that they advertised Linux support at all considering it has always been buggy anyway, but especially because said buggy support basically required voluntarily hard-wiring a hugely capable (fully equipped with its own processor(s!!), BIOS, and supported dev-kits for both a low-level machine code and high-level run-time API) system-wide backdoor into your machine!

After 4 or so months of largely ignoring the very real associated problems spammed all over their forums, they finally tell us their crippling multi-lib PAE 32-bit hack obviously implemented in order to ensure monitoring over known memory regions and continue to protect possibly mapped copies of their firmware via legacy code-paths and their long-standing tradition of devoting our system resources to their memregion watchdog processes so that they can overwrite their region of our memory if our OS of choice has cause to call for the pages.

I'm such an idiot for buying Nvidia. Done ranting now.

Det commented on 2013-11-02 15:27

Yeah. We know.

sl1pkn07 commented on 2013-11-02 15:03

Det commented on 2013-11-02 08:36


* Use a better patch:

mikeserv commented on 2013-11-01 04:57

That's an excellent point. While my test did successfully identify all kernels with headers to include a self-compiled linux-zen build with a custom compile-time-set name-modifier and even correctly pulled version info as 3.11 despite the silly compile-time autogen version string I inexplicably chose, I don't have any kernels that weren't at least installed with pacman. I think such things could be handled with the tee/subshell/read combo I mentioned or with a new line between 3 & 4 like:

echo ${kpkg} | grep -i "linux" || echo "shit... where that package be?" #HANDLE EDGE CASE

This would also require resetting the reused variables at either the beginning or end of each loop iteration (which should probably be done anyway) like:

echo '' | read k{ver,pkg} #does this even work? just playing around now

I assume that depending on the installation location of /usr/lib/modules/ is less brittle than the currently set /boot dependency, but I'm probably wrong after all. What do I know?


ngoonee commented on 2013-11-01 03:25

The current code is able to either use pacman's output or search for installed kernels. I originally put that in because some people compile their own kernels which pacman doesn't know about. Something to keep in mind.

mikeserv commented on 2013-11-01 00:26

Ok, so I honestly have no idea why I care about either of these things for any reason, but I actually tested this and I think it might actually work:

for hdr in /usr/lib/modules/*/build; do {
eval "$(pacman -Qo "${hdr%/*}" | \
sed -rn 's:^.*/([0-9|.|-]*[0-9]).*owned by ([^ ]*["linux"][^"header"|^ ]*).*$:kpkg="\2" \; kver="\1":p')"
echo ${hdr%/*} $kpkg $kver; echo ${kver} | grep "3.11" && echo 'PATCH'
echo 'INSTALL'

And also apparently the "sport of kings" is actually horse-racing. Obviously, I'm not a golfer.


mikeserv commented on 2013-10-31 23:26

Maybe not the best idea - I'm just some stranger on the internet after all.

Anyway, at least not as shown. I don't think it works - I grab ${kpkg} from everything following the version number in the folder name which is probably wrong. I think the following is at least easier to read and pacman supplies the package name directly. Is this better?

eval "$(pacman -Qo ${hdr%/*} | \
sed -rn 's:^.*/.*(linux[^"header"|^ ]*) (.*)$:kpkg="\1" \; kver="\2":p')"

Probably a combo of subshells, tee, and read in that pipe would allow a little more flexibility as well.

And I hereby retract any and all inadvertently negatively connotative statements made regarding the sport of kings.


Det commented on 2013-10-31 18:26

Though it's very healthy to go fishing at least 2 or 3 times a week, as these things make you grow big and strong, I do see your point and will go ahead and implement this request as soon as I can.

mikeserv commented on 2013-10-31 11:57

Point taken. I guess I confused the description to mean *any* kernel. Still, fishing in boot doesn't seem like the most reliable way to do it. Maybe this?

for hdr in /usr/lib/modules/*/build; do {
eval "$(echo ${hdr%/*} | sed -rn 's:^.*/([.0-9]*).?(.*)$:kver="\1" \; kpkg="\2":p')"
echo ${kver} | grep "3.11" && echo 'PATCH'
echo 'INSTALL'

That way you don't have to fishing in /boot, you should only pull kernels with headers installed, and you do all of the logic in a tiny for loop.


P.S. I only brought it up at all because the PKGBUILD failed first time round for me due to missing header files.

ngoonee commented on 2013-10-30 08:27

That would be nvidia-beta. This package builds for all installed kernels, not just the currently running kernel (uname -r in your example).

mikeserv commented on 2013-10-30 06:23

Ok, this is funky:

if [ ${_pacman} = 0 ]; then
_KERNELS=$(file -rk /boot/* | grep 'Linux kernel.*boot executable' | sed 's/
.*version \([^ ]\+\).*/\1/')
sed 's/_pacman=1/_pacman=0/' -i "${startdir}/${install}"
_packages=$(pacman -Qsq linux)
_KERNELS=$(pacman -Ql ${_packages} | grep /modules.alias.bin | sed 's/.*\/li
sed 's/_pacman=0/_pacman=1/' -i "${startdir}/${install}"

Isn't the point of this package to work with different kernels? Just:

cd /usr/lib/modules/$(uname -r)/build || echo "shit... where those headers be?"

mikeserv commented on 2013-10-30 06:22

Ok, this is funky:

if [ ${_pacman} = 0 ]; then
_KERNELS=$(file -rk /boot/* | grep 'Linux kernel.*boot executable' | sed 's/
.*version \([^ ]\+\).*/\1/')
sed 's/_pacman=1/_pacman=0/' -i "${startdir}/${install}"
_packages=$(pacman -Qsq linux)
_KERNELS=$(pacman -Ql ${_packages} | grep /modules.alias.bin | sed 's/.*\/li
sed 's/_pacman=0/_pacman=1/' -i "${startdir}/${install}"

Isn't the point of this package to work with different kernels? Just:

d /usr/lib/modules/$(uname -r)/build || echo "shit... where those headers be?"

Det commented on 2013-10-07 19:17

No, because it's a split package and part of nvidia-utils-beta, as already mentioned in the comments..

kiodo1981 commented on 2013-10-07 19:16

Does not exist.
Sorry for my bad English.

Det commented on 2013-10-07 19:10

Are you serious?

kiodo1981 commented on 2013-10-07 18:54

Missing dependencie

Det commented on 2013-10-07 17:29

Where are your eyes?

kiodo1981 commented on 2013-10-07 17:17

Where is nvidia-libgl-beta?

Det commented on 2013-07-03 16:41

It's not really even the initial pkgname but the only one.

The full array is hidden behind the "true &&" 'hack', which the parser wouldn't understand anyway.

Thanks for the patch.

misc commented on 2013-07-03 13:23

Ok, didn't see that since the search only matches the initial pkgname.

Btw, 325.08 needs a patch for kernel 3.10; I used the one karolherbst posted here:

Det commented on 2013-06-28 17:50

Yes there is:

misc commented on 2013-06-28 16:37

There is no package called "nvidia-libgl-beta".

Det commented on 2013-06-27 13:03


The reason it took me so "long" is that I wanted to upload 'nvidia-full-beta'[1] and 'nvidia-full-beta-all'[2] on the same go. These are for people who are tired of the update conflicts and downloading the same source twice for the two different halves of the nvidia driver.

64-bit systems can also set the option "_lib32=1", which will pull in the 32-bit compatibility sources for all parties involved (again, obviating from the unnecessity of downloading multiple sources) and use them to build the 'lib32-nvidia-utils-full-beta' group.

This only needs to be set once and will remain until the lib32-* packages are removed.

[1] =
[2] =

misc commented on 2013-05-03 21:40

Installed the kernel again; now it's working. Huh.

misc commented on 2013-05-03 10:39

Getting an "error: module nvidia not found" for the stock kernel 3.9.0-2. Bit weird as linux-ck 3.8.11-1 still loads fine.

ngoonee commented on 2013-04-15 00:43

Kind of a moot point IMO but yes, you're right =)

BlackLotus89 commented on 2013-04-12 14:12

Using -ge "8" is wrong because the patch should not be applied to 3.9 kernels.
An equal would work thought ;)

z1lt0id commented on 2013-04-10 00:44

319.12 beta drivers have been announced.

ngoonee commented on 2013-02-22 00:05

My bad, copy-paste error. Fixed version uploaded.

misc commented on 2013-02-21 16:28

Prefix strip for linux-38.patch needs to be 1, not 3.

ngoonee commented on 2013-02-21 02:08

Two different patches depending on kernel version, put both of them here, should work fine (I'm not on 3.8 yet). Will have to rethink the patching behaviour, the old one I'm using is quite brittle.

Det commented on 2013-02-20 03:30

Doesn't build for 3.8 either.

Det commented on 2013-02-20 03:16

Or just increase the sublevel.

ngoonee commented on 2013-02-18 23:13

For now, if you've previous compiled this for 3.7.6 it should still work (does for me).

ngoonee commented on 2013-02-18 23:13

Thanks, subscribed to the bug to see how wonder wants to handle it (probably including patch in tarball) which I'll do as soon as he does.

misc commented on 2013-02-18 19:18

After 3.7.7 I've again been unable to build the package, even with this 3.7.6 patch.

Meyithi linked here
to the linux-3.7.patch Gentoo took to fix this.

With that applied it's working for me again, too.

Det commented on 2013-02-05 11:52

Needs a fix for 3.7.6 kernels (might even bump the sublevel all the way up to 10 or so):

ngoonee commented on 2012-07-16 02:32

Actually no, it won't. dkms isn't really very widely supported on Arch anyway (not 'officially'). I think some people already used it, but I've personally never bothered. pacman hooks (whenever they land) would be MUCH more useful for me in that regard, an Arch-specific solution.

misc commented on 2012-07-14 13:34

This "highlight" of 304.22 could become relevant:

"Added support for DKMS in nvidia-installer. Installing the kernel module through DKMS allows the module to be rebuilt automatically when changing to a different Linux kernel. See the README and the nvidia-installer help text for the --dkms option."

ngoonee commented on 2012-07-04 01:59

This latest update 302.17-2 is only for users of the new kmod-9-2 package. If you try to compile this PKGBUILD while using kmod-9-1, your modules WILL be in the wrong place (and hence you won't be able to boot to X). The package is in [testing], for those who aren't using it, just wait till you get it in [core].

ngoonee commented on 2012-06-20 00:21

Updated, please try again (did not bump pkgrel, those for whom this wasn't a problem have no reason to update).

Det commented on 2012-06-19 11:00

It's in

Anonymous comment on 2012-06-19 10:54

/XFree86/Linux-x86_64/302.17/ doesn't exist.

==> Retrieving Sources...
-> Downloading
Initializing download:
Can't change directory to /XFree86/Linux-x86_64/302.17/

ngoonee commented on 2012-05-10 03:45

Good catch, thanks. I never use that method, just added it in a while back due to some requests. Note to all who use hibernate/suspend, 302.07 won't resume from hibernate on some (8/9 series it seems) nvidia cards, I'm personally just using 295.49 for the time being till nvidia fixes that.

Ner0 commented on 2012-05-09 13:04

Shouldn't the _KERNELS= line be pacman -Ql $_PACKAGES instead of $PACKAGES?

ngoonee commented on 2012-03-26 02:05

The patch isn't required anymore with 295.33

ngoonee commented on 2012-03-20 05:26

Updated - the only change is a patch which should allow this to build fine against the new linux-3.3-1 which just entered [testing]. If any of your custom kernels with version 3.3 or above don't work, you'll need to copy the patch and rename it to the specific name/version of your custom kernel (just check /lib/modules and apped -nvidia-beta.patch to the name).

ngoonee commented on 2012-01-06 03:29

Yep, made the change and uploaded.

Anonymous comment on 2012-01-05 07:22

Thanks ngoonee :) That makes sense to me now and I left a comment on linux-zen. One more thing - could you switch to using the source url at like is done by nvidia-beta and nvidia-utils-beta? it seems that has not been working for me and I have been manually changing the url when building.

ngoonee commented on 2012-01-05 02:23

Hi Bregol, you can uncomment the three lines (and comment the other three lines) which do the moving in my PKGBUILD. Or you should ask linux-zen to update their PKGBUILD to match linux in [core]. I've thought through the location, placing it in /lib/modules/3.1.6-1-ARCH/extramodules serves no purpose since the point is to not have to rebuild on updating AND not have left-behind folders after an update. Check my thread on the arch-general ML for more details.

Anonymous comment on 2012-01-04 22:46

Any way to have it a little more flexible? Something like:

It looks like the zen kernel (via linux-zen) doesn't put a /lib/modules/extramodules-3.1-zen (or whatever) directory in place with the "version" file in it, so although it builds the module for zen, it discards the module when it comes time to package, as it does not have /lib/modules/extramodules.../version file (or even that extramodules folder) for that kernel.

There is a /lib/modules/[kernel version]/extramodules directory that is made by VirtualBox when I rebuild the modules for that kernel. Virtualbox makes that directory and sticks the modules there. For stock Arch, this directory (/lib/modules/3.1.6-1-ARCH/extramodules) is a symlink to /lib/modules/extramodules-3.1-ARCH ... but for zen kernel (possibly through V it is an actual directory with no /lib/modules/extramodules-3.1-zen.

Perhaps for each built _kernver, try to put it in the /lib/modules/3.1.6-1-ARCH/extramodules folder (or whatever). For stock Arch kernel, that will make it end up in the /lib/modules/extramodules..... and for when there is no /lib/modules/extramodules... then make the /lib/modules/[kernel version]/extramodules folder and put it there (like Virtualbox does)?

Det commented on 2012-01-01 13:53

It already installs into "/lib/modules/extramodules-[major version]-[name]" (eg. "3.1-ARCH").

It shouldn't require a rebuild unless the kernel gets a major update (eg. 3.1.x -> 3.2.x) or you modify the kernel yourself that much.

misc commented on 2011-12-31 15:24

Is there a way to not have to install the driver package every time the kernel gets updated? Not a big deal, but kind of annoying still.

ngoonee commented on 2011-12-29 06:13

Yeah I saw, but I don't update this till nvidia-utils-beta is updated =) shouldn't be more than a pkgver/hashsum bump anyway

Anonymous comment on 2011-12-29 03:52

Everything works fine here also, thanks ngoonee. BTW just in case you missed it 295.09 is out

ngoonee commented on 2011-12-29 03:32

I've uploaded a different sort of check, based on finding all /lib/module/extraversion* directories and comparing them with the kernels found in /boot. Runs fine here on my system, please report if any problems arise.

Anonymous comment on 2011-12-29 03:27

Darn didn't spot that, but still if your OK with the basic idea I'll have a look at it and let you know if I come up with something more robust.

ngoonee commented on 2011-12-29 02:26

Had some time to look through your code and it will catch kernels as long as the pkgver is less than 10 (single digit) and 3.0/3.1 does not give way to 3.11 (for example). Thanks though, its a good stop-gap, but I'll be trying for something a bit more robust for now.

Anonymous comment on 2011-12-14 16:50

Cool, i've pastebined the pkgbuild so you can just diff it, enjoy your hols!

ngoonee commented on 2011-12-14 00:26

Thanks, I'll go through it when I come back from my holidays next Monday =)

Anonymous comment on 2011-12-13 18:18

ngoonee, If you're interested I've been looking at this extra modules thing as i'm fed up rebuilding after every minor bump and i've come up with a solution that (seems to) work and keeps things clean.
It installs the modules to " /lib/modules/extramodules-3.1-*kernel_name*/ (ARCH,ck,bfs,etc) " which is a symlink to " /lib/modules/_kernver/extramodules/ ", I think you can just put them straight in there but I thought that would leave a few extra folders floating around for a while, so i've put them straight into " /lib/modules/3.1-*name* " to keep things tidier.
It looks a little unwieldly and could probably be done better but I looked over the AUR and I think this will catch most kernel I could see.
I've tried this with 3 different versions of 3 different kernels and it's worked fine.
Anyway, just need to change the "mkdir -p" and "install" lines in the package function with these.

mkdir -p "${pkgdir}/lib/modules/extramodules-${_kernver:0:3}${_kernver##[0-9]*-[^aA-zZ]}/"
install -m644 nvidia.ko "${pkgdir}/lib/modules/extramodules-${_kernver:0:3}${_kernver##[0-9]*-[^aA-zZ]}/"

If it all goes wrong then i'll just run "format c:" anyway ;)

ngoonee commented on 2011-12-13 02:57

I MUST remember not to apply sarcasm where its unlikely to be recognized... you're free to comment out the line 90 to enjoy your faster module loading, you obviously know how to. I happen to prefer saving some MBs of disk space than speeding things up by a fraction of a second. You're not compelled to agree.

ilikenwf commented on 2011-12-13 01:23

"format c:" is windows only, so it's still pretty stupid.

All it does is slow down the loading of the module - while gzip may be fastest in compressing/decompressing, there's no point in doing it unless you're on an embeded system.

ngoonee commented on 2011-12-09 07:42

Why thanks, I was just weighing how much dumber gzipping a module to save disk space is than typing "format c:" into my terminal, but you cleared it up for me.

And no, post-install already has depmod for each individual _kernver. Thanks for that suggestion, the code IS pretty unwieldy as it is right now.

ilikenwf commented on 2011-12-09 04:06

gzipping the module is the absolute dumbest thing you can increases load time dramatically...also, your post install needs a depmod -a

jrdnjhntn commented on 2011-11-23 05:20

@ngoonee No problem, i'm already up-to-date. :)

290.10 is nicer with RT. Compositing is noticably smoother & nvidia isn't using as much resources. it seems they fixed something. (?)

ngoonee commented on 2011-11-22 06:05

I'm holding off updating for a bit till I get my head around the extramodules stuff =)

jrdnjhntn commented on 2011-11-21 21:58

290.10 is out.

...also, the link you are using is down;

--2011-11-21 16:47:26--
Connecting to||:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2011-11-21 16:47:26 ERROR 404: Not Found.

I grabbed the source listed in the nvidia-beta (which is using ftp), changed md5sums and updated.

Det commented on 2011-11-18 15:57

By the way, starting from [linux] 3.1 all external modules should be installed into the "extramodules" directory (eg. /lib/modules/extramodules-3.1-ARCH).

ngoonee commented on 2011-11-09 02:54

Please check depends.

mrunion commented on 2011-11-09 02:42

nvidia-utils-beta-all does not exist. Is there a package error?

ngoonee commented on 2011-10-24 03:20

Good point, removed.

Det commented on 2011-10-22 09:59

Why exactly have you got "replaces=('nvidia')"? It's intended only when the project changes its name (eg. "pine" became "alpine", which became "re-alpine")

ngoonee commented on 2011-10-17 03:25

You'd need to report that to nvidia. I have an rt install but haven't booted it in ages.

blackhole commented on 2011-10-15 15:34

With patched linux-rt (rt18) installation went fine, but I have a big crash at kde startup.

blackhole commented on 2011-10-15 15:34

misc commented on 2011-10-03 21:49

NB: While 285.05.09 does not appear to freeze/crash anymore with X-Server 1.11.1 on my 9600M, there are still occasions when everything gets awfully slow, e. g. when I move a Chromium tab between two / into a new window.

ngoonee commented on 2011-09-19 05:59

I was not aware of that, thanks Det. Uploaded the (minor) change without pkgrel bump.

Det commented on 2011-09-17 18:33

Also, it doesn't need to conflict with 'nvidia-beta'. 'Nvidia-beta' provides 'nvidia' and this already conflicts with it.

Det commented on 2011-09-10 21:53

Same thing here. Why does it still say "NVIDIA beta drivers for kernel26."?

ngoonee commented on 2011-08-24 04:19

Updated it.

funkmuscle commented on 2011-08-23 18:07

did the link change?
Connecting to||:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2011-08-23 07:05:46 ERROR 404: Not Found.

==> ERROR: Failure while downloading
The build failed.

ngoonee commented on 2011-08-18 03:13

I am currently on my personal machine running kernel26-rt-ice and nvidia-beta-all. I cannot (and will not) distribute patches enabling that though, since I've been informed that that would be a legal violation of the GPL. I'm unsure whether my personal use violates the GPL, but it may not, while distributing my (simple) patch will. As an Arch-er, I'm sure you know the power of google if you want to make a similar patch yourself.

funkmuscle commented on 2011-08-16 23:41

according to your answer here:
I'm out of luck with the rt kernels and nvidia??

funkmuscle commented on 2011-08-16 23:12

nvidia-beta-all doesn't build against the linux-rt-ice kernel
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'migrate_enable'
make[3]: *** [__modpost] Error 1
make[2]: *** [modules] Error 2
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [module] Error 2
==> ERROR: A failure occurred in build().

funkmuscle commented on 2011-08-16 22:55

nvidia-beta-all doesn't build against the linux-rt-ice kernel

ngoonee commented on 2011-07-30 04:12

Okay, updated for that.

Det commented on 2011-07-29 17:43

Could you gzip the driver as in [extra]?

ngoonee commented on 2011-07-29 01:36

That has nothing to do with this package, since it only depends on nvidia-utils-beta. Please learn use the AUR the way it was intended, yaourt is convenient but only if you understand what its (trying) to do behind the scenes.

And you obviously have not even read this PKGBUILD. As I previously said, I already uploaded a changed version. Obviously, without having changed pkgrel yaourt would not have told you that (another reason why using yaourt isn't the best idea). This version works with my machine, please test out my kernel-detection parameters (they're in the PKGBUILD) to see what's going on with your specific case.

misc commented on 2011-07-28 11:50

Wasn't aware that lh provides kh, I figured it didn't as yaourt demanded (once) that I reinstall kh nonetheless. Odd.

Re. USE_PACMAN_VERSION, I've checked the relevant configs, none of them include such a line.

Anyway, I figure I'll just have to use the separate packages until said update.

ngoonee commented on 2011-07-28 01:26

Anyway, I've uploaded a changed version of the sed lines for those using the USE_PACMAN_VERSION=1 setting. Will need to update it again as all the AUR kernels start naming themselves linux rather than kernel26, but it hasn't happened uniformly yet, so far.

ngoonee commented on 2011-07-28 01:19

linux-headers provides kernel26-headers. Are you setting USE_PACMAN_VERSION before running makepkg?

misc commented on 2011-07-27 13:51

kernel26-headers has been replaced by linux-headers (in testing).

I don't know if that's the cause, but the package won't build anymore here - next to the standard kernel I also have kernel26-ck installed, for which it previously built fine, but now immediately aborts with "*** Unable to determine the target kernel version. ***".

misc commented on 2011-07-27 13:51

kernel26-headers has been replaced by linux-headers (in testing).

I don't know if that's the cause, but the package won't built anymore here - next to the standard kernel I also have kernel26-ck installed, for which it previously built fine, but now immediately aborts with "*** Unable to determine the target kernel version. ***".

ngoonee commented on 2011-07-27 02:41

Excuse me, but this IS nvidia-beta-all?

artiom commented on 2011-07-26 16:55

How this package is different from nvidia-beta-all ? Could you put some explication to the description?

ngoonee commented on 2011-06-07 01:26

Updated. It was previously in nvidia-utils-beta, but ProgDan has moved it to nvidia-beta for consistency, so I've done the same here. pkgrel NOT updated.

demonicmaniac commented on 2011-06-06 12:19

Hello. The package is missing the /etc/modprobe.d/nouveau_blacklist.conf which is required in feature initscripts removing functionality to blacklist in /etc/rc.conf. suggest you just copy the file from the official package and add it.

ngoonee commented on 2011-05-06 23:40

Both. nvidia of course only really develops for the stock kernel, but I've found their team (all 2 of it) quite responsive if they notice your message on their forums. The rt-team is quite understaffed, and they don't recommend the nvidia driver anyway (affects latency in some situations). Best bet is nvidia, but make sure you're on the rt-list as well in case you need to ask them some specifics.

beroal commented on 2011-05-06 16:40

I wrote here because I can not determine the relevant upstream — the RT patch or Nvidia.

ngoonee commented on 2011-05-06 09:58

Please contact the relevant upstream, then. If I have the time (and remember to) I will test that out myself, but I cannot do anything about it since I'm just packaging these things.

beroal commented on 2011-05-06 09:32

Sorry, I must be more precise. Xorg hangs the whole OS up after it switches to the 7 virtual terminal, I see the black screen.

ngoonee commented on 2011-05-05 02:22

The module compiles fine for kernel26-rt-ice 2.6.33-17 here, though I haven't actually booted into it yet.

beroal commented on 2011-05-04 17:59

nvidia 270.41.06 does not work with kernel26-rt-ice 2.6.33-17 . Need to downgrade to nvidia 270.30 .

misc commented on 2011-04-13 20:37

Found the cause: Somehow my /boot got chmod 700'd; hence "find /boot/*" failed while building as normal user.

Anonymous comment on 2011-04-13 19:57

@misc It works fine here, just changed the version numbers. Pkg size 7.7MB.

misc commented on 2011-04-13 19:20

Somehow broken with 270.41.03. The package I get is a whopping 940 bytes large.

fackamato commented on 2011-04-11 22:14

270.41.03 for Linux x86/x86_64 released

ngoonee commented on 2011-03-26 13:50

I personally only use nvidia-beta. If noone takes it in the next week or so let me know, shouldn't be all that much hassle. Why don't you take it yourself? The best thing is always to have users of a package maintaining it.

Barthalion commented on 2011-03-26 08:19

What do you think about maintaining nvidia-all?

funkmuscle commented on 2011-02-19 16:25

yeah, your awesome work here has been fine on my laptop..
I run the RT-ice kernel
and the stock as backup in case a kernel panic on the other 2.
it seems to build the other 2 but fails at the 2.6.37-ARCH

ngoonee commented on 2011-02-19 01:17

I'm currently running 2.6.37. Do you have the headers?

funkmuscle commented on 2011-02-18 21:44

it won't build against the stock kernel 2.6.37

ngoonee commented on 2011-02-18 04:30

Works here. Did you re-download the PKGBUILD?

funkmuscle commented on 2011-02-18 03:58

nah, same problem

funkmuscle commented on 2011-02-18 03:26

nah, same problem

ngoonee commented on 2011-02-18 02:55

Uploaded changed, this one should work. Sorry, my error.

funkmuscle commented on 2011-02-18 02:19

hey ngoonee, I get this error:

-> Downloading
--2011-02-17 21:17:11--
Connecting to||:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2011-02-17 21:17:12 ERROR 404: Not Found.

==> ERROR: Failure while downloading
The build failed.

Anonymous comment on 2011-01-27 17:03

Hmmm... my KDE 4.5 hasn't done that to me yet (270.18) on either zen kernel or stock kernel.

SanskritFritz commented on 2011-01-27 15:01

Warning: my KDE 4.5 freezes at logon when using 270.18. Downgrading to 260.19.29 solves the problem. I'll notify upstream.

funkmuscle commented on 2010-12-16 01:43

thanx ngoonee

ngoonee commented on 2010-12-15 23:07

Thanks, my typo, reuploaded.

funkmuscle commented on 2010-12-15 21:52

cannot update:

Making package: nvidia-beta-all 260.19.29-1 (Wed Dec 15 16:51:05 EST 2010)
==> Checking Runtime Dependencies...
==> Checking Buildtime Dependencies...
==> Retrieving Sources...
-> Downloading
--2010-12-15 16:51:05--
=> “”
Connecting to||:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /XFree86/Linux-x86_64/260.19.29 ...
No such directory “XFree86/Linux-x86_64/260.19.29”.

==> ERROR: Failure while downloading

M0Rf30 commented on 2010-10-13 15:55


ngoonee commented on 2010-10-13 14:34

@darkraven, why flag out-of-date? There is no new beta release.

falconindy commented on 2010-09-08 00:37

260.19.04 released.

Det commented on 2010-09-06 19:32

Might as well unflag. Sure, there is a version with a 0.01 higher number change but that's about it then.

M0Rf30 commented on 2010-08-31 23:04

256.53 is out

ngoonee commented on 2010-08-30 00:48

Updated to 256.52

Det commented on 2010-08-29 14:24

It is not a dev preview release, it is a 'normal' prerelease. As for the first part - I know.

ngoonee commented on 2010-08-28 16:00

@Det - I will only update once nvidia-utils-beta is updated. I believe the latest 'release' is a dev preview release, unsure if ProgDan will update nvidia-beta to reflect that.

ngoonee commented on 2010-06-09 09:45

Nothing has changed in that specific code, have you done something to your kernel in the meantime? Most likely the kernel has been marked dirty somehow.

M0Rf30 commented on 2010-06-09 09:38

yes it works with USE_PACMAN_VERSION, altought in the previous version of this PKGBUILD ran smoothly also with the for cycle

ngoonee commented on 2010-06-02 23:42

@Morfeo, try the USE_PACMAN_VERSION option, assuming your kernels are installed through pacman and not self-compiled. Alternatively, please pastebin the output of "file /boot/*" (remove the quotes).

M0Rf30 commented on 2010-06-02 23:27

Creating directory NVIDIA-Linux-x86_64-256.29-no-compat32
Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86_64 256.29............................................................................................................................
Building module for \261\323\001\216\211&\001\264\315\230\020\013,
/bin/sh: 001264315230020013,: command not found
/bin/sh: line 1: 001264315230020013,: command not found
/bin/sh: 001264315230020013,: command not found
/bin/sh: line 1: 001264315230020013,: command not found
make: *** [select_makefile] Error 127

ngoonee commented on 2010-05-30 22:31

@Morfeo - Please bring that up with author of nvidia-beta, this PKGBUILD is basically a superset of that one.

M0Rf30 commented on 2010-05-30 09:25

please replace make SYSSRC=/lib/modules/${_kernver}/build module
make SYSSRC=/usr/src/linux-${_kernver}/ module

ngoonee commented on 2010-04-09 23:38

@Alger, your -zen kernel might not include all the necessary headers. Try booting to that kernel and then installing nvidia-beta, it should have the same error. Contact the maintainer for the kernel26-zen package to check with him whether any headers are missing.

@Det - Ah, understood. Thanks. However, this is taken directly from nvidia-beta, I will ask them to make the change which I will then replicate.

Det commented on 2010-04-09 22:10

@ngoone, I mean that "conflicts=nvidia" is not there :D. You have 'nvidia-96xx', 'nvidia-71xx', 'nvidia-legacy' and 'nvidia-beta' but not 'nvidia'.

Anonymous comment on 2010-04-09 18:04

I have a problem with it. I'm using aur/kernel26-zen 2.6.33-1 and when i use this pkbuild it works for standard arch kernel but when it gets to building for zen kernel i get this message:

Building module for 2.6.33-ZEN
If you are using a Linux 2.4 kernel, please make sure ...( and the message prints until it gets to)


the equivalent nvidia-installer command line option.

*** Unable to determine the target kernel version. ***

make: *** [select_makefile] Błąd 1
==> BŁĄD: Budowanie nie powiodło się.
Error: Makepkg was unable to build nvidia-beta-all package.

From what i understand the pkbuild can't get enough information about kernel but i don't know what to do with it

ngoonee commented on 2010-04-06 22:36

@mortan, you say your custom kernels do not have vmlinuzXXX names? Can't remember why I put that check in, I think you can just remove 'grep 'vmlinuz |' from the check.

mortan commented on 2010-04-06 10:41

Ok, found the problem: kernel sources for standard arch kernel were not correctly installed, reinstalling helped. Also one have to name custom kernels "vmlinuzXXX" so that the script can catch it.

Good job btw. I struggled a lot with recompiling nvidia modules for custom kernels, so thank you!

ngoonee commented on 2010-04-05 16:45

Do you have the sources installed for that particular kernel?

mortan commented on 2010-04-05 16:37

Cool, but it's not working for me: when the script tries to build the nvidia kernel module, the nvidia script can't find the sources for the target kernel!

You do a "make SYSSRC=/lib/modules/${_kernver}/build module" but it's not working for me...

ngoonee commented on 2010-03-27 17:05

Yes, it does. You cannot have both installed.

Det commented on 2010-03-27 14:45