New option: -G

This lets you run the old post upgrade section in X, and turns off the pre upgrade kernel install section, the upgrade warnings/upgrade section, and the final graphics install section.

Only available in X, desktop mode.

This is for people's convenience so they can do the various stuff in the post du section in X without needing to go out of the desktop.

Eventually there will be full in X support, but that requires some significant testing for various updated packages to really be stable, but eventually that will come.

To use, first update smxi: smxi -U
then in your favorite terminal just run as root: smxi -G

and it will show the system information section, then the options list.

Nice feature I think, about time to move past that silly ATS stuff that really had not a lot to do with reality.
Back to top

the graphics installer question now also offers nvidia card users nouveau driver, which is often a better choice for older nvidia cards, and with latest xorg, 1.9 I guess, I've heard nouveau is actually working for many newer cards.

For 1.7 it's not working reliably at all in my tests, totally unusable in fact, which is why I resisted adding it, but I guess it's going to come along ok.

I added a message to users that they can use sgfxi -N vesa
to force vesa driver install to recover from a bad nouveau install just in case.
Back to top

Fixed an smxi tool that's been broken ever since insserv was introduced, and also fixed some bugs in that tool which were present even before this break. Sometimes it's good to revisit tools and methods and bring them up to date and make them robust.

the smxi runlevel tool is now updated to use the automated cli version of sysv-rc-conf, that is much cleaner and reliable than the method I was using before, and it's easier too! easier for me that is.

smxi will test for and install if missing sysv-rc-conf as well, prior to updating the runlevels of your dm as well.

I see no issues with this, so now there's a simple default runlevel tool working in smxi again, that should be of use long term, since it uses sysv-rc-conf via CLI options now instead of hardcoding in the changes like smxi used to do.

Since sysv-rc-conf tends to be hard to use for regular users, and very easy to make mistakes with, I tended to try to avoid using it in smxi, but I didn't realize it has CLI triggers that simply use it as a back end, that opens up some nice possibilities overall I'd say.

This tool is of especial use for Debian users, because debian insists on starting the desktop at the same runlevel as everything else, even though there are clear times when you want to be able to start the system as user without the desktop running.

Personally I use runlevel 1 as single user mode, as intended by debian, runlevel 2 is no X/desktop, and 3 is desktop. There's no reason I can see for the old redhat/sidux/mepis type runlevels of 3 and 5, 2 is a fine default for the base system, and the next one is 3, so there you go.

Just fyi, that convention has no current reasoning behind it that I have ever been able to discover, ie, 3 and 5 are just random, but since debian defaults always to 2-5 being on, it's logical to simply keep those defaults, and change the desktop start to 3, ie, kdm/gdm and so on, start at runlevel 3, not 2.
Back to top

I should mention that I fixed a long time weakness/bug that made the ceni installer not update ceni to latest version on reinstalls, that is now corrected.

In general I don't really want to update ceni too often to make sure it keeps working with squeeze/sid as squeeze goes stable, but I may expand that to support having two versions, one stable for squeeze, and one I update now and then for testing/sid.

Doesn't matter that much overall I guess, but some people may have noticed that ceni didn't get updated/reinstalled via smxi so now that's working correctly.
Back to top

smxi, sgfxi, svmi, all updated for wheezy/squeeze stable detections.

smxi partially updated to dynamically detect OOo or libreoffice installed/in apt.

Lots of changes, might be bugs, I haven't tested it all yet.
Back to top

h2

Is it the way forward for libreoffce to replace oOo? At the moment oOo will go unless uno-libs3 is put on hold - should I just let it go and allow libreoffice to replace it?

EDIT Looks like it is for sid. d-u today brought in oOo transitional packages to allow a smooth transition (32 bit)
Back to top

Ah, good, I was hoping transitional packages were coming in, if not I would have had to do a pre du fix in smxi.
Back to top

completed and debugged smxi openoffice.org/libreoffice handling, now all detections of installed/candidates are automatic, and the choices that are offered people should reflect accurately more or less what apt will do for people's systems.

This completes one big phase of the squeeze/wheezy update, and hopefully it works as expected. This should support all debian users, mepis users, lmde/antix testing /. sid base users, and anyone else, and should also support different versions of office, say libre in mepis, without any manual intervention.

Failure to do so, ie, if apt-cache policy libreoffice-core shows candidate for installation but if smxi gets it wrong that's a bug, please report it, with the output of:

apt-cache policy libreoffice-core
and
apt-cache policy openoffice.org-core

so I can debug the issue.
Back to top

hi

techadmin feel free to move/split if not a feature post please!

Just to let you know I am on a 32 bit system and techadmin's warning about xorg being removed and nouveau was well appreciated but

1) warning on aptosid about grub2 common package being wrong is ok
todays smxi pulls in all grub2 packages ok

2) I use partimage so completed smxi at own risk and as I use a non-free video driver....the nouveau was not an issue for me

b) But I appreciate the time techadmin has spent offering those X options that I could see

3) I still prefer updating the kernel and rebooting rather than having options to update certain closed source drivers and new kernels after normal package updates

b) that is because I like to see smxi report I am on the latest kernel so I know for sure....to be anal.....when I remove older kernels

sorry if this seems a negative....keep up the great work

4) And...am happy to report that dkms ? auto-build my closed source Vbox module...thru smxi updating the packages

regards

gordy
Back to top

Added the kernel remover option to the advanced kernel options to make it a bit more intuitive for some users. By request.
Back to top