I noticed that there is now an option to install the latest Mepis kernel, but it doesn't work. Is it because it hasn't been incorporated into the script yet?

Another question.

Can the clean up section of the script be run in X?
Back to top

there's an option to install the latest mepis kernel?

I did build into the core logic basic support for theoretical mepis kernels, but as far as I know, it's not actually implemented on the user level, though in theory it's just a matter of adding mepis to the list of supported kernels and tweaking a few things, but this kernel stuff takes so much testing and debugging that I can't really add such an option safely I think. Though the logic is there ready to be used in the future.

Running any part of smxi except the -v, -W, -h stuff is just too tricky, basically, it's all wrapped in the x killer. What happens is that once you are in smxi, it's not safe to do most of the features in x for normal users, so it's best to just leave it all x-less.

The -v, -W, and -h stuff actually trigger standalone functions that run then exit immediately, leaving you no way to proceed.

I suppose I could add such a function for the cleanup stuff though now that you mention it, but these things all require lots of tools etc from smxi itself to run, it's not just starting a function and that's it, things have to be loaded, logs checked and started, and so on. It's far easier to just start things from inside smxi, knowing everything you needed was loaded and run.
Back to top

Thanks for the reply h2.

1. About Mepis kernel, I noticed it today as an option in the add new kernel section, in a list with the sidux ones (option 17 I think it was).
There is a Mepis 2.6.26-1-mepis-smp kernel in the Mepis 8 repos.

2. Clean up in X. Some one posted this idea on the antiX forums and sought your knowledge on this. So in theory it can be done in X, but it is a lot of work to implement it in smxi, so better to do it as is.
Back to top

oh, so the mepis stuff is working? amazing, I did a better job than i thought, now I remember, I did add the mepis detection and handling in the advanced kernel install options, but I didn't expect them to get used.

Let me know if they work, although I'm not sure about what the mepis kernel installer package will try to do to the system, that might be something good for you to know too.

Basically, for smxi, I try to make a formula, since it's already complicated enough internally as it is: how much work or headache does the idea really save the end user?

In this case, let's say you boot, then ctrl alt f1 at login screen, to start smxi.

Then: smxi -kwid
to skip the steps and get to the cleanup options.

Once done, start x again via smxi.

There's always been a tendency among smxi users to try to avoid going to the console at any cost, but once they try it, suddenly they realize that a: they really should be running ubuntu after all, or b: hey! that was easy!

In theory I could run only cleanup, but to do so, why? it's just too easy to do this, and how often do you need to really clean up anyway?

By the way, if the system has a standard crontab thing set up, it defaults to this absurdly early time in the day, so most cron jobs do not get run, but if you install anacron, the log files etc for syslog should get handled fine. smxi now installs anacron by default with its utilities stuff.
Back to top

Installing the new Mepis kernel doesn't work. smxi gives the option to install, but it fails to do so.

Here is the repo for it (if you haven't already got it)
deb ftp://ftp.mepis.com/mepis/ mepis-8.0 main

linux-image-2.6.26-1-mepis-smp_2.6.26-2mepis1_i386.deb
linux-image-2.6.26-1-mepis64-smp_2.6.26-2mepis1_i386.deb
linux-headers-2.6.26-1-mepis-smp_2.6.26-2mepis1_i386.deb
linux-headers-2.6.26-1-mepis64-smp_2.6.26-2mepis1_amd64.deb
Back to top

probably I didn't finish the installer logic internally, I'll check the rest of it for mepis and maybe have it working tomorrow, then you can test it again if you want. I think I just have to set a few switches etc, then upload the installer libs.
Back to top

There were a few missing switches internally as I suspected for mepis, try it again, it should now either get further in the process, or it should work fine.

There might be a few little places where naming conventions need to be tweaked, but please post a link to your /var/log/smxi.log in all cases, so I can make sure the mepis data is flowing correctly, thanks.

Based on your package names, I also added 64 bit support to the mepis, since that's fairly trivial, assuming mepis follows debian style module naming conventions, it should work fine, if not, I'll know from the log where it fails.

Oh, by the way, if mepis doesn't have a metapackage for its kernels, then I can't make the tests work, period.

If it turns out there wasn't one, I'll remove the kernel install option for mepis.

Metapackage name for mepis would have to be like so: linux-image-2.6-mepis-smp

If there isn't one, I can't do anything to support mepis. If it has a different syntax, I need to see it.
Back to top

There is no metapackage for the kernel (at least at the moment).
I tried to upgrade the kernel via smxi and it gives an error about not finding linux-image-2.6-mepis-smp.

Never mind. Hopefully Mepis will have a metapackage for its kernel, if not, is there a way to install the new Mepis kernels via a tarball like the old sidux kernels?
I'm thinking out loud here, and I guess the site where antiX is hosted could host the new Mepis kernel(s) tarred up with the necessary modules.

Another question, but nothing to do with smxi (if you don't mind)
Where can I get some info for metapackages? Long-term, I'm thinking of maybe including some for antiX.

Thanks
Back to top

A metapackage is simply a debian package with basically null content, the only thing it contains is dependency information, so when the metapackage gets upgraded, its dependencies get upgraded.

so it's like any other debian package, except it's actually not a container for any real packages, it just lists other packages as dependencies.

A mepis zip file could I guess be done, but there aren't very many users of antix so far, not sure if it's actually worth it. Also, you'd need 32 and 64 bit zip files, with all modules etc, and with source available.

If a mepis metapackage file could be made, then smxi will just work, natively, using the mepis metapackage if mepis sources are present. That's by far the best option from my perspective re smxi, dynamic updating of data is always to be preferred, otherwise things quickly go out of date or fail because packages change.

However, to see the script I use to construct the zips, go to svn and check out or download dsl

You also want to make sure to download the source for the package, even if you don't include it in the zip, it needs to be available.
Back to top