On a How To I started for smxi on the CrunchBang forums, several people (me included) have brought up an issue with smxi failing to run due to:

Download Error: smxi component sm-lib-warning could not be accessed

Starting at this thread link on the forum you can follow the issues and the help that h2 has provided.

I have been an smxi user for years and have never encountered this issue, or any for that matter. The amount of people it is affecting is the concern.

I meant to post this sooner but I have been away for the birth of my granddaughter... Which happened 12-12-12 and all is good.
Back to top

based on what I saw on the other thread, there's a bug somewhere in the networking, that's a guess.

Take any live cd that is debian based,not ubuntu, and run smxi on it, you'll see for yourself,hopefully, that everything acts normally.

Make sure to run it on the same systems that manifest the issues. Once you remove the hardware and external networking as causal factors, you'll get closer to the source of the problem.

I've tested this on 3 systems I think, there is no.(mainly because there really technically can be no) issue with the smxi server or smxi.

You can collect data locally but these types of issues are very hard to pinpoint.

The first thing to do is exclude components, and a live cd running on your hardware is the easiest way to do that. Try siduction for example, or antix if it has a livecd option.

Download and install the files, just smxi alone should be adequate, then run it.

run it to the upgrade section, if the problem persists, then try another computer. If the problem goes away, it's the os.
Back to top

Ok, to update this, and to rule out any issues caused by my local dev systems, I did what I suggested you do, booted a siduction live cd, downloaded and ran smxi.

I did conveniently find one small bug that made the liquorix kernel sources not authenticate properly, so I fixed that, but that would not have caused your issue, that was unrelated, came from a recent update I did.

I also noted some legacy holds that had not been removed, again, that would not have caused the issue, just a nice thing to clean up.

So here's the score: from my system, my isp, my router, everything works exactly as expected.

By the way, to clean the system between tests, you can start smxi with -Y, like: smxi -Y

then select the last option, clean scripts and data, that will look for and delete anything smxi related so the system will act as if it were new, minus any apt sources or packages you installed, of course.
Back to top

Oh, I'll post this.

Create a test directory in home, then inside that create a file, say, smtest

inside the file place this content:



make the file executable: chmod +x smtest

Then run the file. A few times.

Then try running it as root.

Then try running it out of x as user and as root.

This might or might not trigger the event.

To make it more similar, one can add a timer between wgets, like:



that will even more closely duplicate the execution. However, it's not perfect, because other things didn't also run, like: apt-get update, which also creates quite a bit of network activity, particularly if you don't have pdiffs turned off, a lot of requests done very quickly from apt as well.

In the mean time I'll see if I can get anyone outside of crunch to duplicate this issue.

Basically, the point of running tests like this is to pinpoint just what makes the system's networking fail at a certain point, or wget fail, or whatever it is that's failing.

I suggest you clean up the other forum's postings on this subject, or ideally move them to a new thread, it disrupts your actual thread, sorry about that, I should have started a new thread, but I didn't realize this was a more widespread issue for you/your users.
Back to top

I'm sad to report that this was in fact an smxi bug, related to the handling of /etc/os-release, which used a different syntax and method than lsb-release.

smxi had imported the inxi logic for that but that logic actually required much more modification to run properly in smxi, oh well, live and learn.
Back to top

Thanks for this and I am glad you got it sorted out.

I also appreciate the help that xaos52 gave on the thread over on the CrunchBang forums

I am a moderator over there so I will split out the issues from the original thread to a new one so users can use it as a reference.

Thanks for all you do and your help

VastOne
Back to top

well, consider yourself added to my unofficial list of distro people I pay particular attention to their issues. In general, post here with issues, and point crunchbang users to post here, it was actually a total coincidence that I found that thread, was just bored one night and searching at random. Or use irc.oftc.net #smxi and leave a message there, but I just track it, I'm not always on it.

What's annoying is I started seeing signs of this issue in another area but didn't connect the dots, maybe a month or two ago, but I thought the cause of that was something totally unrelated, so that's actually two issues fixed, which is nice.

I'm going to guess that debian removed the lsb-release file or had os-release replace it, which then triggered a fallback detection in smxi that hadn't actually been properly done by me, but which lay inert until it was activated, which was where the bug occurred. My systems didn't trigger it because they all have distro files that made the fallback mode of lsb/os-release detection not run, so I didn't see this issue, sigh. Or they are old, or I was testing with a livecd from a year or so ago, that also had a distro file that blocked the use of os-release.

What's extra annoying was that something in the back of my head kept saying it might be distro file problems, but what I thought it might be it wasn't, but it was in fact a distro file id problem, ah well.

I've also I think changed the order, and now use os-release as primary, and lsb-release as secondary, unless smxi detects a supported distro file in /etc.

Sigh, always something.
Back to top

I have been at this long enough (26 years) to feel comfortable in saying this:

If I report an issue, you can be 99% assured there is something broken.

I mean no disrespect to anyone with that statement

Glad to be a part of the unofficial team! :D

Cheers.
Back to top