Yes it was my typo in the shell!

My apologies for the false alarm. All is good now.

This install has 4 kernels. I built modules for the non-running ones with -k -K option, deleted them, rebuilt with -X -K with no errors.

Multiple kernels and nvidia.are now a lot easier.
Back to top

great, thanks, at this early stage I expect logic errors and weird little bugs to happen as different systems come to light, but all my research showed me that the paths I'm testing, amazingly enough, are consistent across debian, ubuntu, arch, and fedora.

At least I'm assuming ubuntu is the same, haven't tested it yet.

It took a lot of testing though to get it this solid, many days, so I'm looking forward to letting sgfxi slip back into stable mode, this fast development eats up a lot of time and is very tiring, and doesn't let me do anything else until it's done.

And remember: to install a new driver release, simply do, out of X:

and you will have the new driver and modules in all your kernels right away. That will remove all modules and uninstall the driver, then it will update and rebuild the driver modules for all the non current kernels.
Back to top

EDIT
I think the size of my logs caused website corrruption so spreading over a number of posts as code boxes failed.

1) Firstly I found a log where I used smxi and you can see the old way worked



< Edited by aus9 :: Mar 6, 10, 15:26 >
Back to top

I have elected to show you only the last log....which is a fail for me.

I had to edit xorg to nv to post.....don't worry I can recover using partimage......heh heh


Back to top

and nvidia log


Back to top

its early sunday morning and I have only just started to wake up.

maybe because I have no other kernels I should not have attempted the sgfxi command from page 2....but I leave the above junk here in case h2 needs it.....and builds a test that if only one kernel found ...spank the user for testing toooooooooo much


have a great day
Back to top

thanks for the logs, in the future please use paste.debian.net for anything larger than common sense would suggest fits into a forum posting.

However, the logs showed exactly what is wrong.

Because nvidia rolled back their default driver 195xxxx to 190.53, but because you already had the 190.53 kernel module built, but since building it, you'd moved to kernel 2.6.33, which uses a new path to the headers, /generated/ instead of /linux/ what happens is that the patch trigger does NOT run on the module rebuilder, but the patch is required to install these drivers.

Solution, do this: sgfxi -f
to force driver reinstall, which will also patch the driver.

You basically hit a fringe case, which I'll have to decide if it requires special handling, but realistically, nvidia has almost never pulled out a driver like this, so I think this is a fringe case not requiring special handling, but it is a weakness in the module builder, and it should probably have some way of testing, but it's tricky with stuff this specific.
Back to top

I added the suggestion to use sgfxi -f if module build fails, but unfortunately, this exposes a real bug in the logic here:

The bug is simple, and is limited to rare situations, but unfortunately we are in that situation now:

driver requires patch to run on new kernel, but f you patch installer it will fail on old kernel, thus breaking the ability to seamlessly handle building modules for every kernel.

However since basically new nvidia drivers usually contain the patches, and get rid of the problem, this issue will only exist until nvidia releases fixed 195x drivers, which shouldn't be that long.

This was just an odd set of circumstances, ie, kernel 2.6.32 does not have /generated/ path, 2.6.33 does, but nvidia installer 190.53 requires patch to install to 2.6.33.

I think I won't do too much with this issue though, just note it exposes a slight weakness in the overall logic, but it's too hard to cleanly handle that I think so I'll wait until maybe an idea hits that would smoothly allow for patching or not patching driver installer file. (like... for example: running patch tester, if requires patch, then apply patch to a new copy of the file, used temporarily, or something...)
Back to top

hi

paste.debian.net.....will not allow more than 90kb pasting.

ok so restored partimage...image....tried smxi and did not update kernel....ran sfgxi -f....and reboot failed.....no log.....

ok redid smxi with kernel update option so




summary....log says fail but I am in X using 190.53

weird...somewhere my eyesight spotted one of your messages that Nvidia recalled a driver so not sure I am on right driver.

But it works..heh heh.

latest /var/log/sgfxi/sgfxi.log is here

stashbox.org/815408/sgfxi.log

nvidia log is here

stashbox.org/815409/nvidia-installer.log

regards
Back to top

what's happening there is something I've seen before, the nvidia installer is returning an error about something that happened, but the actual driver install worked.

I saw this in Arch too.

So sgfxi gets sad and confused, because it queries the nvidia installer and asks it, so, did the install work or fail, a return value of 0 means success, > 1 is error. There were some weird glitches there, that caused the installer to return 254, but they didn't make the install fail.

In a sense this is a bug in the nvidia installer, it's almost as if the guys don't expect anyone to actually evaluate the return error codes, and sgfxi isn't smart enough to know when the error codes aren't important, so it says, oh, sorry, install failed.

I saw this in arch with a libgl thing, nvidia installed but gives an error return unless you've reinstalled libGL, but there's no way you would know that in arch/nvidia unless you read the return value of the nvidia installer, then read the logs, both of which I've done.

sgfxi now includes the nvidia error logs in itself on install failure so you don't need to include the nvidia error log.
Back to top