===========================================================================

===========================================================================
 Script FAQs
===========================================================================

Here are our FAQ pages. These will be updated as more questions appear. What, after all, is a FAQ without a question?
----------------------------------------------------------------------------

----------------------------------------------------------------------------
Answers to Questions, Frequently Asked or Not
----------------------------------------------------------------------------

If you need to ask a question that isn't answered here, please use the script forums. For specific smxi or sgfxi questions that aren't covered here, check the script specific FAQ pages:

----------------------------------------------------------------------------
What does smxi look like?

It looks pretty much exactly like these web pages (assuming you are using a GUI, CSS supporting browser, of course). The only difference is that instead of clicking on links, you type in the number and hit enter.

The only time it's different is when you start either svmi or sgfxi alone, without smxi, then their default fonts are blue, like this.

But you can always also change the default color scheme with the -j option (see -h for color schemes), which all the scripts also support, except inxi, which has its own color schemes.

top

----------------------------------------------------------------------------
What is the general structure of smxi / sgfxi /svmi?

Please see the docs page navigation for full layout and structure of smxi. This shows most of the features included in smxi, and the order they appear in, along with explanations of various distro specific things you may or may not see.

If you want to see the actual programming structure, you can run these commands, which will show all functions and main structural sections of the scripts. 

# for just smxi
egrep '^([a-z](.)*\(\)|###)' /usr/local/bin/smxi

# for all of smxi and library scripts
egrep '^([a-z](.)*\(\)|###)' /usr/local/bin/sm*

# for sgfxi
egrep '^([a-z](.)*\(\)|###)' /usr/local/bin/sgfxi

# for svmi
egrep '^([a-z](.)*\(\)|###)' /usr/local/bin/svmi

# and for inxi
egrep '^([a-z](.)*\(\)|###)' /usr/local/bin/inxi
top

----------------------------------------------------------------------------
What script options are available?

All the scripts have a full help menu, which you activate by starting them with the -h option, like so: 

smxi -h

#or
sgfxi -h

#or
svmi -h

#or
inxi -h

See also the docs page options for more information on how to use the more common options.

top

----------------------------------------------------------------------------
Do the scripts support aptitude?

Yes they do. Full, native aptitude support is an option for all users. All users with aptitude installed in their systems will be asked the first time smxi, sgfxi, or svmi run, whether they want to use apt-get or aptitude as their default package management tool.

After this first question, the scripts remember your selection and won't ask you again, though you can always change your answer in smxi, located here:
Post Upgrade Options -> Miscellaneous Tweaks -> Advanced Tweaks -> apt-type

Manually editing /etc/smxi.conf to add apt-type=aptitude

