You are not logged in.
I came across this thread, and noted some people using towo kernels, so I added add siduction repos to the advanced kernel options section, along with liquorix. smxi actually already had most of the logic in place for siduction repos and kernels, I just hadn't done the last part, adding siduction repos with the one click installer, so to speak. The smxi documentation page, navigation, now notes that.
For users who don't see the default offer to add liquorix sources on the first run of smxi, it means you don't have debian testing or sid repos enabled, so smxi won't show you those options that require a testing or sid/unstable system. Or that smxi thinks you don't have a testing/sid system, if you in fact, do, then smxi is wrong, and you should post a bug report on smxi forums. Or people with CPUs that don't support pae running 32 bit OS as of today will also not be offered liquorix kernels, no point, since support for 32 bit 686 without pae (ie, pentium M) is being dropped anyway.
On the first run, smxi will only offer testing/sid users liquorix option, I want to keep it simple, if they want siduction, they can run the advanced tweak then change their default kernel preferences in smxi advanced kernel options section.
I've also improved the default kernel version handling to automatically check for pae kernels for the default kernel type, if the system supports it and if your system has greater than 3gB of ram installed, and if the kernel type you default to in smxi has the pae kernel, then smxi will use that for 686 system. Currently that's debian and now siduction.
By the way, I should alert you, damentz is switching over liquorix to pae for 686, no non pae version will be offered after he introduces that. That's my fault, I asked him for pae, I run 32 bit and want to use all my ram, heh, but it is time, literally the only 686 cpu that most people might run that is non pae is pentium M, laptop cpu, old now, so it's time to use pae for 32 bit for a cutting edge kernel like liquorix.
The posters above, by the way, are right, smxi will never offer an automated upgrade option, that's totally unsafe, and almost certainly guarantees a failed system over time, which is contrary to the goals of smxi. Smxi wants your systems to keep working over time. Smxi will also never support ubuntu, so don't even think of asking, heh, way too much work and just no fun at all. Sgfxi does support it to some degree however when used standalone mode.
My workstation install was first installed january 2006, and, now, several motherboards later, it's still running. As Sid now, mostly though.
While I don't personally care or benefit either way, I do agree with anticapitalista, it's much easier for end users if you use the stub installer for smxi, it has full instructions in the script top comment header, and it's not that hard to do.
http://smxi.googlecode.com/svn/trunk/sm … /smxi-stub
we had great success with that, users really liked it, back in the days of yore.
Last edited by h2 (2012-12-04 20:40:06)
Offline
^h2
Excellent post of very good information. I have used the stub on a distro I am working on and it is perfect for including it as a default.
If you do not mind I am going to post and link parts of your post to the original post/How To
Thanks for the time you took in educating us even more on the great qualities of smxi.
Offline
Hi
I thought i might give it a go as well ... Unfortunately it failed ... Download Error: smxi component sm-lib-warning could not be accessed
The smxi.log is telling me:
OFFICE_INSTALLED: libre -- OFFICE_AVAILABLE: libre
Function: run_script_import - Utility: Start
Args: sm-lib-warning
Function: test_version_info - Utility: Start
Args: sm-lib-warning
Function: update_scripts - Utility: Start
Args: sm-lib-warning
Function: download_test_file - Utility: Start
Args: sm-lib-warning
download url: http://smxi.org/sm/sm-lib-warning
Function: file_download_error - Primary: Start
Args: sm-lib-warning server-problem
Function: print_error - Utility: Start
Args: yn
Function: print_error - Utility: End
Function: file_download_error - Primary: Start
Args: sm-lib-warning server-problem
Function: file_download_error - Primary: End
Function: download_test_file - Utility: End
Return: 0
Function: update_scripts - Utility: End
Function: compare_numbers - Utility: Start
Args: 2.0.2
returnValue: 0
Function: compare_numbers - Utility: End
Function: test_version_info - Utility: End
Function: update_scripts - Utility: Start
Args: sm-lib-warning
Function: download_test_file - Utility: Start
Args: sm-lib-warning
download url: http://smxi.org/sm/sm-lib-warning
Function: file_download_error - Primary: Start
Args: sm-lib-warning server-problem
Function: download_test_file - Utility: End
Return: 0
Function: update_scripts - Utility: End
------------------------------------------------------------------
The operation you requested requires the library file: sm-lib-warning but it is missing.
Skipping the load attempt and continuing.
smxi cannot continue. Exiting now.
Error No: 100- Function: run_script_importAny ideas how to fix? Thx.
Offline
If sm-lib-warning is not in /usr/local/bin, then let's try and make it.
Open geany, paste:
#!/bin/bash
########################################################################
#### Script Name: sm-lib-warning
#### version: 2.0.2
#### Date: April 15 2009
#### Copyright (C) Harald Hope 2005-2009
#### This program is free software; you can redistribute it and/or modify it under
#### the terms of the GNU General Public License as published by the Free Software
#### Foundation; either version 2 of the License, or (at your option) any later version.
#### This program is distributed in the hope that it will be useful, but WITHOUT
#### ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
#### FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
#### Get the full text of the GPL here:
#### http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
#### Script Author: Harald Hope
#### This is a library file for smxi and cannot be run independently
#### Script URL: http://smxi.org/sm/sm-lib-warning
#### Script SVN: http://code.google.com/p/smxi
#### Script Home page: http://techpatterns.com/forums/about736.html
########################################################################
# get remote server status
# Note: du needs to exit if this file isn't found, otherwise errors can occur in du
# args: $1 - print (optional)
get_status()
{
eval $LOGUS
local ua="-U s-tools/warning-alerts.$WARNING_STATUS"
if [ "$1" != 'print' ];then
wget $ua -T$TIME_OUT -t2 -q -O $SCRIPT_HOME/$WARNING_STATUS $SCRIPT_DOWNLOAD$UPGRADE_DATA$WARNING_STATUS || error_handler 'warning-status-file-missing' $FUNCNAME $WARNING_STATUS
fi
if [ -f $WARNING_STATUS ];then
STATUS=$( cat $WARNING_STATUS)
else
error_handler 'warning-status-file-missing' $FUNCNAME $WARNING_STATUS
fi
eval $LOGUE
}
# get warning text if required
# args: $1 - alert/danger; $2 - print (optional)
get_warning()
{
eval $LOGUS
local ua="-U s-tools/warning-alerts." uaFull=''
if [ "$STATUS" == 'danger' -o "$STATUS" == 'danger-alert' -a "$1" == 'danger' ];then
if [ "$2" != 'print' ];then
uaFull="$ua$WARNING_BODY"
wget $uaFull -T$TIME_OUT -t2 -q -O $SCRIPT_HOME/$WARNING_BODY $SCRIPT_DOWNLOAD$UPGRADE_DATA$WARNING_BODY || error_handler 'warning-data-wget-error' $FUNCNAME $WARNING_BODY
fi
if [ -f $WARNING_BODY ];then
cat $WARNING_BODY
else
error_handler 'warning-data-file-missing' $FUNCNAME $WARNING_BODY
fi
fi
if [ "$STATUS" == 'alert' -o "$STATUS" == 'danger-alert' -a "$1" == 'alert' ];then
if [ "$2" != 'print' ];then
uaFull="$ua$ALERT_BODY"
wget $uaFull -T$TIME_OUT -t2 -q -O $SCRIPT_HOME/$ALERT_BODY $SCRIPT_DOWNLOAD$UPGRADE_DATA$ALERT_BODY || error_handler 'warning-data-wget-error' $FUNCNAME $ALERT_BODY
fi
if [ -f $ALERT_BODY ];then
cat $ALERT_BODY
else
error_handler 'warning-data-file-missing' $FUNCNAME $ALERT_BODY
fi
fi
eval $LOGUE
}
# this isn't properly part of the warning system, but it's still reasonably
# related. This is called in pre du-1, so users can actually remember the config files
# args: $1 - print (optional)
get_configs()
{
eval $LOGUS
local ua="-U s-tools/warning-alerts.$CONFIGS_BODY"
if [ "$1" != 'print' ];then
wget $ua -T$TIME_OUT -t2 -q -O $SCRIPT_HOME/$CONFIGS_BODY $SCRIPT_DOWNLOAD$UPGRADE_DATA$CONFIGS_BODY || error_handler 'warning-data-wget-error' $FUNCNAME $CONFIGS_BODY
fi
if [ -f "$CONFIGS_BODY" -a -n "$( cat $CONFIGS_BODY )" ];then
echo "${M}Answer ${C}y${M} instead of the standard ${C}n${M} if you are asked to"
echo "replace the following config files during $DU_UPGRADE:${N}"
cat $CONFIGS_BODY
echo
echo $MLINE
else
error_handler 'warning-data-file-missing' $FUNCNAME $CONFIGS_BODY
fi
eval $LOGUE
}
# args: $1 - print (optional)
print_alert_warning_data()
{
eval $LOGUS
get_status $1
if [ "$STATUS" == 'alert' -o "$STATUS" == 'danger-alert' ];then
echo $EBAR
echo ${E}"******* CURRENT ALERTS & FIXES"
echo $EBAR
get_warning 'alert' $1
echo
fi
if [ "$STATUS" == 'danger' -o "$STATUS" == 'danger-alert' ];then
echo $WBAR
echo "${W}******* IT IS NOT CURRENTLY SAFE TO $( tr [a-z] [A-Z] <<< $DU_UPGRADE )"
echo ${W}"******* CURRENT WARNINGS(s)"
echo $WBAR
get_warning 'danger' $1
echo
echo $LINE
echo "${S}Please wait to do the $DU_UPGRADE until you have received word "
echo "that it is safe, or until the script runs without displaying this warning."
if [ "$SYSTEM_BASE" == 'sid' ];then
echo
echo "Check the forums and news page of sidux.com for further information."
fi
fi
if [ "$STATUS" == 'proceed' ];then
echo $MBAR
echo "${M}There are currently no known major issues with ${C}$DU_UPGRADE${S}"
fi
eval $LOGUE
}
# issue warning if status = danger etc
upgrade_warning()
{
eval $LOGMS
local ContinueText='' options='' opt=''
print_alert_warning_data
if [ "$STATUS" == 'alert' -o "$STATUS" == 'danger-alert' ];then
ContinueText="${E}Continue with ${C}$DU_UPGRADE${E}. Proceed with caution. Watch for fixes noted above."
fi
if [ "$STATUS" == 'danger' -o "$STATUS" == 'danger-alert' ];then
ContinueText="${W}Continue with ${C}$DU_UPGRADE${W}. Proceed at your own risk!!!"
fi
if [ "$STATUS" == 'proceed' ];then
ContinueText="${S}Continue with ${C}$DU_UPGRADE${S}."
fi
echo $LINE
echo "${C}1${S} - $ContinueText"
echo "${C}2${S} - Continue without doing the ${C}$DU_UPGRADE${S}."
echo " This will let you do graphics install and various other smaller functions."
echo
echo "${C}3${S} - Quit the script now."
echo $LINE
echo $SLE
echo $LINE
options="continue continue-no-$DU_UPGRADE quit"
select opt in $options
do
eval $LOGME
case $opt in
continue|c)
# start xorg install, update, dist-upgrade, xorg component install
install_dist_upgrade 'first'
;;
continue-no-$DU_UPGRADE)
echo "${S}Skipping ${C}$DU_UPGRADE${S} for now. Continuing with script.${N}"
;;
quit|q)
print_quit
;;
*)
print_error opt
upgrade_warning repeat
;;
esac
break
done
}
#upgrade_warning
###**EOF**###Save it as the filename sm-lib-warning in /usr/local/bin
Then try running smxi again, and see what happens.
Last edited by dura (2012-12-06 21:23:55)
Offline
the person has no internet connection at this point, that often happens with a gui network manager that is not correctly configured.
The only reason lib-warning etc fail to download is that there was no internet connection, or something blocked the connection somewhere in the end user network.
These issues are far out of the ability of smxi to handle, the user has to figure out why their networking is failing out of X.
Offline
@h2
Thx. for your message.
the person has no internet connection at this point, that often happens with a gui network manager that is not correctly configured.
The only reason lib-warning etc fail to download is that there was no internet connection, or something blocked the connection somewhere in the end user network.
These issues are far out of the ability of smxi to handle, the user has to figure out why their networking is failing out of X.
I am "the person" and my internet connection out of X is working fine. It is not failing and "something" is not blocking "anything". Actually the script is testing the internet connection by itself and confirms that all is ok - downloading the script, doing the "update" - all is fine except when it stops as indicated.
@dura
Thx. for your advise. I created the file accordingly in the given location and all went fine till the end. I am exploring now my machines (Dell Vostro 131) behaviour.
Last edited by tonyoptical (2012-12-07 06:48:19)
Offline
tony, I've seen this problem before, and, want to believe it or not, it is in fact a networking problem. It can be related to isp caching, or one of a variety of other things, router issues, it's pretty much impossible to diagnose.
I used to see this on maybe one out of 10,000 uses of smxi, and when we spent time tracking it, it seemed to come down to a router or isp issue, but that was out of smxi's ability to collect data or diagnose. While it's been a while, I want to say the bug/issue was triggered by a rapid sequence of wget requests, as you note, the first one, to get the versions file, goes through, but the next set fail.
Now, of course, the smxi server can be momentarily down, but it's usually pretty solid, but a simple retry will deal with that issue if it's in fact the server.
We could never figure out why wget requests would fail in this way, it's some router/isp thing, if it's in fact the request failing and not the smxi server, it's some arcana of router/isp configurations, to resolve it would have required carefully gathering all relevant data, router, router firmware version, isp, connection type, etc, and then we might or might not have narrowed it down, but you can rest assured, if you get this error repeatedly, it's not an smxi or smxi server issue.
Last edited by h2 (2012-12-07 17:53:41)
Offline
@h2...
I am seriously miffed about this. I have never seen the sm-lib-warning in the 4 plus years I have used smxi until now. And I cannot seem to get around it
Here is what led up to it:
New build of an ISO I am working on
Installed WICD as the network manager for wireless needs for users
I also setup the stub for the first time
No matter what I do, I cannot get beyond the sm-lib-warning error.
This is what I have done.
Removed wicd
Gone with stock dhcp setup in /etc/network/interfaces
Gone with static IP in /etc/network/interfaces
Completely removed smxi, including the stub and started over.
Nothing is working with smxi because of the error, on the other hand, I can wget from anywhere I want including the 638 MiB ISO I am working on with no issues from anyone of the setups I listed above.
When I get stumped, it is usually an event...
Going to keep investigating it and will let you know what I find.
Offline
It turns out that the file sm-lib-warning was never installed. And even purging and resinstalling smxi it did not reinstall it.
I grabbed it from another setup I had and put it where it belonged and it solved the problem
Strange that a new install did not reinstall it.
I have seen worse... 
Offline
i've just had this exact same issue installing smxi on a waldorf 64 bit system . . . 
all your Base are belong to us
Offline
I was curious, why use wicd instead of network manager, when the former will not easily support vpn?
Offline
Offline
vastone, you certainly have an issue, if lib-warning is not downloading, which is what is happening, then something is wrong.
smxi issues a series of wget requests when it starts up, the first is I think the versions file, which acts somewhat like a mini apt package version database flatfile, then I think there's a few others, basically as it runs, it will request the non core files it needs if they are required by whatever the smxi user is doing, or if the core files have updated since it was last run. So basically, it appears though I cannot be certain that something in the networking is messing up during repeated wget requests, but beyond that, I can't really say, except to note the fact there is an error somewhere in the setup.
Just as data points, maybe something will click if I note the issues I have seen in smxi support over the years. I already noted the rare isp/router issue, never resolved, but very unusual.
Next, and far more usual, was an issue with gui network manager, I think it was network-manager but I don't know for certain, that has a default setting where only the logged in user is connected, which made out of x actions kill the networking. The fix was to add all users to the network-manager gui permissions, don't remember how to do that, I use ceni to setup networking usually, because it generally just works. Not quite as easy to use for roamng wifi, of course, but works well for real networking. I'd avoid doing things like setting your IP static on the lan, that should certainly not be required, unless there's something really odd in your firewall.
One easy test you can run is to see if the network connections work with wired networking, that's always a good default test, wifi will always fail if you give it a chance, wired, almost never. If the issue persists out of x with wired after configuring networking with ceni, then there's something very hard to figure out going on in the system, which I'd actually be interested in knowing the cause of just as a generally good to know thing that can go wrong. Ceni is my preferred network configuration tool.
If smxi got the version sm-versions file, then fails on a subsequent request, that's not correct behavior of the base system, it should be largely agnostic about the frequency of requests being sent, unless there is something wrong or a bug has manifested, of which this failure is just a symptom, not a cause, so it might be worth tracking down.
Offline
@h2. I personally have never used a network manager, preferring good old /etc/network/interfaces...
I never have seen this until this wicd install for the ISO I am working on. Now that I know what it is, I have solved the problem and can move on.
It was really weird that a new install did not get the correct files... What I will do this time though is remove smxi from within the smxi script and see if that makes a difference.
Thanks for the discussion!
Offline
i've just had this exact same issue installing smxi on a waldorf 64 bit system . . .
@h2
it's not just v1 that has this issue.
all your Base are belong to us
Offline
I am having the same issue with the sm-libs-warning missing, and reinstall doesn't fix it. I am having this problem on a fresh install of Waldorf. Also, I unfortunately don't have a copy of the sm-libs-warning file to paste in the directory to fix this either. Is there any place that I could grab a copy, or maybe an archived version of smxi that would contain it? Any help is much appreciated.
>lurk moar
Offline
^ There is one in this thread that dura posted.
Look back to a post by dura
@h2
On a complete purge of smxi from within smxi, I still had the same issue. I am heading over to the smxi forums to report all of this
Offline
Just to make sure this wasn't some mistake on my part, which has happened, heh, I did a real check, sm-lib-warning is present on server. Then I removed sm-lib-warning, and ran smxi again, after having removed the file physically from the local machine, and it is present and downloads exactly as expected prior to the upgrade section. I confirmed this checking to make sure it had downloaded, it has.
so there's some issue with networking in crunchbang I have to assume.
The file failing to download means, and this is particularly pertinent now that several users report the issue, that there most likely is something going on in the networking stack of crunchbang, what that is, I cannot say.
Keep in mind, manually downloading that file and replacing it does NOT fix the underlying cause of the problem, which is one or more wget requests failing to go through.
Again, i want to urge you NOT to just download a file and replace it, because the reason it did not get downloaded is not corrected, and those types of failures may impact other areas of the system as well during an upgrade. This is definitely the type of issue you want to resolve before proceeding in my opinion. I've seen a lot of particular errors and failures in my years of doing smxi, but I've never seen one like this, so I have to assume there's a new factor at play.
Last edited by h2 (2012-12-11 23:02:00)
Offline
^ Just for clarity, I am a pure debian user and do not have CrunchBang on this system I am having issues with.
I will point to this thread when I report it on the smxi forums... Life got in the way and I have been a bit busy and forgot to do it earlier
Thanks h2
Offline
I found a solution.
When prompted with a warning about missing sm-lib-warning, press Y to exit the process and return to the command line. Once there execute the following command from /usr/local/bin/:
wget http://www.kahealani.com/posix/bin/sm-lib-warningOnce it's downloaded, restart smxi using the smxi command and resume where you left off.
Offline
I found a solution.
wget http://www.kahealani.com/posix/bin/sm-lib-warning
A better source is probably:
http://smxi.googlecode.com/svn/trunk/sm-lib-warning
Offline
I'm not sure I can make this anymore clear. without repeating myself. Manually downloading a file that should have downloaded automatically is NOT a solution, it's a quick hack that does NOTHING to fix or remedy the actual problem.
I was trying to remember why smxi grabs the lib warning file even when you grab the zip file and extract it, and then I remembered, it's precisely because if networking is broken and fails to download the lib warning file, that means the upgrade should stop until you find out why networking is broken, and smxi will exit with error, precisely as intended, it's a sort of failsafe builtin tool,so to speak..
However, I'm not going to pursue this any further, something somewhere is wrong, and I have no way to help fix the issue since the smxi server itself is fine and smxi is fine.But I do want repeat, for the last time, if a file failed to download, that means you really have to figure out why, running upgrades with something glitchy is a very high risk activity, and not one I would support or encourage.
Offline
I should have asked for this before, but if someone who experiences this issue can post a link to the entire smxi.log file, it's important that it is the entire file,from smxi start to the lib-warning error, otherwise it doesn't do me any good.
It is possible that there is something totally unrelated going on causing the issue I just realized, and sometimes the full log file will show me what that is.
If you have the lib warning file installed, just remove it, and rerun smxi, then if it exits with error, post the log file. Do not post log files from smxi runs that worked.
I've tested this on a few of my standard debian systems, and there is definitely something causing a break that is not in regular debian, and there's a small chance that smxi logs will show the difference.
Use pastebin.net to post the log file they are very verbose and long.
You can also upload a full inxi debugger output with:inxi -xx@ 14
that uploads to the servers automatically and might show a difference somewhere as well, run that OUT OF X, the same way you run smxi, so the data will be the same.
If we're lucky, between these two we might, maybe, find the actual cause of the problem, it depends on if the problem is logged or not.
Last edited by h2 (2012-12-13 06:58:30)
Offline
'I also setup the stub for the first time'
oh, I'm kicking myself, I missed this key phrase.
Show this on a system with that stub:
ls -l /usr/sbin | grep -Es '(smxi|sgfxi|svmi|inxi)'
then:
ls -l /usr/bin | grep -Es '(smxi|sgfxi|svmi|inxi)'
ls -l /usr/local/bin | grep -Es '(sm|sgfxi|svmi|inxi)'
post the complete output for each one, it's important that I see the actual full list output, permissions etc
also, as ROOT, show this: echo $PATH
Last edited by h2 (2012-12-13 07:12:11)
Offline
EDIT: Please disregard the remainder of this post; I didn't realize h2 is, in fact, on the SMXI development team.
@h2: "I honestly think you ought to sit down calmly, take a stress pill, and think things over."
Yo have a very valid point; smxi is marketed (yes, it's free, but I can't think of a better term..."touted" maybe?) as a one-stop-shop for proprietary nVidia drivers and the latest Liquorix kernels, and having to manually download a required file falls means one of the package maintainers there is asleep at the wheel. But please remember, the time at which you posted these last three messages is bedtime for a great many of us. VastOne has already said that he's brought this up at the smxi forums, so I'm sure they'll get this sorted soon.
while ( ! ( succeed = try() ) );
We've earned a reputation as a nice, friendly community; please help us keep it that way.
Offline
Copyright © 2012 CrunchBang Linux.
Proudly powered by Debian. Hosted by Linode.
Debian is a registered trademark of Software in the Public Interest, Inc.