I noticed you said choose the sid plus sidux option.
In antiX there isn't one that directly states this.
It gives the options:
1. no change
2. sidux
3. sidux-conversion

Aptitude choice does work fine. (I had tried it on a box where aptitude was not installed)

Where abouts in the script can I look to see if there is a possible typo in the script? Another pair of eyes might help.
Thanks
Back to top

Check two things: file permissions on /etc/apt/sources.list ( ls -l /etc/apt/sources.list )

paste your actual /etc/apt/sources.list onto paste.debian.net

Do not paste it here, it's critical to see what the actual physical file is, the structure and characters.

Never rely on forum pastes.

It's not technically possible for your stuff to not be updating, so there is clearly something different in your system, the code to update has NOT changed, so something in your new test config HAS changed.


Back to top

I missed your posting, let me check that.

Ok, that explains it. smxi is not a psychic script, so what you were getting was the default debian options.

You failed to create the id file /etc/antiX so smxi is treating your test install as a default Debian install. Since Debian installs are already sid, testing, or stable, smxi doesn't try to alter that stuff in any way, respecting that the debian user knows what they need.

For antiX, it runs more stuff, but for Debian, it does not change the system default type, unstable, testing, or stable.

The real place you should have looked, and in the future, please paste the FULL smxi log to paste.debian.net and it will save us a lot of debugging time, it contains all the data and information I need to debug and issue, in this case, it would have shown me the distro type and system base, which would have immediately solved the problem.

heh, time to make a developer's forum now.
Back to top

But there is an /etc/antiX file. It says.

antiX-M8-base.iso
Back to top

In the future, I will not accept any bug issues without a full smxi.log so we can avoid spending hours determining what I can discover in minutes by what data the system reported. This is especially critical for experimental systems. I do not want to assume anything, I want to know for a fact what smxi is working with internally. Please give link to paste.debian.net of your log before replying so we can discover together where the error is. Do not assume anything.

Here's how it works:

This code is copy and pasted from smxi. Please link to the log file so we can discover what data is incorrect. All this data is logged internally in smxi.log
Back to top

Here is smxi.log
paste.debian.net/17405
Back to top

The bug is now fixed, needed to set the distro data before conversion when conversion is run.

These types of errors are instantly obvious and easy to fix with the log fiiles.

smxi 8.4.8 has that fix, and the new smxi.zip has it as well.

By the way, give some thought to using the smxi-stub installer with symbolic links in /usr/sbin on the next antix release, it's a very useful method, since you never have to reinstall smxi, sgfxi, or svmi manually, it does it for you if you delete the files in /usr/local/bin
smxi.googlecode.com/svn/trunk/smxi-stub/smxi-stub

Unfortunately this particular bug has been active for a while now, which means I assume the antix conversions weren't going quite correctly. I did a lot of hacking on this stuff over summer, and I don't have time to retest everything each time on each system it works on, but over time things will get smoothed out.
Back to top

Thanks for the fix.
As far as the bug being around for a while, I don't think that mattered as most antiX users keep to the standard repos and/or add the sidux ones too in order to get a more up to date kernel.
Back to top

Yes, you're right, but it would lead to odd bug reports, such as this one, heh heh...

Now it should all work as intended.

What happened, if I remember right, was that I used to test for the file /etc/antiX explicitly, but then I decided to globally set the DISTRO flag, to handle all distros, but I forgot that flag is set in a function after the conversion function, which made antix default to the debian information. Now antix users will see antix specific information and options, as intended when they first run smxi.

It shouldn't have any real affect on people who ran the basic antix, as you noted, since that left the sources alone anyway. But it's good to have the stuff working correctly, otherwise you end up with that weird case where you tell the person they are looking at something about antix, and they tell you they aren't, and you both think the other person is nuts, but both are right. This is why it's always good to catch and fix bugs.
Back to top

Yeah, this was an odd bug report. Does that mean I'm odd or the bug? LOL

I just tried smxi-stub on a new (under-development) antiX-M8-base install in VB and all works as it should.
Options show antiX-sid, antiX-sidux etc. Thanks.
I then did the same with the very first Debian-based antiX-M7.01-base (December 2007) and chose sidux and sid repos, install new sidux kernel, dist-upgrade, apt-get and guess what, not a glitch in the upgrade!

One very minor point. The smxi script adds the debian sid sources using the uk repos. antiX by default uses the de German repos for Testing and (commented out) unstable. No big issue really, but I guess the repos should be consistent.

Thanks again

Edit: Completely off-topic, but have you found the 2.6.26 sidux kernels to be very slow booting in VB 2.02?
Previous kernels fly, as does the 2.6.26-1-486 Debian kernel.
Back to top