Kernel panic because of unresolved symbols ? Help me please!

JhAgA · 03-23-2006, 10:00 AM

Hi there!

I'm trying to recompile the kernel in a Network Debian Install in an old MMX 200 with 64 MB (which works wonders with Gentoo so far).

I downloaded the last 2.6 kernel source using aptitude, and followed the exact instructions on this page:

h t t p : / / w w w .debian.org/releases/stable/i386/ch08s05.html.en

Everything worked OK, but there was something that caught my attention:

Code:

old:/usr/src/kernel-source-2.6.8# dpkg -i ../kernel-image-2.6.8_custom.1.1_i386.deb
Selecting previously deselected package kernel-image-2.6.8.
(Reading database ... 17815 files and directories currently installed.)
Unpacking kernel-image-2.6.8 (from .../kernel-image-2.6.8_custom.1.1_i386.deb) ...
Setting up kernel-image-2.6.8 (custom.1.1) ...
depmod: *** Unresolved symbols in /lib/modules/2.6.8/kernel/drivers/acpi/thermal.ko
depmod: *** Unresolved symbols in /lib/modules/2.6.8/kernel/drivers/ide/ide-cd.ko
depmod: *** Unresolved symbols in /lib/modules/2.6.8/kernel/fs/ext3/ext3.ko
Not updating image symbolic links since we are being updated (custom.1.1)
Searching for GRUB installation directory ... found: /boot/grub .
Testing for an existing GRUB menu.list file... found: /boot/grub/menu.lst .
Searching for splash image... none found, skipping...
Found kernel: /boot/vmlinuz-2.6.8
Found kernel: /boot/vmlinuz-2.4.27-2-586tsc
Updating /boot/grub/menu.lst ... done

I assume those "unresolved symbols" have something to do with the "Kernel Panic" I'm experiencing, no matter how many times I recompile it, the same unresolved symbols occur and kernel panic too.

Code:

(...)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128Kib
hda: 58633344 sectors (30020 MB) w/418Kib Cache, CHS=58168/16/63
 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 >
mice: PS/2 mouse device common for all mice
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4 Kbytes
TCP: Hash tables configured (estabilished 4096 bind 8192)
NET: Registered protocol familiy 17
Kernel panic: VFS: Unable to mount root fs on unknown-block(3,5)

Could someone please help me on this? BTW, I'm still a Linux newbie, so please, don't tell me only to "link the libraries properly" and stuff like that, because I won't know how to do it...

Thank you very much in advance!
Jh00

P.S. - support for ext3, ext2 and Generic IDE (and the second, more improved IDE support) were compiled into the kernel, but NOT as Modules.

TigerOC · 03-23-2006, 10:38 AM

Check whether;
/lib/modules/2.6.8/kernel/drivers/acpi/thermal.ko
/lib/modules/2.6.8/kernel/drivers/ide/ide-cd.ko
/lib/modules/2.6.8/kernel/fs/ext3/ext3.ko
actually do exist.
It's been a while since I compiled a new kernel but found that using the Debian source was the only way and also I have always used an initrd.img. The initrd.img means the kernel is actually using the image to boot.
Given the age of the m/board you are using, is there any particular reason to compile a new kernel? A standard kernel is likely to have all the drivers you would need.

JhAgA · 03-23-2006, 10:48 AM

Wow, that was fast, thanks!

In fact, I thought that maybe it would take a little longer for someone to post a reply, so I decided to uninstall my previous kernel build and do it again. This time I followed the booting screen from the default kernel and noted that the system SEEMS to have detected a SIS5513 chipset, which was not compiled into my kernel attempt. So I'm waiting for it to compile again to see if it solves my problem.

Because of that, I can't say if those files were there or not. But I will know it in a couple of minutes (hopefully).

The reason to recompile the kernel is to save up some more memory, since I don't need the default support for USB, Firewire, SCSI, sound, IPv6 etc.

