Yes, you can, but you'll have to edit fstab too.
You can edit the /boot/grub/menu.lst as h2 suggests to include the kopt line (use your UUID)

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
## kopt_2_6_8=root=/dev/hdc1 ro
## kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=UUID=e16357e4-6122-46df-9098-d68055385d08 ro vga=791 nosplash

Ok, I switched everything over uuid and the system booted up no problem. However, the fstab gets updated on boot and puts the partitions under the dynamic entry line.

h2 wrote:masinick, the grub stuff is the result of mepis using a non debian standard grub updating method, that's out of my hands, long term hopefully mepis will abandon that idea and use update-grub compatible syntax.

I'm not going to try to work around what is essentially in my opinion an error, and not debian compatible, that's far too much work, so that's something mepis/antix users will have to resolve, probably by setting up a simple how to update /boot/grub/menu.lst page, the edits aren't that hard, and should be done after the first new kernel install.

Once you sync the stuff, it all works fine, and all future kernel updates will work as expected for sidux and debian kernels.

In general, if systems are going to use debian as their source, it's a fairly good idea to not drift very far from core debian methods, it's just harder to maintain longterm.

I understand, and I appreciate your viewpoint on this point. Hopefully SimplyMEPIS will adopt the standard Debian practice. I suspect that the code that was written was done so before any standard techniques were in place and it worked for a simple setup, so it never got changed. Hopefully that will change with the next release. Trickles of information suggest there will be a Version 8 sometime this year.

I'm like you, though, I am not inclined to put much into it. I keep SimplyMEPIS out there mostly to have a nice, simple, stable system to fall back on when I torch one of my other favorite systems, which I am known to do every 1-2 years. Now having four pieces of hardware and dozens of distros, I am less worried about what I may do to any one of them, though ideally I like them all to work.

After fooling around with it a bit, I am most likely to just install the new version of SimplyMEPIS when the next one comes out and use antiX and sidux for most of my day to day stuff anyway.

Thanks for the explanation!

Alright, for testing purposes I used smxi -T and installed the 2.6.25-2-686 Debian kernel. Install was smooth and the machine rebooted into it without issue. I have noticed that some modules are not available for some kernels, but, nothing I needed though.

I have installed both Debian and sidux kernels, and kept an old MEPIS 2.6.22-1-mepis-smp kernel around,"Just in case". All of them work. The older Debian kernels require using either the old hda device naming conventions or the use of UUID strings to identify mount points. All of the kernels work fine, with that one difference in usage.

I've upgraded using smxi a number of times with both SimplyMEPIS and antiX, as well as the sidux instances I use, and all of them work fine. SimplyMEPIS, given differing conventions, is the roughest with smxi, but I still find it useful and usable. AntiX has become nearly as good as sidux in its use of smxi, and I found my"autograph" in the contributer's section - thanks, h2!

smxi is looking real solid and I think it will be ready for the next release. Only remaining questions are the various upgrade scenarios. Anti, what scenarios do you still need tested? If I can squeeze in some time, I can always install some old CDs of AntiX and upgrade. I think it is a 7.0 image that I have already been upgrading on my old Dell for some time, and that works great, as does my 7.2 image on my much newer Lenovo. If you are lacking test scenarios I may be able to help out. Do let me know and I will confirm whether or not I can run the scenarios you need.

eriefisher, some modules get merged into kernel, others vanish, and so on, so I just keep a fairly long list for all systems and test if they are available, so the missing module thing has no real meaning except to let you know it's not available.

I've done a load of tweaks and improvements all through smxi to smooth things out even more for all platforms, and I'll have to let this stuff settle down a bit pretty soon.

Just cleaned up package groups in package install, and updated especially all the utility groups, so they are more complete now, installing good utilities etc that you might not know about but which are almost always useful.

Nice new tweak in system information in first part of smxi: shows your / (and /home if mounted elsewhere) partition size, percent used, free, and file system type. This helps solve a long term problem where people accidentally run their partitions to 100% full,which makes desktops etc unable to start.

Also finished up full logging, that's now a quite effective debugging tool, and I can easily add more data to be logged any time I hear a bug report that we can't easily figure out. (/var/log/smxi.log, /var/log/sgfxi/sgfxi.log)

One request, not necessarily just for antiX.
Could you make more debian kernels available?
486 as well as 686. It may help those using older boxes.

486 are available, but you need to start with a 486 kernel, the debian kernel detection automatically tests for bigmem, xen, 686, amd64, 486.

smxi handles that automatically at the moment, if you start with a debian 486, it will continue with a debian 486, for modules and everything else.

For now that's enough I think, offering fine tuned debian kernel options is more work than I think it's currently worth doing, though in the future it might be a choice.

It wouldn't be super hard to integrate it, but the hard part is in correctly offering that only where applicable, that kind of detection isn't that easy. The debian installer, by the way, does a really good job of it, offering a range that works on your kernel, but nothing that doesn't.

Keep in mind, the system must have booted to run smxi, so whatever kernel the person is using by definition works, that's why smxi uses their default.

Default for sidux is always: 686/amd64.

For antix, there's no way to know which if they start with a mepis kernel, so currently default is 686 for mepis too.

