very odd, especially that the older kernels have trouble too. that points to a potential problem in the initial ramfs, and maybe the tools that run there.

it's interesting that when yer dropped into the recovery shell, /dev/hda6 is already present, though. have you tried adding a rootdelay= parameter to your kernel? It could be that something in the initramfs is not populating the temporary /dev tree quickly enough for the kernel to be able to find it and mount it, and rootdelay might help with that. I'm basing this on the fact that the initial failure was "no such device" and that after you were dropped into the recovery shell in the initramfs, there was in fact such a device present.

for a stock debian initial ramfs, you might also want to try inserting a "break=" parameter to poke around during the initial boot step.

btw, while it's technicaly accurate to say "ash doesn't have fsck", ash is a shell, and no shell has fsck capabilities, afaik. So i don't think that's really what you meant. If you run ash from a full-fledged GNU/Linux environment, you will in fact have access to fsck. You were running ash from within the stripped down initial ramfs, and the ramfs itself doesn't contain fsck. Sorry for the nitpick, but I think it's worthwhile to tease apart the specific things that are happening during a modern Linux boot process so that we all can make sense of it better.

--dkg

I upgraded yesterday and pulled in linux-image-2.6.21-2-686 (version 2.6.21-6). I don't remember the other packages (about half a dozen that came in with it, none of them looked relevant to the problem), but the problem disappeared after rebooting.

I haven't tried with the older kernels yet, but will now.

Thanks for the cmdline tips and also for the ash clarification!

--jamie