If you didn't have aptitude installed when you first ran smxi, then you can edit (as root) the file: /etc/smxi.conf
and add this line (but first make sure there's no apt-type= entry already there!): 

apt-type=aptitude

The other possible value is: 

apt-type=apt-get

Then, the next time smxi (and svmi and sgfxi) runs, the script will use aptitude as the default instead of apt-get.

After you add this, you'll also be able to use the Post Upgrade Options -> Miscellaneous Tweaks -> Advanced Tweaks -> apt-type option to switch should you want to do so, but in general, it's best to stick to aptitude once you switch to it.

More information on switching to aptitude from apt-get

Read more on switching from apt-get to aptitude on the script forums.

top

----------------------------------------------------------------------------
How do I know when a script update occurs?

All the system maintenance scripts (smxi, sgfxi, svmi) update themselves automatically each time they run, or each time smxi runs them. smxi itself has a mini updating system I like to call mini-apt because it's like a tiny version of apt in how it works. sgfxi and svmi, if started by themselves, simply update themselves automatically each time they run.

One reason these scripts have always worked so well for people is that they are always up to date, by definition, and thus are able to cope with new issues before the actual apt update itself starts.

In other words, all the system maintenance scripts are install once, then just run as long as you like.

inxi, on the other hand, only updates via apt (if it's installed from apt), like any other package, or by the end user doing it with the -U option, or if you choose the inxi install option in smxi, which will always update inxi to the latest version as well.

You can also, if you are so inclined, sign up for the Project Feeds (that's smxi's in this case, but each svn has its own feed). Few things are less interesting to me than watching code changes roll by, but, again, each to their own.

top

----------------------------------------------------------------------------
Where can I track changes to the scripts?

You can always track changes at the script svn sites (smxi, sgfxi, svmi, inxi). Personally, to me looking at svn change logs is not very interesting, but each to their own.

For anyone more seriously interested in tracking svn, for example, if you want to use one of these scripts in your distro, you can also be added to the svn update email list. Please post in the developer forums and ask about that.

For more normal changes, you can also just track the various script library threads in the main forums, those tend to just have the more interesting changes, that will actually be of interest to people, ie, new drivers, new features, and so on. Here are the forum update threads for each project:

You can also, if you are so inclined, sign up for the Project Feeds (that's smxi's in this case, but each svn has its own feed). Few things are less interesting to me than watching code changes roll by, but, again, each to their own.

top

----------------------------------------------------------------------------
Something scrolled by. How do I scroll back up in terminal?

Don't worry, the terminal stores about 6 screens or so on average. You can move back up using shift+page up, and move down again with either page down, which returns you to where you were, or with shift+page down, which moves you down one terminal screen.

If you want to stop the output of the screen, just hit the ScrLk key, then you can move up or down from that point. This is useful if the upgrade has started, and you want to see something you may have missed before you have gone past the 6 screen limit.

If you are using the smxi -G option, you can run smxi in X, but the upgrade/graphics install sections are turned off. If you have your terminal/console (like konsole/xterm) history turned up high, you can scroll up as far as you want.

top

----------------------------------------------------------------------------
Do I have to type in all these horribly obscure commands?

Of course not. This is Linux, and hackers are lazy. The easiest way to enter any command you see is to simply highlight it with your mouse, then, without clicking anything, move your mouse over to your terminal window (aka console), and click once (left mouse button) to activate the window, then click down on the mousewheel, assuming you have that feature in your mouse. This will paste the entire thing you highlighted into the terminal, and, if it's a single line, all you have to do then is hit enter, and it will run the command.

The first thing you should learn about Linux like systems is that hackers and programmers are a lazy bunch of people, so there is usually some easy way to do things you have to do all the time.

You can also do this out of X, in the actual console, if you have gpm installed, which allows the mouse to work in console, out of X. This is a very useful feature, because you can actually copy something, say an error message, in one terminal, then change to another one (ctrl+alt+F2, for example), login, start nano or some other text editor, then simply click your center mouse button, and the entire thing you copied will appear, all without X running at all.

top

----------------------------------------------------------------------------
How big are the smxi / sgfxi / svmi scripts?

These things are getting really big.

Altogether, smxi/sgfxi/svmi are a bit more than 20,000 lines of code, and growing. smxi has more than 10 library files, plus the main script engine, and 2 modules, the stand-alone sgfxi and svmi scripts. The smxi back-end stuff is about 1000 lines.

Every system that runs smxi/sgfxi/svmi, of course, won't have every file or library, or won't have a current one, so your results will vary a bit.

The new inxi script is heading towards 3000 lines, and will probably pass that soon. But it's not a direct module of smxi, so I don't include that in the total code count.

If you want to see for yourself, just run this command, after you have all the script components. If you haven't run every module or section, you won't have them all. 

find /usr/local/bin/sm* /usr/local/bin/sgfxi* /usr/local/bin/svmi | xargs wc -l

And that's the answer to that question.

Now, if you ask:
Should I consider making a Bash script with the potential to get this big?
the answer is definitely NO!!!!

However, I had no idea it would get this big when I started it, although I did start it with the idea of making it maintainable, ie, using structured, standard programming methods.

Unfortunately, Bash is just not a very good language, though it is kind of fun to work with I have to admit. Sadly, trying to make it work like a normal programming language can be quite a challenge, it definitely seems to invite poor programming style and habits rather than encouraging good ones.

top

----------------------------------------------------------------------------
Where can I post problems/bugs?

Please post bug reports in the script forums. You can use one of the following threads:

For sgfxi specific bugs, also read the sgfxi bug reporting section.

top

----------------------------------------------------------------------------
smxi / sgfxi / svmi had an error, what do I do?

Report the error if it's new, or unexpected. Use the bug reporting options to do this.

In general however, most errors are much more easily diagnosed if you use a paste website such as http://paste.debian.net and upload the relevant log file using their convenient file upload feature, then just copy the link you get for that paste page to the script forums.

Do not paste the log files directly into the forums! They are too big.

It takes FAR less time to diagnose an issue using the log files than it does to try to get the information from you piece by piece in most cases.

You can find log files for the following scripts here:

rbxi and inxi do not use log files, so just post your questions/observations in the script forums.

top

----------------------------------------------------------------------------
Are there manuals for smxi/sgfxi?

There are basic manual pages, which I try to keep reasonably up to date, for smxi and sgfxi, along with a wide variety of documention you might want to also take a look at. The documentation should cover the standard operating questions you'd have. I'll update and improve these as user feedback lets me know the manuals are missing parts, or are unclear.

I hope these help answer any questions you may have, if not, you can always ask on the script forums.

top

----------------------------------------------------------------------------
How are the scripts licensed (GPL, etc)?

All scripts here are licensed either GPL 2 or later or GPL 3 or later.

Here are the licenses currently used by the projects as of 15 February 2009:

This is probably where it will stay for a while now, unless of course there is a new GPL license released, then I'll upgrade all the 3 or later items to the new version. And you of course are free, because of the 'or later' clause, to use this code in any future GPL project.

top

----------------------------------------------------------------------------
Do smxi/sgfxi/svmi support my Debian bsed distro (like Linux Mint Debian, Aptosid, Antix)?

smxi, sgfxi, and svmi support all Debian based distributions. sgfxi also supports all Debian derived distributions like Ubuntu.

If something isn't working right, either there's a bug in the script in question, or the distro doesn't use standard Debian methods. For example, Mepis uses some non standard methods so not all features of smxi work with it.

Debian based distros that ship with smxi tools that I am aware of, as of 2010-09-22:

Distros I am aware of with full script support, in other words, all features should work:

top

----------------------------------------------------------------------------
smxi or sgfxi cannot locate any /boot/grub/ config files unable to continue

Yes, smxi / sgfxi even supports fringe user cases, with non-standard grub locations. The most complete discussion can be found on techpatterns.com smxi forums.

However, I'll summarize the content here again in terms of how to deal with the no grub found due to it being mounted somewhere else, say: /media/sda2/boot, for example.

You can set this yourself I think, simply use the smxi sticky options or sgfxi sticky options.

While i don't say it in that documentation, you can set any hard coded global that is set in the top part of the script to whatever you want, so in the case of sgfxi we find:

sgfxi grub path data

GRUB1='/boot/grub/menu.lst'
GRUB1_FED='/boot/grub/grub.conf'
GRUB2='/boot/grub/grub.cfg'
GRUBED='/etc/default/grub'

Clearly, since the script autoupdates, we don't want to edit those directly. However, none of these are hardcoded anywhere else in the script, so the script will test for the content of these global values so you simply take the one you want, let's say GRUB1, and do this: 

echo GRUB1='/etc/somewhere/grub/menu.lst' >> /usr/local/bin/sgfxi-values

Note, grub 1 is for the old menu.lst, grub2 needs all the relevant ones, at least grub.cfg, maybe also /etc/default/grub - now you'll note at about line 358 this, which imports, if present, the user data files:

smxi grub path data

smxi requires a slightly different grub syntax, these are the variables you will need to adjust in the config file: 

GRUB_PATH='/boot/grub/menu.lst'
B_GRUB_2=false

So you'd do this, say you are setting it for grub 2, note we need the boolean B_GRUB_2 set to true if the local system is using grub 2. 

echo GRUB_PATH='/etc/somewhere/grub/grub.cfg' >> /usr/local/bin/smxi-values
echo B_GRUB_2=true >> /usr/local/bin/smxi-values

How the data is included in the scripts

# allow user set globals to override script globals
if [ -f $SM_VALUES ];then
	source $SM_VALUES
fi

smxi, svmi, and sgfxi, and I think inxi, have this. smxi, sgfxi, and svmi require the config alt file to be named for ex: sgfxi-values, smxi-values and to be in /usr/local/bin

Any hard coded value there, or any option set parameter, can be set there permanently.

sgfxi - custom case

For example, let's say we always just want to always use the new skip grub test option -! 33 (sgfxi, in this case) since the system is fine for sgfxi: 

echo B_SKIP_GRUB_TEST='true' >> /usr/local/bin/sgfxi-values

now sgfxi will always skip the grub test when you type this in: sgfxi

Benefits of using the config files for permanent changes

I tend to forget these config hard codings, but they are documented, though I don't generally want people to do things out of the ordinary, but you certainly can if you have those needs.

So sgfxi, as well as smxi, always have had this option.

Keep in mind when you do this, the option or change is ALWAYS an override, to get rid of it you have to delete the entry in the sgfxi-values file, no comments are supported.

top