Sometimes your boot/grub/menu.lst will show that the partition is seen as sd other times hd.
This might cause problems if you wish to install a sidux kernel as the upgrade-grub feature (in a terminal or via the smxi script) fails to put the new kernel entry into the menu.lst.

The simple solution to this is to check that the /boot/grub/device.map shows the correct information:
ie (hd0) /dev/sda or (hd0) /dev/hda
depending on how grub labels you partition.

You should then be able to run
#update-grub
and see a much longer grub menu with any new kernels added at the bottom.

To clean up this menu, make the following changes.

1. Remove all the first 2 entries that refer to the newest kernel and previous kernel.
2. In this section ### BEGIN AUTOMAGIC KERNELS LIST make the following changes

# kopt=root=UUID=47c2cebc-2aa0-4v92-9006-d4cd3c4a6e8b ro nomce quiet nosplash vga=791
(your UUID will be different)

## should update-grub create alternative automagic boot options
## e.g. alternative=true
## alternative=false
# alternative=false

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
## altoptions=(single-user) single
# altoptions=

## should update-grub create memtest86 boot option
## e.g. memtest86=true
## memtest86=false
# memtest86=false

3. In /boot/grub remove the vmlinuz, vmlinuz.old, initrd.img.old, initrd.img sym links
4. #update-grub in a terminal should show a cleaned up list of available kernels.

You should now be able to install any kernel and have it automatically added to the /boot/grub/menu.lst

Thanks! Those are a handy set of tips, ones that perhaps the veterans could figure out, but are, nevertheless, very handy! The beginners would have no way of figuring that out, so this is a most useful tip indeed!

Just to add to anti's tip. If you have any special arguments to pass to the kernel at boot such as acpi=force etc, add them to the end of the kopt line. The boot codes or argument/helpers will be automatically added to the new any new kernel you install. This just prevents you from having to edit the /boot/grub/menu.lst with every new kernel. Hey, why do more than you have to. The smxi script will automatically do"update-grub" but if you use any other method you will need to do it yourself.

In my experience, when you run update-grub on the vast majority of systems, it will scan /boot on the current system and update the grub menu with the current list of kernels that can be found in /boot on the partition that you are using. Is there, however, a clean and easily maintainable way of having update-grub look at ALL partitions containing a /boot directory, and examine each of them, then add a copy of each kernel, so that your grub menu contains all the available kernels on all systems?

It appears that a few distributions have a technique to do this when they initially install their software, but very few, if any, of them implement a version of update-grub that consistently scans all partitions for instances of a /boot/vmlinuz* in all partitions?

Is there a clean way to do this, or does it require hackery of some sort? Seems to me that if this functionality is available at install time, it ought to be available in general. If I were clever enough and had the time to do it, I suppose that I could write a script to do what I want to do, but it seems that such a tool ought to be out there already. Does anyone know of such a tool, and if so, where to get it and how to use it?

Thanks!

I tested this, and I'd like to update a few points:

You want to set: # alternative=false

This makes the system not create doubled sets of menu.list entries when you run update-grub

There is no need to remove the vmlinuz, vmlinuz.old, initrd.img.old, initrd.img sym links, at least not that I can see.

Also on the top, remove the memtest item that appears above the automagic stuff, with the original Mepis items.

I can add a test in smxi to allow Debian kernel installs if UUID= or LABEL= is used for root= in kopt= section of menu.lst, this would be fairly safe then, at least reasonably.

You might also want to add: default 0
to the top data, timeout, gfxmenu section, that lets you tell grub which OS to use by default.

So I'll modify the smxi test for antix to check for a corrected kopt=, with root=UUID= or root=LABEL=, if that's present, Debian kernel install will be activated, and I'll assume that the person has corrected their menu.lst manually and it's safe to proceed with debian kernel install.

Sorry, let me update, on testing, you do need to delete the files: /boot/grub/vmlinuz.old initrd.img.old
but nothing else in there that I can see needs to be deleted.