Re: Kernel panic: VFS: unable to mount fs on 09:00

Re: Kernel panic: VFS: unable to mount fs on 09:00

[Ralica Kirilova]

Hi, Kevin, Glynn
Thanks for you answers and questions :)

>Glynn
>Change the "root=..." setting in lilo.conf.
>
>Essentially, your problem is that you're trying to boot directly from
>a software RAID device, but the device doesn't exist at boot time.
>
>You have to pass additional options to the kernel in order to tell it
>which devices (partitions) make up the RAID array. See
>Documentation/md.txt for details.

My lilo.conf and /etc/raidtab (which is explained in md.txt)
lilo.conf
________________
disk = /dev/md0
bios=0x80
sectors=63
heads=255
cylinders=553
partition=/dev/md1
start=63
boot=/dev/sda
map=/boot/map

prompt
timeout=150

vga=normal

# this CAN'T boot
image=/boot/bzImage.0428
    root = /dev/md0
    label = LRH0427
    read-only

#this boots
image=/boot/vmlinuz
    root = /dev/md0
    label = LinuxRaid
    read-only

#END.
________________
raidtab
________________
raiddev    /dev/md0
raid-level    1
nr-raid-disks    2
chunk-size    32
nr-spare-disks    0
persistent-superblock    1
device    /dev/sda1
raid-disk    0
device    /dev/sdb1
raid-disk    1

raiddev    /dev/md1
raid-level    1
nr-raid-disks    2
chunk-size    32
nr-spare-disks    0
persistent-superblock    1
device    /dev/sda2
raid-disk    0
device    /dev/sdb2
raid-disk    1
________________

I can't find a mistake. If younitice sth please let me know

>Kevin
>Did you run "make modules" and "make 
>modulesinstall"?
Yes.
>If its not the kernel, its the way the boot 
>loader is configured to boot the new kernel.  Is that the same?
I've posted my lilo.conf, if you find sth please let me know :)
And I run lilo, lilo -q, etc , after editing lilo.conf

I'll try to do sth with initrd. May be the problem is here.
I'll continue to search the net
Have a nice weekend :)

Re: Kernel panic: VFS: unable to mount fs on 09:00

[Glynn Clements]

Ralica Kirilova wrote:

> >Change the "root=..." setting in lilo.conf.
> >
> >Essentially, your problem is that you're trying to boot directly from
> >a software RAID device, but the device doesn't exist at boot time.
> >
> >You have to pass additional options to the kernel in order to tell it
> >which devices (partitions) make up the RAID array. See
> >Documentation/md.txt for details.
> 
> My lilo.conf and /etc/raidtab (which is explained in md.txt)
> lilo.conf

> # this CAN'T boot
> image=/boot/bzImage.0428
>     root = /dev/md0
>     label = LRH0427
>     read-only
> 
> #this boots
> image=/boot/vmlinuz
>     root = /dev/md0
>     label = LinuxRaid
>     read-only

If other kernels can successfully mount a RAID device, then the device
has been set up for autodetection. In which case, it appears that the
new kernel doesn't have the necessary support compiled in.

The SCSI drivers, SCSI disk support and the various RAID options must
all be built-in (i.e. not modules). Check whether anything critical
has been built as a module.

-- 
Glynn Clements <glynn.clements@virgin.net>

Kernel panic: VFS: unable to mount fs on 09:00

[Ralica Kirilova]

Hi, all
I have a Linux box (Linux Slackware 9.1, uname -r --> 2.4.22),
 with two SCSI Seagate hard disks,
I have software RAID1 running.
Everything is OK.
So I try to precompile the kernel

make clean
make oldconfig     // use this in order to not to have mistake in
configuration.
                            // this is running kernel configuration
make dep, make, make bzImage,
make modules, make modules_install, make install

cp new image in /boot, add new image in lilo, run lilo, reboot
The error:
Kernel panic: VFS: unable to mount fs on 09:00

I don't know if I explained it right.

 Any help is appriciated

P.S. Sorry for my bad english

Re: Kernel panic: VFS: unable to mount fs on 09:00

[Kevin J. Cummings]

Ralica Kirilova wrote:
> Hi, all
> I have a Linux box (Linux Slackware 9.1, uname -r --> 2.4.22),
>  with two SCSI Seagate hard disks,
> I have software RAID1 running.
> Everything is OK.
> So I try to precompile the kernel
> 
> make clean
> make oldconfig     // use this in order to not to have mistake in
> configuration.
>                             // this is running kernel configuration
> make dep, make, make bzImage,
> make modules, make modules_install, make install
> 
> cp new image in /boot, add new image in lilo, run lilo, reboot
> The error:
> Kernel panic: VFS: unable to mount fs on 09:00
> 
> I don't know if I explained it right.
> 
>  Any help is appriciated
> 
> P.S. Sorry for my bad english

