Yes, I am using a custom kernel right now. Earlier I commented out the custom kernel thoughtlessly, expecting the generic kernel to work, so I had to use a livedisk to uncomment the custom kernel via some tricky chroot of my /dev/sda2 into the livedisk environment, which I found interesting.

I am not sure what is going on, since when I run 'lilo -v' it gives me verbose information and updates my lilo to MBR without any errors or warnings.

I am thinking to keep the custom kernel and forget this issue.

If your custom kernel works and the generic kernel doesn't, there must be something missing/wrong with your initrd.gz for the generic kernel.

I only used the commands to automatically create the initrd.gz. So it is only what the system told me.

Though it can be maybe that the custom kernel I made has created an initrd.gz incompatible with the 3.2.29 generic kernel?

try booting the huge kernel rerun the scripts to create an initrd.gz for the generic kernel and see if that helps. The only possible problem with this is if you are using an initrd.gz to boot your custom kernel.

My new redhat 9 installation is not booting, it says: <0>kernel panic: Attempted to kill init!
I've tried different machines but will get the same error. How should i correct this

@ stfwala you need to start a new thread with your question to prevent confusion. This is a Slackware problem and not any way related to a redhat problem.

No, I would not use an initrd.gz to start the custom kernel, as I already have an entry for it in the lilo.conf. I'll try this with huge.

Yes, the solution was that. The creation of a custom kernel unrelated to the huge kernel that comes with the generic results in a bad initrd.gz.

I switched to the huge kernel, then ran the command:

/usr/share/mkinitrd/mkinitrd_command_generator.sh

This produced the right initrd.gz. So I learned from this, the initrd.gz for a generic can only be produced with the right huge kernel related to it, and not with a custom kernel.