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

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>

console parameter ignored

[A. R. Vener]

Hi all,
I am trying to boot a linux box using kernel v 2.4.13
to use the serial !0 device as its console.

My grub config file contains the correct arguments and the S0 device works
fine for the grub boot loader and  for serial login
in run level 3, but the kernel insists on using the keyboard and
monitor as its console during boot and initialization.


I'm including the relevant output from  my dmesg 
and scratching my head. Can anyone tell me why the 
kernel is not using the ttyS0 serial port as its console?

Thanks,
Rudy Vener

dmesg output follows:
Linux version 2.4.13 (bishop@ol311d.drift.platypus.bc.ca) (gcc version 2.95.2 19991024 (release)) #19D SMP Sun Oct 13 22:55:19 PDT 2002
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000f7f0000 (usable)
 BIOS-e820: 000000000f7f0000 - 000000000f7f3000 (ACPI NVS)
 BIOS-e820: 000000000f7f3000 - 000000000f800000 (ACPI data)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
Scanning bios EBDA for MXT signature
Advanced speculative caching feature not present
On node 0 totalpages: 63472
zone(0): 4096 pages.
zone(1): 59376 pages.
zone(2): 0 pages.
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Kernel command line: ro root=/dev/hda1 console=tty0 console=ttyS0,38400n8
Initializing CPU#0
Detected 851.941 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 1697.38 BogoMIPS
Memory: 247172k/253888k available (1059k kernel code, 6332k reserved, 264k data, 264k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0183fbff c1c7fbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
CPU: After vendor init, caps: 0183fbff c1c7fbff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0183fbff c1c7fbff 00000000 00000000
CPU:             Common caps: 0183fbff c1c7fbff 00000000 00000000
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
CPU: Before vendor init, caps: 0183fbff c1c7fbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
CPU: After vendor init, caps: 0183fbff c1c7fbff 00000000 00000000
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0183fbff c1c7fbff 00000000 00000000
CPU:             Common caps: 0183fbff c1c7fbff 00000000 00000000
CPU0: AMD Duron(tm) processor stepping 01
per-CPU timeslice cutoff: 182.84 usecs.
SMP motherboard not detected.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 851.9146 MHz.
..... host bus clock speed is 200.4505 MHz.
cpu: 0, clocks: 2004505, slice: 1002252
CPU0<T0:2004496,T1:1002240,D:4,S:1002252,C:2004505>
Waiting on wait_init_idle (map = 0x0)
All processors have done init_idle
PCI: PCI BIOS revision 2.10 entry at 0xfb3f0, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router SIS [1039/0008] at 00:01.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
mxt_scan_bios: enter
Starting kswapd v1.8
VFS: Diskquotas version dquot_6.5.0 initialized
vesafb: framebuffer at 0xa0000, mapped to 0xc00a0000, size 128k
vesafb: mode is 640x480x4, linelength=80, pages=17862
vesafb: scrolling: redraw
Console: switching to colour frame buffer device 80x30
fb0: VESA VGA frame buffer device
pty: 1024 Unix98 ptys configured
block: queued sectors max/low 163960kB/54653kB, 512 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 01
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SiS730
    ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:pio, hdd:pio
hda: Maxtor 2B020H1, ATA DISK drive
hdb: LTN526D, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 40020624 sectors (20491 MB) w/2048KiB Cache, CHS=2491/255/63, UDMA(100)
Partition check:
 hda: hda1 hda2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Cronyx Ltd, Synchronous PPP and CISCO HDLC (c) 1994
Linux port (c) 1998 Building Number Three Ltd & Jan "Yenya" Kasprzak.
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
IEEE 802.2 LLC for Linux 2.1 (c) 1996 Tim Alpaerts
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: AppleTalk 0.18a for Linux NET4.0
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 264k freed
mice: PS/2 mouse device common for all mice
ide-floppy driver 0.97.sv
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
  Vendor: LITEON    Model: CD-ROM LTN526D    Rev: YSR7
  Type:   CD-ROM                             ANSI SCSI revision: 02
8139too Fast Ethernet driver 0.9.20
PCI: Found IRQ 11 for device 00:0d.0
PCI: Sharing IRQ 11 with 00:01.2
PCI: Sharing IRQ 11 with 00:01.3
eth0: RealTek RTL8139 Fast Ethernet at 0xd0038000, 00:07:95:4e:43:b0, IRQ 11
eth0:  Identified 8139 chip type 'RTL-8139C'
Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, version 0.14.9d, 23:29:39 Oct 13 2002
PCI: Found IRQ 12 for device 00:01.4
trident: SiS 7018 PCI Audio found at IO 0xe000, IRQ 12
ac97_codec: AC97 Audio codec, id: 0x414c:0x4710 (ALC200/200P)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
PCI: Found IRQ 11 for device 00:01.2
PCI: Sharing IRQ 11 with 00:01.3
PCI: Sharing IRQ 11 with 00:0d.0
usb-ohci.c: USB OHCI at membase 0xd0059000, IRQ 11
usb-ohci.c: usb-00:01.2, Silicon Integrated Systems [SiS] 7001
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 3 ports detected
PCI: Found IRQ 11 for device 00:01.3
PCI: Sharing IRQ 11 with 00:01.2
PCI: Sharing IRQ 11 with 00:0d.0
usb-ohci.c: USB OHCI at membase 0xd005b000, IRQ 11
usb-ohci.c: usb-00:01.3, Silicon Integrated Systems [SiS] 7001 (#2)
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 3 ports detected
8139cp 10/100 PCI Ethernet driver v0.0.5 (Oct 19, 2001)
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 196M
agpgart: Detected SiS 730 chipset
agpgart: AGP aperture is 64M @ 0xd8000000
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport0: irq 7 detected
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
NET4: Linux IPX 0.47 for NET4.0
IPX Portions Copyright (c) 1995 Caldera, Inc.
IPX Portions Copyright (c) 2000, 2001 Conectiva, Inc.
eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1.
eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1.
spurious 8259A interrupt: IRQ7.
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
sr0: scsi3-mmc drive: 52x/52x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
lp0: using parport0 (polling).
lp0: console ready

Re: console parameter ignored

[terry white]

... ciao:

on "4-29-2004" "A. R. Vener" writ:"


: to use the serial !0 device as its console.

    i'd start by looking here:

	"/dev/hda1 console=tty0 console=ttyS0,38400n8"

    instead of 'console=tty0', let me suggest "/dev/ttyS0" , or something
like it.


: My grub config

   "I Know Nodthing" ...


-- 
... i'm a man, but i can change,
    if i have to , i guess ...

Re: console parameter ignored

[Bill Carlson]

On Thu, 29 Apr 2004, terry white wrote:

> ... ciao:
> 
> on "4-29-2004" "A. R. Vener" writ:"
> 
> 
> : to use the serial !0 device as its console.
> 
>     i'd start by looking here:
> 
> 	"/dev/hda1 console=tty0 console=ttyS0,38400n8"
> 
>     instead of 'console=tty0', let me suggest "/dev/ttyS0" , or something
> like it.

No, look at serial-console.txt in the kernel Documentation, the above 
syntax is correct for the kernel.

Rudy, you'll need to tell grub to support serial; I prefer lilo and one 
has to tell lilo specifically to support serial as well as add the kernel 
parameters. You'll have to figure out what to tell grub.

Also, double check your kernel parameters are being read correctly by 
checking /proc/cmdline.

Bill Carlson
-- 
Systems Administrator    wcarlson@vh.org      | Anything is possible,
Virtual Hospital      http://www.vh.org/      | given time and money.
University of Iowa Hospitals and Clinics      |       
Opinions are mine, not my employer's.         | 

Re: console parameter ignored

[A. R. Vener]

Grub supports the serial console just fine. I can use it during the GRUB boot 
process to select   the linux image and command line options I want.

The problem happens when the kernel takes over and begins  printing 
messages to the console or waiting for input from the console in case of fsck 
failure.  

The /proc/cmdline file shows:
ro root=/dev/hda1 console=tty0 console=ttyS0,38400n8

So apparently the kernel is reading the command line arguments correctly.

For some reason, the kernel is  not using  ttyS0 for its console.  The kernel 
boot messages go to the video screen and  input is read from the keyboard.

Once the boot process reaches run level 3 however,  the getty process on ttyS0 
works and I can login, assuming all goes well.

Since GRUB and getty  both work with the ttyS0 serial port, there
is obviously nothing wrong with it per se. So I am left with the 
conclusion that for some reason the kernel is refusing to use the ttyS0 port 
as its console.

On Mon, May 03, 2004 at 03:51:52PM -0500, Bill Carlson wrote:
> No, look at serial-console.txt in the kernel Documentation, the above 
> syntax is correct for the kernel.
> 
> Rudy, you'll need to tell grub to support serial; I prefer lilo and one 
> has to tell lilo specifically to support serial as well as add the kernel 
> parameters. You'll have to figure out what to tell grub.
> 
> Also, double check your kernel parameters are being read correctly by 
> checking /proc/cmdline.
> 
> Bill Carlson

Rudy Vener

Re: console parameter ignored

[Milan P. Stanic]

On Mon, May 03, 2004 at 05:30:49PM -0400, A. R. Vener wrote:
> For some reason, the kernel is  not using  ttyS0 for its console.  The kernel 
> boot messages go to the video screen and  input is read from the keyboard.

Does it have compiled in support for serial console?
 
> Once the boot process reaches run level 3 however,  the getty process on ttyS0 
> works and I can login, assuming all goes well.

That convince me that the your kernel image doesn't have support for
serial console, but I can be wrong.
 
> Since GRUB and getty  both work with the ttyS0 serial port, there
> is obviously nothing wrong with it per se. So I am left with the 
> conclusion that for some reason the kernel is refusing to use the ttyS0 port 
> as its console.

Se above.

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

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>