What type of filesystem is your "root" partition?
Is all of the necessary support for this fs compiled into your kernel?
If not, did you remake the proper initrd.img file for your new kernel so 
that it contains the proper modules for your root partition?

The chronology is the following:

System BIOS determines the active partition and loads and executes the 
boot loader.

The system boot loader knows where to find the Linux kernel image, how 
to load it, and to de-compress it if necessary.  This kernel image needs 
to contain the necessary file systems builtin to it in order to find and 
mount the root partition so that it can load any necessary modules 
needed to complete your system boot up.

If (like RedHat) your boot loader boots an initial RamDisk image, this 
image can contain copies of various modules needed for the kernel image 
to load so that it has all the necessary modules it needs to find/load 
the root file system.  When it mounts the root partition, it unmounts 
the initial ramdisk and your system boot then continues "normally".

Is this clear enough?

Your RAID fs is a "complicated" file system, and may involve more than a 
simple driver (like an IDE driver or SCSI driver) in order to mount the 
root partition.  All of the necessary support must either already be a 
part of your kernel (making it larger to boot from) or be able to be 
loaded from an initrd image during startup.

-- 
Kevin J. Cummings
kjchome@rcn.com
cummings@kjchome.homeip.net
cummings@kjc386.framingham.ma.us

Re: Kernel panic: VFS: unable to mount fs on 09:00

[Ralica Kirilova]

Hi, Kevin
Thanks for the reply :)

> What type of filesystem is your "root" partition?
fd --> Linux Raid Autodetect

> Is all of the necessary support for this fs compiled into your kernel?
Well, the old kernel boots. I haven't changed the .config
I used make oldconfig
The command  #diff .config .config.old --> returns nothing

> If not, did you remake the proper initrd.img file for your new kernel so 
> that it contains the proper modules for your root partition?
initrd.img is something I'm not familiar with. Byt the kernels are the same
 
> The chronology is the following:
> 
> System BIOS determines the active partition and loads and executes the 
> boot loader.
Yes.
> The system boot loader knows where to find the Linux kernel image, how 
> to load it, and to de-compress it if necessary.  
The problem is that the two kernels are exactly the same.
And the old boots, the new don't !!!
>This kernel image needs 
> to contain the necessary file systems builtin to it in order to find and 
> mount the root partition so that it can load any necessary modules 
> needed to complete your system boot up.
This is OK
> If (like RedHat) your boot loader boots an initial RamDisk image, this 
> image can contain copies of various modules needed for the kernel image 
> to load so that it has all the necessary modules it needs to find/load 
> the root file system.  When it mounts the root partition, it unmounts 
> the initial ramdisk and your system boot then continues "normally".
I'm not sure about this. I use Slackware. 
> Is this clear enough?
Yes :), thanks a lot! 

Something I found is: 09:00 is NOT the SCSI disk. It's SCSI Tape! 
The other kernel reads from 08:00 (or something). Why this kernel
tries 09:00? How can I change this?

Thanks again for replay

help is appriciated

Greetings Ralica Kirilova

Re: Kernel panic: VFS: unable to mount fs on 09:00

[Glynn Clements]

Ralica Kirilova wrote:

> Something I found is: 09:00 is NOT the SCSI disk. It's SCSI Tape! 

Not it isn't. *Character* device 09:00 is /dev/st0 (SCSI tape). Block
device 09:00 is /dev/md0 (software RAID device).

> The other kernel reads from 08:00 (or something).

Block device 08:00 is /dev/sda (the whole of the first SCSI disk). 
More likely, it's using one of the partitions (e.g. 08:01, /dev/sda1).

> Why this kernel tries 09:00?

Because you're trying to boot from a RAID device.

> How can I change this?

Change the "root=..." setting in lilo.conf.

Essentially, your problem is that you're trying to boot directly from
a software RAID device, but the device doesn't exist at boot time.

You have to pass additional options to the kernel in order to tell it
which devices (partitions) make up the RAID array. See
Documentation/md.txt for details.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: Kernel panic: VFS: unable to mount fs on 09:00

[Kevin J. Cummings]

Ralica Kirilova wrote:
> Hi, Kevin
> Thanks for the reply :)
> 
> 
>>What type of filesystem is your "root" partition?
> 
> fd --> Linux Raid Autodetect

Personally, I've never used it, but lets see if we can make some headway 
below....

>>Is all of the necessary support for this fs compiled into your kernel?
> 
> Well, the old kernel boots. I haven't changed the .config
> I used make oldconfig
> The command  #diff .config .config.old --> returns nothing

