Im not sure if this problem is ditribution specific as I have seen similar problems on other distributions but here gos.
I installed rehat 9.0 and it worked great. When I tried to recompile my kernel and boot off it I get the error.

FAT: bogus logical sector size 5376
FAT: bogus logical sector size 5376
modprobe -s -k nls_iso8859-1 failed; error2
Kernel panic: VFS: Unable to mount root fs on 03:00

I have a 10 gig HardDrive with 5 gigs for Win2000 and the other half for redhat. I also have a 500mb secondary drive that is FAT32. My original kernel is still fine and I can boot off it.

Does anyone have any ideas?

You forgot to configure some items in the kernel config. Code pages are required for FAT32 file-system support. In addition to that, you probably forgot other kernel drivers as well, probably even ext2/ext3 support. 03:00 is /dev/hda

Hey thanks, I recompiled again and managed to remove the modprobe -s -k nls_iso8859-1 failed; error2 by compiling in support for that module. Doh! always the easiest solution. Still cant get rid of the bogus logical sector size errors. I made sure I had support for ext3 and any other file systems (apart from umsdos and reiserfs) included when I rebuilt, but still no luck. Are there any other specific modules I need support for? maybe not in the fs menu?

The error is printed by the FAT file-system kernel driver upon reading a FAT superblock and finding invalid parameters. Your kernel should not access any FAT partition when booting.

You might want to start with Red Hat's kernel config from /usr/src/linux-2.4/configs and modify that one.

Argh. Im still have the same problem. Ive tried recompiling the kernel soo many times with different module support and I still get the same error message when I try to boot off the new kernel:
FAT: bogus logical sector size 5376
FAT: bogus logical sector size 5376
Kernel panic: VFS: Unable to mount root fs on 03:00
I looked in the config directories, even used make oldconfig and deleting my config that was stored in there to create a new one, but still no luck.
Is there an option in the configs that can stop a booting kernel from trying to access a FAT partition?

As a starting point, you should be able to rebuild Red Hat's kernel with Red Hat's config file. Sort of the following:

cd /usr/src/linux-2.4
make mrproper
cp configs/kernel-2.4.20-i686.config .config
make oldconfig
make dep bzImage modules modules_install install

Then don't forget to create an initial RAM-disk for that kernel:

cd /boot
mkinitrd initrd-2.4.20-9custom.img 2.4.20-9custom

I was using my old kernels RAM-disk that was resident in /boot to boot with. Is this bad?
After building a new kernel should I always create a RAM-disk or should there be a RAM-disk created for me in the linux source build directory tree?

Yes, that is bad because an initrd contains kernel modules which depend on a specific kernel. Whether or not you need an initrd at all depends on things such as whether you have ext3 fs support build into the kernel as a module or not and whether your root fs is on LVM.
You must create it manually.

Thanks for the help. I rebuilt my kernel from the configs/kernel-2.4.20-i686.config file. Is this the default kernel that is created and used after a successful redhat install?
I then created a new RAM-disk for it and set GRUB to use this RAM-disk instead of the old kernels, but it still fails on the same error during boot.
I had a look at the config file using xconfig before i compiled it, I saved the config when in xconfig and now I think that I should just have rebuilt without saving in xconfig.
Could this be the reason why it failed during boot again?

"make xconfig" is known to cause an error with regard to zlib, but it shouldn't damage anything else. Try "make oldconfig" instead. Or "make menuconfig".

And yes, that is the kernel config file for Red Hat's kernel. If the precompiled kernel from the kernel package works, your own compiled kernel based on the same config file should work, too.

Finally success! I must have missed something in the last kernel recompile because after trying again using the kernel in /configs I could finally boot off of it. Thanks for all your help misc. Thats what I call dedication to a problem.