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

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



-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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


-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

console parameter ignored

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
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
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: console parameter ignored

.... 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 ...

-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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 :)



-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: console parameter ignored

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. |



-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: console parameter ignored

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
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: console parameter ignored

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: console parameter ignored

On Mon, May 03, 2004 at 05:30:49PM -0400, A. R. Vener wrote:

> 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.


Are you sure that you compiled that support into your kernel? If you don't
have support for using the serial port as the system console option set,
then the kernel can not use it wheb booting and will have to use the
video/keyboard instead.

--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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


-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html