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?)
(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: 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: [email protected]
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 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 "/
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.
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)