VFS: Cannot open root device

VFS: Cannot open root device

[Jeremy]

Hello all,
 HELP, I have a new server that I am trying to put
Redhat 7.0 on. It is a Compaq Proliant ML530 Dual PIII
1Ghz with a Gig of RAM. It has a Compaq smart array
5300 in it also. It boots just fine with the default
Redhat 7 kernel 2.2.16smp but when I compiled my own
2.4.2 kernel I get the following message.

request_module[scsi_host_adapter]: Root FS not mounted
request_module[scsi_host_adapter]: Root FS not mounted

Then some standard lines Then:

NET 4: Unix domain sockets 1.0/SMP for Linux NET 4.0
request_module[block-major-104]: Root FS not mounted
VFS: Cannot open root device "6802" or 68:02
Please append a correct "root=" boot option
Kernel Panic: VFS: Unable to mount root FS on 68:02

 When I boot 2.2.16 the only modules that are loaded
are cciss, NCR53C8XX, eepro100 and tlan. I have triple
checked and I have built cciss and NCR53C8XX into the
kernel, I even tried them as modules. It almost looks
like it just isn't loading the NCR53C8XX and then it
cant mount the File system.
 If you need any more info please let me know.

Please CC anything to me directly since I am not on
the mailing list.

Thanks,
   Jeremy

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Re: VFS: Cannot open root device

[Jeremy Jackson]

Jeremy wrote:

This is going to get confusing!

> Hello all,
>  HELP, I have a new server that I am trying to put
> Redhat 7.0 on. It is a Compaq Proliant ML530 Dual PIII
> 1Ghz with a Gig of RAM. It has a Compaq smart array
> 5300 in it also. It boots just fine with the default
> Redhat 7 kernel 2.2.16smp but when I compiled my own
> 2.4.2 kernel I get the following message.
>
> request_module[scsi_host_adapter]: Root FS not mounted
> request_module[scsi_host_adapter]: Root FS not mounted

2 possibilities: you misconfigured kernel or didn't
make  an initial ramdisk to load scsi modules.

to make a good configuration, you may wish to use the config
files that redhat used to build the kernel you say works,
and then just tweak a few things like processor type.
they're installed (i think) in /usr/src/linux/configs
if you install kernel-source package.

try command 'man mkinitrd' under redhat
for hints about initial ramdisk.

>
>
> Then some standard lines Then:
>
> NET 4: Unix domain sockets 1.0/SMP for Linux NET 4.0
> request_module[block-major-104]: Root FS not mounted
> VFS: Cannot open root device "6802" or 68:02
> Please append a correct "root=" boot option
> Kernel Panic: VFS: Unable to mount root FS on 68:02
>
>  When I boot 2.2.16 the only modules that are loaded
> are cciss, NCR53C8XX, eepro100 and tlan. I have triple
> checked and I have built cciss and NCR53C8XX into the
> kernel, I even tried them as modules. It almost looks
> like it just isn't loading the NCR53C8XX and then it
> cant mount the File system.
>  If you need any more info please let me know.
>
> Please CC anything to me directly since I am not on
> the mailing list.
>
> Thanks,
>    Jeremy

Re: VFS: Cannot open root device

[Peter Samuelson]

[Jeremy Jackson]
> try command 'man mkinitrd' under redhat for hints about initial
> ramdisk.

I have been puzzled about this for quite some time.  Why exactly does
everyone always recommend using 'mkinitrd' on Red Hat systems?  It
seems to me that if you are compiling a kernel for a specific server
anyway, it is a much more reliable proposition to just compile in
whatever drivers you need to boot.

initrd's are inherently clumsy and fragile, to my way of thinking.
I've always thought they should only be used to support diverse or
unknown hardware, or odd cases like crypto loopback root.  Are there
other advantages to 'mkinitrd' in the case of a custom kernel for a
single machine?

Peter

Re: VFS: Cannot open root device

[Jeremy Jackson]

Peter Samuelson wrote:

> [Jeremy Jackson]
> > try command 'man mkinitrd' under redhat for hints about initial
> > ramdisk.
>
> I have been puzzled about this for quite some time.  Why exactly does
> everyone always recommend using 'mkinitrd' on Red Hat systems?  It
> seems to me that if you are compiling a kernel for a specific server
> anyway, it is a much more reliable proposition to just compile in
> whatever drivers you need to boot.
>
> initrd's are inherently clumsy and fragile, to my way of thinking.
> I've always thought they should only be used to support diverse or
> unknown hardware, or odd cases like crypto loopback root.  Are there
> other advantages to 'mkinitrd' in the case of a custom kernel for a
> single machine?
>

no the reason redhat uses it is to allow a generic kernel for everyone.
having *ALL* drivers in kernel would make it huge, and some drivers
conflict with each other (not many) so they couldn't all be in there.

If you have made a custom kernel (that is configured properly) you don't
need to bother.  The question is if you configured it properly :)

I would suggest taking a config from redhat (it puts them in
/usr/src/linux/configs)
and just tweaking that. (sorry if i already said that once)

other pitfalls include not having the right root= entry (or missing one) in
lilo.conf.

>
> Peter
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/