I have some pretty good experience with building custom kernels and the like and I haven't had any problems in the past with doing so but I am really about to go crazy on this one. I'm trying to get 2.6.16.19 working and I cannot for the life of me figure out why I am getting "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,2)" whenever I try to boot with it. I know that my grub file is correct:

root (hd0,1)
kernel /boot/bzImage-2.6.16.19 root=/dev/hda2 ro
initrd /boot/initrd.img-2.6.16.19
savedefault
boot

I know for a fact that /dev/hda2 is where the root of the drive is because the kernel I am using now (2.6.8.2) sees it. Initially I had just built file system support for only reiserfs, which is what I use as I don't have a need for JFS, XFS, ext, ext2, ext3, or minix. This gave me "Kernel panic - not syncing: VFS: Unable to mount root fs on unkwnon-block(0,0)" so I decided to go back and include all file system support. As a result, I now get what I posted above. I have all the file systems built into the kernel and I'm pretty sure I made the initrd file right (mkinitrd -o initrd.img-2.6.16.19 2.6.16.19). Anyone know what the deal is? Could this problem extend to another section of the kernel configuration?

Check that your disk drive is supported in Device Drivers > ATA/ATAPI/MFM/RLL support. If nothing else, you may need the generic IDE chipset support.

^ Sadly, that was the second thing I checked for. I have all ATAPI/IDE stuff built in because I had the same problem in the past and this fixed it. Guess this is a different issue

Hm. The only other thing I can think of (and I'm not sure this is required) is RAM disk support and Initial RAM filesystem support. Both are in Device Drivers > Block Devices. On my kernel, I've just used the defaults for RAM disk support and both that and the Initial RAM Filesystem are built into the kernel.

/me sighs

Yes, I made sure those were both built in as well. In fact, right before I get the kernel panic it will say that the RAM disk has been mounted. I'm thinking I'm just going to wipe the configuration data and start over from scratch. Thanks for your help though.

Oh, if it's of any interest or help I have uploaded my kernel configuration data. See below.

Config-2.6.16.19

I'm going to admit to being stumped. Nothing glaringly obvious is jumping out from your config file. About the only suggestion I've got is to run a make clean, and then start with the config from your 2.6.8.2 kernel.

Alright, that's what I'll do. Thanks

HA! Got it. I was on a rampage and dug around in the miscellaneous file systems section and found CRAMFS hiding away. Built it in, and that was exactly the problem. Everything works like a charm now...minus the 4 or 5 FATAL errors I saw during start up :| I suppose I'll be working on that tonight.

This seemed odd to me. So, I did a Google search and found the following information on Wikipedia:

So that's one to watch out for on recent Debian releases.

One question: With a custom kernel, are there any advantages to running an initrd? I can understand why packagers would use this functionality, but can the home hobbyist with a fully customised kernel benefit from an initrd in any way?

Just wanted to drop a "thanks" to all of you as this thread. It helped me fix my own 2.6.16.19 compile woes. Although I don't use initrd, I had forgotten to include my IDE controller (it was a module) and so I got the dreaded kernel panic. Now everything works great and so does my laptop's battery monitor!

"That's what we're all here for."

And the reason that "we're all here" is that .. we've all "been there, done that."

"We're not incredibly-smart... we've just made the same mistakes slightly earlier than you did."

CRAMFS is needed by the initial-ramdisk support. If you're using that, the initrd image will be ... a CRAMFS.

OK, now I've managed to become the seriously confused one. I've never included cramfs in any of my custom kernels, and I've never had this problem. I do include RAM disk support and initial RAM filesystem support. Are these different from initrd? Or, as suggested by rkelsen, is this a Debian-specific issue?

I get the impression that recent Debian kernel packages include an initrd with all of the "essential, but not built in" kernel modules. It is possible to build your own initrd, but I don't understand why anyone would want to do this with a custom kernel. Packagers obviously need to provide the widest support in the smallest package, so I can see why they'd need to do it.

Suse and Fedora are two other distros which use an initrd by default. Although I'd hazard a guess that not many Suse and Fedora users ever compile a custom kernel (or anything else for that matter)...

In the normal run of things, I don't think anyone would need an initrd. If you need to support alot of different setups, such as in distros, then you would, but not for a custom kernel. My kernel even with most everything built in is still small:

1241688 /boot/bzImage-2.6.16.18-nfmod

That's with all pci cards other than the ethernet card, cd, floppy, sound, framebuffer, filesystems (root and msdos/w32), and netfilter (base only). The only major thing I load later is USB support w/printer and ethernet card support.