That means that whatever was builtin to the old kernel is builtin to the 
new kernel, and whatever was a module in the old kernel should be a 
module in the new kernel.  Did you run "make modules" and "make 
modulesinstall"?

As an aside, what are the "names" of your linux kernels?  I recently 
rebuilt a RedHat 2.4.20-28.9 as my own, and called it 2.4.20-28.9kc. 
When the modules got installed, they were installed to a "new" 
directory:  /lib/modules/2.4.20-28.9kc  (the original modules were 
installed in /lib/modules/2.4.20-28.9 by the RedHat RPM when I installed 
it).

>>If not, did you remake the proper initrd.img file for your new kernel so 
>>that it contains the proper modules for your root partition?
> 
> initrd.img is something I'm not familiar with. Byt the kernels are the same

initrd is a ramdisk image used by RedHat (and others) in order to keep 
the actual number of drivers builtin to the kernel to a minimum, and to 
include those which are necessary in order to help the system finish 
booting and then load all of the necessary filesystems so that the 
"rest" of the modules can be loaded from the newly mounted 
filesystems....  It is particularly used if you boot from a SCSI disk 
and your kernel doesn't have the necessary SCSI modules compiled into 
your kernel.  Instead, the .o files for the modules are copied into your 
initrd.img file my the "mkinitrd" so that your kernel can load them as 
modules before it it ready to mount your actual root partition.

Your error messge (the reason you started this email thread, remember? 
B^) is a problem with the kernel not recognizing the "type" of the root 
filesystem [ie, it does not have the proper support builtin or available 
in the initrd.img file that (may or may not) have gotten loaded when you 
booted.  This is what you need to track down:

	WHERE IS YOUR SUPPORT FOR THE "FD -> Linux RAID Autodetect: 
filesystem....."

>>The chronology is the following:
>>
>>System BIOS determines the active partition and loads and executes the 
>>boot loader.
> 
> Yes.

Good!

>>The system boot loader knows where to find the Linux kernel image, how 
>>to load it, and to de-compress it if necessary.  
> 
> The problem is that the two kernels are exactly the same.
> And the old boots, the new don't !!!

No, if the two kernels were EXACTLY the same, they would both boot!

(Sorry, couldn't resist!)  If its not the kernel, its the way the boot 
loader is configured to boot the new kernel.  Is that the same?

>>This kernel image needs 
>>to contain the necessary file systems builtin to it in order to find and 
>>mount the root partition so that it can load any necessary modules 
>>needed to complete your system boot up.
> 
> This is OK
> 
>>If (like RedHat) your boot loader boots an initial RamDisk image, this 
>>image can contain copies of various modules needed for the kernel image 
>>to load so that it has all the necessary modules it needs to find/load 
>>the root file system.  When it mounts the root partition, it unmounts 
>>the initial ramdisk and your system boot then continues "normally".
> 
> I'm not sure about this. I use Slackware. 

OK, that's progress, I haven't used Slackware since 1995....

>>Is this clear enough?
> 
> Yes :), thanks a lot! 

Feel free to bounce a new set of questions off of me if you need to....

> Something I found is: 09:00 is NOT the SCSI disk. It's SCSI Tape! 
> The other kernel reads from 08:00 (or something). Why this kernel
> tries 09:00? How can I change this?

Check out your Makefile(s).  Look for ROOT_DEV.  The RedHat default is 
the value "CURRENT".  I'm not sure what Slackware is using these days....

Block device 8 is the SCSI disk subsystem, so 08:00 would be /dev/sda.
Block device 9 is the Metadisk (RAID) devices, so 09:00 would be 
/dev/md0....
(Character device 9 is the SCSI Tape system.  Aren't devices wonderful?)

Sounds to me like either you are trying to mount the wrong device as 
your root partition, or you don't have support for your RAID root 
partition built into your kernel....

If you are using SCSI devices in your RAID array, it would then look 
like you need to fix your ROOT_DEV definition in your Makefiles....

> Thanks again for replay
> 
> help is appriciated

Good Luck!  Happy to help!

-- 
Kevin J. Cummings
kjchome@rcn.com
cummings@kjchome.homeip.net
cummings@kjc386.framingham.ma.us

Re: Kernel panic: VFS: unable to mount fs on 09:00

[Ralica Kirilova]

Hi :)
Thank you both for help.
I precompiled kernel with all fs built in and it boots :)
I don't know which is mine, because there aren't fd or 
Linux Raid Autodetect. Anyway, I'll try to find out.
Thanks again for the help :)

Greetings,
Ralica Kirilova