I'm still confused on how Grub works, and don't have an idea about how initrd.img works (because, in my head, if the kernel isn't using the image, it is using what?). I wish I could do a debian install using the good old lilo...

Anyway, I will post about those files in a couple of minutes.

On another note, is there any file in the system that keeps a log of the booting process? I had to type all the info in the first post by hand...

Thanks!

TigerOC · 03-23-2006, 11:20 AM

Quote:

Originally Posted by JhAgA

I'm still confused on how Grub works, and don't have an idea about how initrd.img works (because, in my head, if the kernel isn't using the image, it is using what?). I wish I could do a debian install using the good old lilo...

On another note, is there any file in the system that keeps a log of the booting process? I had to type all the info in the first post by hand...

Thanks!

Grub is great and really very straight forward. Have a look at /boot/grub Basically works off stages 1 & 1.5 driven by menu.lst. Great advantage is that when you install a new kernel it is automatically updated. Lilo has to be manually updated. Editing is purely a matter of editing and saving the text file menu.lst.
initrd.img is a compressed kernel image and is loaded into memory and makes booting very fast (no reference to the drive)
There is no log of the initial boot process ( a feature I have always thought to be useful) which can be nuisance when you have to try to remember what the error was as it racing past your eyes.

JhAgA · 03-23-2006, 11:24 AM

Quote:

initrd.img is a compressed kernel image and is loaded into memory and makes booting very fast (no reference to the drive)

Does this mean that I need RAMdisk Support? Because I don't have it in my kernel...

(still compiling it, damn, this machine is slowwwww)

divukman · 03-23-2006, 12:36 PM

The part about the logs, try dmesg:
dmesg - to read it or
dmesg|less
(or #dmesg>my_dmesg_file to redirect output to a file).

JhAgA · 03-23-2006, 12:47 PM

Ok, I compilation has ended and the Kernel panic persists. This time, thought, the system complained that /lib/modules/2.6.8 already existed, but I choose YES before installing the package.

The files
/lib/modules/2.6.8/kernel/drivers/acpi/thermal.ko
/lib/modules/2.6.8/kernel/drivers/ide/ide-cd.ko
/lib/modules/2.6.8/kernel/fs/ext3/ext3.ko

do exist though.

Any idea?

TigerOC · 03-23-2006, 02:29 PM

I would suggest reading through this thread. What is apparent from the thread is ensuring that the ide modules should be compiled into the kernel and msdos_partition support is included. One of the contributors reports success with initrd as well. This would require ramdisk support.

JhAgA · 03-23-2006, 02:56 PM

Ok, I'm trying again with MS-DOS and RAM compiled not_as modules. Could you point me to somewhere where I can read more about that initrd thing and how can I use it? As far as I could get, the system loads the kernel into a ramdisk and uses it from there, is it? What happens after the kernel is loaded, does the system removes the RAM disk?

Thank you, I'm very impressed with how how fast people are helping me here (and I've been to lots of other forums, I assure you).

bernied · 03-23-2006, 03:11 PM

this sort of stuff happened to me when i compiled my first kernel in debian. as i remember there is some problem with the file system used by that ramdisk image.

i solved it by ditching the initrd completely - comment out (#) the line that refers to initrd in /boot/grub/menu.lst

just be sure that you have your filesystem support (ext2 or ext3 or whatever) compiled into the kernel and not as modules. scsi hard drives might be a problem - can't remember

i didn't know why they do the initrd thing in debian until now - for speed eh? well it took me several days to boot that kernel - the irony

TigerOC · 03-23-2006, 04:22 PM

Quote:

Originally Posted by JhAgA

Could you point me to somewhere where I can read more about that initrd thing and how can I use it? As far as I could get, the system loads the kernel into a ramdisk and uses it from there, is it? What happens after the kernel is loaded, does the system removes the RAM disk?

I have always used the ramdisk and it appears to be a standard implementation with Debian kernels. The switch to generate it with the kernel looks like this;

$fakeroot make-kpkg --append_to_version -<your_version_#> --initrd \ --revision=rev01 kernel_image

You can read about the functions of a ramdisk

here