Could testers with nvidia (old and new) post feedback on whether it is ok in this build. On my box, using sgfxi -f fails, but using smxi and choosing the debian way with siduction repos enabled works.

Please post your feedback and any tricks/tips/advice

Run fine and All I did was select the time zone.

Graphics: Card: NVIDIA G86M [Quadro NVS 135M] bus-ID: 01:00.0
Display Server: X.Org 1.16.4 drivers: nouveau (unloaded: fbdev,vesa)
Resolution: 1440x900@60.00hz
GLX Renderer: Gallium 0.4 on NV86
GLX Version: 3.0 Mesa 10.3.2 Direct Rendering: Yes

Machine: System: Dell product: Latitude D630
Mobo: Dell model: 0WM416 Bios: Dell v: A07 date: 01/30/2008

Do you mean the nvidia-nvidia driver, or nouveau?

When I tried to start sgxfi, I was told it looks like it is not a debian/ubuntu/arch install.
But, if it is the proper nvidia driver you mean, I will try it later

proper nvidia driver

Test one:
a core install, smxi would not start, sgfxi would not start.
Changed line 1 in etc/lsb-release from antix to debian, and it starts fine.

Selected the debian-nvidia option, and it needed a reboot, then running sgfxi again, I did, and it seems to work fine?

I did not mess with repos and such.

test2,
A full install.
sgfxi and smxi did not work, edited etc/lsb-release to say debian, and etc/debian-version to say 8
(which I am not sure if is the right number)
Now both start ok.

Used sgfxi and the"driver with xorg.conf" installed, but, again it needed a reboot.
Looks like it works, (something looks different) but no, it went to the vesa driver.

Going to try the debian-nvidia driver now.
update
That also failed.
What would make the full install different to the core version, when it comes to this?

The 173xx & 96xx nvidia legacy drivers which supported older nvidia cards were removed from the repos while Jessie was in development because they lack support for the 1.16 Xorg version that Jessie is using. (and you won't really get a better result with those cards using smxi/sgfxi)

In Jessie those old nvidia cards are pretty much limited to using either the nouveau driver or the vesa or fbdev non-kms drivers.

The following cards used to use the 173xx driver (the output of the command below) And these cards used to use the 96xx legacy driver (the output of the command below)

live, semi-automatic dynamic root persistence

sgfxi would not proceed, complained unknown distro until I edited both etc/debian-release amd etc/lsb-release
(or I pointlessly tried editing, or creating, the first one... but sgfxi was checking for"debian" in the other?)

advice:
(from sgfxi script, line 2452)

errorData="This does not appear to be a Debian/Ubuntu/Arch based system!
If you know that it is\nand received this error, please let the maintainer know and he'll try to correct the distro identification failure.
Post on the script forums:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://techpatterns.com/forums/forum-33.html"
linktext was:"http://techpatterns.com/forums/forum-33.html"
====================================
with your system information,
including the contents of these files, if present: /etc/issue /etc/debian_version /etc/lsb-release"

What would be a suitable check condition?
if (lsb-release exists, and contains substring 'antix')... ?

Then, when sgfxi had completed its first run (preinstallation?) and advised a shutdown/restart...
this (reported, and a fix is pending) bug in the current shutdown script(s) prevented the changes from being saved

. . .
persist-autosave: Possibly save persistent information
/var/local/bin/persist-config: line 144: local: can only be used in a function

(after which the system is unresponsive until rebooted)

So, grabbing at straws, I hacked the persist-autosave scriptfile ~~ just removed the several instances of"local" from the var=value lines.
Afterward, sgfxi successfully installed nvidia driver

Graphics: Card: NVIDIA GT215 [GeForce GT 240]
Display Server: X.Org 1.16.4 driver: nvidia
Resolution: 1920x1080@60.00hz
GLX Renderer: GeForce GT 240/PCIe/SSE2
GLX Version: 3.3.0 NVIDIA 340.76

It's working OK, as far as I can tell (I usually just stick with noveau).
To test, I played a couple youtube videos & visited
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://jsdo.it"
linktext was:"http://jsdo.it"
====================================
and ran some of the WebGL demos

Are there any side-effects, repercussions, from creating/editing the files debian_release and lsb-release ?
( sgfxi errorscreen also mentioned"/etc/issue" )
The sgfxi installation steps span reboots, so a wrapper script (move those files, run sgfxi, restore those files) is probably not feasible, eh?

The"driver installation" operation balooned (added 320Mb to) the size of my persistence file.
I was expecting to see SOME increase, so in advance I uppded the size of the persistence container, but I wasn't expecting THAT much.
During sgfxi's `pre-installation` run, I saw lines mentioning"build-tools" and whatnot scrolling up the screen...
I suppose I'll check the apt, er, dpkg logs; I'm inclined to remove the extra packages which were needed during install.
advice? If antiX devs create a sgfxi wrapper script, consider including a user choice to have those extra build packages purged.

As a testing followup, I intended to purge the 'nouveau' packages... but cannot do so. They're part of Xserver metapackage or somesuch.

initramfs needed to be rebuilt when the driver was installed.
How large is that ? (I haven't checked)
and... until/unless I perform a snapshot operation, are multiple copies (initramfs? kernel?) taking up space on the pendrive?
(I'm now trying to determine/understand what comprises the additional 320Mb storage overhead.)
So far, I've determined that it's PARTIALLY due to the previously-reported"aufs plnk" live persistence bug
and I'll followup by posting to the current development discussion.

advice:
Persistence user needs to know approx how much additional savefile space will be required
so that s/he can, in advance of upgrading driver, increase the savefile size if necessary.
(Here, I'm suggesting a message displayed to screen via what I'm envisioning as a 'wrapper script'.)
I'm now fairly certain this was a roadblock during my prior attempts (previous builds) but at the time didn't realize the reason for the failure.
OTOH, during those prior runs, I don't recall sgfxi displaying onscreen clues about specific problem files (lsb-release, debian_release)

For the issues with smxi and sgfxi maybe h2 (the developer and maintainer of sgfxi and smxi) should be aware that AntiX is a Debian distro so that he can add support for AntiX in his scripts.

DeepDayze wrote:For the issues with smxi and sgfxi maybe h2 (the developer and maintainer of sgfxi and smxi) should be aware that AntiX is a Debian distro so that he can add support for AntiX in his scripts.

sgfxi gets past the distro type testing it does if I create a /etc/debian_version file with the following: (and I didn't need to make any changes to the /etc/lsb-release file)

$ cat /etc/debian_version
8.0

antiX-15-beta2 had a /etc/debian_version file, but it looks like it's been replaced by the /etc/devuan_version file in antiX-15-beta3

$ cat /etc/devuan_version
jessie

So I think either the /etc/debian_version file needs to be added back to antiX-15, or maybe h2 needs to add support for Devuan distros to smxi/sgfxi.

I asked h2 to make the change to smxi/sgfxi/inxi to recognise devuan and he did.
Installing nvidia via sgfxi works as it has always done on my nox now.