To change it, just: apt-get install linux-image-2.6.25-2-486, for example, for testing/sid at the moment, then smxi will always offer 486 debian kernels.

I suppose I can offer debian 486 as a fourth option if it's not 64 bit without a lot of work... hmmm

The latest modularization and abstraction stuff made this trivial to add, so I did.

Now, for any system that supports debian kernels, or for antix with smxi -T start, smxi will show both 686 and 486 (for 32 bit systems) as debian kernel install options.

And it will default to the currently installed debian type for standard use, ie, if you have 486 installed, it will offer the next 486 in the default kernel install section.

This, by the way, is why structured and modularized code is always better, it's more flexible and powerful, and requests like this help remind me of that fact.

That's going to be redundant in some cases, because the default kernel will be set by the currently run use kernel.

hmmm.... that's the problem with trying to to do too much fine tuning, it ends of getting more and more complex, but for now I'll just leave the 486 as an extra option, and the default will just be whatever the user is currently running. Otherwise I'd have to add all this super specific stuff.

Great work, h2! We sure appreciate all of the extras you are including to make smxi even more useful to a broader audience, namely we people who like both sidux and antiX!

now it offers you the opposite of what you're using, but only in the case of kernels ending with 686/486

I believe for antix and 686 users, this means that they will always see the 486 when using default mepis -smp marked kernels, which is what you want. And 486 users will see 686 option, with a warning about trying to install 686 on non 686 compatible cpus (older than pentium 3)

I'm not going to get more specific than this though.

The default debian kernel install option will install whatever you are currently using.

This will allow these older boxes to at least run modern kernels. This is great stuff.

Thanks h2.

masinick, without getting into specific numbers, smxi pretty much hit a plateau of users over the last year, which is one reason I decided to make it available to a broader base. Well, plus I wanted to use it for my own installs of Debian too.

I have a rule with learning most linux stuff, if I want to do something, I have to wait until I script it into smxi, sgfxi, or svmi until I can do it. While this can be a pain sometimes, it's one of the things I use to motivate myself.

h2 wrote:masinick, without getting into specific numbers, smxi pretty much hit a plateau of users over the last year, which is one reason I decided to make it available to a broader base. Well, plus I wanted to use it for my own installs of Debian too.

I have a rule with learning most linux stuff, if I want to do something, I have to wait until I script it into smxi, sgfxi, or svmi until I can do it. While this can be a pain sometimes, it's one of the things I use to motivate myself.

Did you say that at one point you taught yourself Bash and used smxi as a learning point? I just took a quick look at the script, and I found it to be very well documented, it uses good variables and generally seems reasonably conceived. Of course, doing stuff in Bash quickly grows, and it has become a large script - but a good one and a very useful one.

Kind of reminds me, in a round about way, about exmh, a TCL/Tk script written to be a more powerful replacement for the old xmh mail handling program. Xmh itself was just one of a few sample programs designed to show people how they could code applications in X. It is a powerful program but not really all that flashy (but it is fast). Exmh, on the other hand, was a exercise in TCL and the TCL Toolkit, Tk. It started out as a set of functions that performed many of the same things that the command line MH mail tools would do, and basically do them like xmh. But Tk is much more extensible than plain old Xlib, so before you know it, colors and all kinds of other extensions were written.

Your script shows the same kind of growth. I suppose there comes a time (at least in some people's minds) where an application grows too much. I do not think that smxi is in that spot at all. Instead, I think it fills a niche that only one or two efforts have even attempted to address in the past, and to me, it is the only tool that does a good job with Debian based systems. (I used to like what Libranet did with their tools way back when).

Anyway, keep at it; your work is greatly valued! Like you said, though, this may be around the time to step back and assess the overall architecture to make sure it does reasonable things - and should there be any future turns or bends in the road, it will be able to adapt appropriately.

I think that you have a far better handle on that than I do, and I applaud everything that you are doing!

masinick, actually, the time to reassess the architecture already came, twice in fact, once during the initial sidux launch, and once about 6-8 months ago.

I've actually been going over most of it this past month as I further improved and abstracted everything away from specifics to general, so now it's getting pretty flexible and easy to work with again. Except for the graphics lib, sm-lib-graphics, that is just basically always fighting with the non free logic to maintain some type of functionality amid various changes and failures in non free drivers.

Your view is interesting on this though, for a while I worried about smxi getting too big, but the more I modularize and abstract, the less that worries me, most core functions are all controlled from a single place now, so it's really just repeating function calls, less and less hardcoding going on.

One thing I found especially interesting, if you look at the code on
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://code.google.com/p/smxi"
linktext was:"http://code.google.com/p/smxi"
====================================
you'll see that the dev tools, for example, and kernel tools, which are dev scripts I modified for public release from simple linear scripts with no structure, anyway, as I structured each in turn, I realized that each one gained power and flexibility, even when they were really short.

So I'm increasingly starting to believe that there is almost no case where writing unstructured code is a good idea, no matter how simply you think the tool will be. I'm always amazed to see that major bash etc scripts out there, like the fglrx / nvidia installers, still do not follow such good practices.