smxi FAQs :: Answers to common questions about smxi

The following are specific questions about only smxi, and problems or issues you might have question about, or solutions/tricks/tips that might be of use to you.

Smxi specific questions and technical solutions:

For more general questions, that apply to all the scripts, script descriptions, and other general information, see the FAQs section. If you need to ask a question that isn't answered here, please use the script forums.

Newly installed kernel doesn't show in Grub?

The problem: you have installed a new kernel with smxi, or you believe you have, but when you reboot, there is no sign of the kernel in your grub boot menu of kernels or operating systems.

This issue is something I just learned the cause of. Well, it has two possible causes, so let's go down the list one by one, from easiest to hardest to fix.

  1. One possible reason is that your download of the kernel image file was interrupted, and the kernel install process didn't complete. This could happen because the package you were downloading was replaced by another one, or because your download was otherwise interupted.

    Whatever the case, this is easy to confirm or fix, just run smxi again, and try to install the kernel again, you can just redo it without any issue. If that fixes the problem, fine, you're done.

  2. If, on the other hand, you're still not seeing the new kernel in grub, you may have done the following (which I just discovered helping someone with this very issue on IRC):

    You are Multi Booting, or dual booting (ie, you have more than one operating system on your computer), and when you set this up, you did it wrong, and have installed BOTH operating system grubs to your Master Boot Record (mbr). This doesn't work, only one of them is actually active. In other words, if you install a new kernel on the system that is not in the mbr, you will see no change in the boot options in /boot/grub/menu.lst.

    Fixing this isn't as hard, since you have to actually fix your setup, by making one operating system the official, default, master one, that has its grub written to boot. When this one updates its kernels, you will see that new kernel there.

    The second, non master operating system will require that you reinstall its grub to its partition boot sector, root, that is. Once you do this, you have to add a chainloader to the master grub's /boot/grub/menu.lst file, which will point to the second (each extra OS on your system will have one such chainloader in the primary, master, grub) operating systems partition boot sector, which will have its own grub, which is what will show the new kernels you add. The chainloader sends the system to the seconardy grub, installed on the partition boot sector.

    Sample menu.lst entry for second OS

    		rootnoverify (hd0,0)
    		chainloader +1

    This sample would work after you install Grub for the next Os to the partition root, and tells grub to locate the second instance of grub, for that OS. hd0,0 means disk 1, partition 1.

    When you use grub-install with just hd0, without the ,0, that would mean install grub to the disk one master boot record, not the partition root.

    Grub Syntax Tutorial (Ignore the top parts about installing grub, you already have it, and ignore the stuff about using dd if=..., you're just concerned with the syntax to use for your /boot/grub/menu.lst file).

    Note that you will have to fix your grub manually if you made this mistake by using grub-install to move the second grub to the partition boot sector, not the master boot record.

Error: 34 - Missing Warning Section file:

If you see this don't worry, it's not a big deal.

Error: 34 Missing Warning Section file: status
smxi cannot execute the requested action without this file.

Error 34 means smxi failed to get a small file it needs to test the status of the dist-upgrades/upgrade.

That means one of two things, the smxi server had a temporary failure (VERY UNLIKELY), or that your connection got too slowed down, or failed in some other way unknown to us. Common failure points are your router, your ISP, etc. For some reason especially small files seem to trigger this issue more than larger files.

The solution is to retry smxi. The message is not an error, it's a statement of fact, smxi could not download a file it needs in order to proceed, and the failure to download is almost always the result of some local ISP or router issues, and very very very rarely might be caused by a momentary failure in the smxi servers.

The colors are too hard to read in my console!

You have two ways to set the script colors, -j [color option number] or setting it in /usr/local/bin/smxi-values (see sticky options for more information on this method.

Current -j color options are as follows: 1 is somewhat neutral, ok for dark and light consoles, but better for light on dark; 2 is light on dark, 3 works as either dark/light or light/dark, and 4 is dark on light:

# turn off all script colors completely, revert to defaults for console
smxi -j 1
# default, standard colors
smxi -j 1
# gray/ pale colors
smxi -j 2
# earthy, green/brown
smxi -j 3
# darker, good for light backgrounds
smxi -j 4

You can also set these permanently by creating the file /usr/local/bin/smxi-values then adding this to it (to for example make the script default to dark on light colors):


And that's it! Colors set to your liking.

Other modules started from smxi will also inherit your color choice, by the way, like sgfxi and svmi.

Can I run smxi in X/gui terminal?

Yes, but only with the smxi -G option, which turns off the initial kernel install question, the upgrade section, the warnings section, and the final graphics installer section.

Since the post upgrade section contains lots of useful things, none of which really depend on being out of your desktop or X, that's been opened up to run in X, so you can run things like Package Install, Cleanup, Kernel Install, Miscellaneous Tweaks, and so on without leaving your desktop.