Linux boot problem

[Chaotic42]

Hey.

I've recently installed Debian on my laptop, and when I try to use the kernel that I compiled (or the default kernel for that matter), Linux kernel panics with the following output:

VFS: Cannot open root device
Please append a correct "root=" boot option
VFS: Unable to mount root device

Now, of course, I've appended a "root=" option, and done everything that I know to make it work. I can boot off of the rescue CD, but not from the hard drive. It doesn't matter if I use LILO or Grub.

Any ideas? Google doesn't turn up a whole bunch of useful info.

 

[djdrastic]

Have you ?


1)Been Compiling Your Own Kernels ?
2)Have you fscked the filesystems with your rescue cd
3)Been playing with fdisk / cfdisk ?


If you could , maybe displaying yout fdisk / cfdisk screenshot might be helpful

 

[stars]

Do you by chance have an incorrect entry in grub/lilo? or using a kernel with no ext3/ext2/ FS support?
I'm sure you have checked these, just trying to give you some ideals.

 

[TGS]

just copy your grub.conf here.

 

[Chaotic42]

Originally posted by: djdrastic
Have you ?


1)Been Compiling Your Own Kernels ?

Yep, for a little more than 9 years.

2)Have you fscked the filesystems with your rescue cd

, no the FS is completely intact.

3)Been playing with fdisk / cfdisk ?

Not other than during the initial install

If you could , maybe displaying yout fdisk / cfdisk screenshot might be helpful

I'll post it when I get home.

Thanks for the replies, everyone. I've been using Linux for quite a while and I've never come across this problem before.

 

[Nothinman]

By default Debian kernels require an initrd, did you make sure everything necessary to get to the root was static if you're not using one?

 

[drag]

ya. Debian generally uses initrds. In order not to have to use one you have to make sure that your compiling in all your drivers you need to access the filing system instead of just having everything modules. Hell, Debian even compiles ext3 in as a module.

Just make sure that grub has a initrd entry for the default kernel's initrd.

If you need to make one yourself you can use the script that is used in the automated way to create kernels. The mkinitrd script...

You have to go like this:
mkinitrd -o /boot/initrd-linux-version linux-verion

Then it should work, also you have to supply absolute paths for the -o part of the script. If you don't give it a kernel version then it will make one for the kernel your using.

Generally though, unless you have special needs, Debian's default kernels are nice and up to date security wise. For Debian stable I think they are have 2.6.8 aviable and for unstable they have 2.6.11 aviable.

apt-get works from chroot, so you could use that to install a kernel if you can't figure out what happenned to make the default one stop working.

 

[Chaotic42]

Thanks for the replies.

Yes, I have "initrd=" in menu.lst. It still says panic on (0,0), which is odd because menu.lst points it to (0,1).

Here's my menu.lst:

-
timeout 15
default 1
fallback 0

title Windows 2000
rootnoverify (hd0,0)
makeactive
chainloader +1
boot

title Debian 2.2.10
root (hd0,1)
kernel /boot/vmlinuz root=/dev/hda2
boot

title Debian 2.6.12
root (hd0,1)
kernel /boot/linux-2.6.12 root=/dev/hda2 noscsi
initrd=/boot/initrd-linux-2.6.12
boot
-

All of the files and devices are correct, and ext2 support is built in to the kernel.

 

[drag]

initrd=/boot/initrd-linux-2.6.12

should be
initrd /boot/initrd-linux-2.6.12

 

[Nothinman]

Yes, I have "initrd=" in menu.lst. It still says panic on (0,0), which is odd because menu.lst points it to (0,1).

The numbers are different. In grub they're a (device, partition) identifier and in the panic message it's a major:minor identifier. The fact that they're both 0 in the panic tells me that you don't have a driver for that device loaded. If you had the driver loaded and it couldn't mount for some other reason, it would have real numbers, 3:1 is /dev/hda1 for instance.

 

[Chaotic42]

Originally posted by: Nothinman

Yes, I have "initrd=" in menu.lst. It still says panic on (0,0), which is odd because menu.lst points it to (0,1).

The numbers are different. In grub they're a (device, partition) identifier and in the panic message it's a major:minor identifier. The fact that they're both 0 in the panic tells me that you don't have a driver for that device loaded. If you had the driver loaded and it couldn't mount for some other reason, it would have real numbers, 3:1 is /dev/hda1 for instance.

That's weird, because it has ext2 and 3 support built in to it.

 

[Nothinman]

Irrelevant, if it could get to the drive to figure out what fs was on it, it would work. But it's the drive/controller that's not being detected, so you most likely forgot that driver.

 

[Chaotic42]

I built cramfs support into the kernel and it worked.

Thanks for the replies, everyone.