kernel compile errors
 

I've retried this kernel malarkey a couple of times now and I'm positive I haven't chosen any incorrect KERNEL options as such, but I still can't actually use my kernel.
I don't have a clue what it really means but I get these errors on choosing my kernel:

Loading jbd.ko module
jbd: version magic '2.6.3-4mdk 586 gcc-3.3' should be '2.6.5 586 gcc-3.3'
Error inserting '/libjbd.ko': -1 Invalid module format
ERROR: /bin/insmod exited abnormally!
Loading ext3.ko module
ext3: version magic '2.6.3-4mdk 586 gcc-3.3' should be '2.6.5 586 gcc-3.3'
Error inserting '/lib/ext3.ko': -1 Invalid module format
ERROR: /bin/insmod exited abnormally!
mounting /proc filesystem
Creating device files
Mounting sysfs
Creating root device
Mounting root filesystem
mount: error 19 mounting ext3 flags defaults
well, retrying without the option flags
mount: error 19 mounting ext3
well, retrying read-only without any flag
mount: error 19 mounting ext3
pivotroot: pivot_root (/sysroot, /sysroot /initrd) failed: 2
Remounting devfs at correct place if necessary
Mounted devfs on /dev
Freeing unused kernel memory: 264k freed
Kernel panic: No init found. Try passing init= option to kernel

I'd really appreciate any help on this as I feel it's my duty as a Linux user to customise as much as possible and eventaully join the Slackware community.

Im no expert at this, but it looks like you boot using an 'initrd', and the modules that the initrd loads, don't match what the kernel expects.

There is an option in the kernel called 'Module versioning support', under 'Loadable module support', which may solve the problem, however it also claims to be 'experimental'.

In the mean time, copying the new jbd.ko and ext3.ko to overwrite the ones in the initrd, should solve the problem. [Obviously backup first in case I am wildly wrong!] [also check don't have support for your root filesystem as a module!]

I'm recompiling now with ext3 as a component, not a module with the same for anything like jbd but somehow I feel this won't be a complete solution.
To be honest I couldn't even find ext3.ko or jbd.ko when I had them set as modules (for some strange reason) in .config and trust me, I tried in ~/linux-2.6.5/fs/ext3 and ~/linux-2.6.5/fs/jbd and have even less of a clue where they would go (i.e. where the originals are for my current kernel).

Here's the text for the fs part of my compile for ext3 and then jbd (compile as yet uncomplete):

CC fs/ext3/balloc.o
CC fs/ext3/bitmap.o
CC fs/ext3/dir.o
CC fs/ext3/file.o
CC fs/ext3/fsync.o
CC fs/ext3/ialloc.o
CC fs/ext3/inode.o
CC fs/ext3/ioctl.o
CC fs/ext3/namei.o
CC fs/ext3/super.o
CC fs/ext3/symlink.o
CC fs/ext3/hash.o
CC fs/ext3/xattr.o
CC fs/ext3/xattr_user.o
CC fs/ext3/xattr_trusted.o
CC fs/ext3/acl.o
CC fs/ext3/xattr_security.o
LD fs/ext3/ext3.o
LD fs/ext3/built-in.o

and

CC fs/jbd/commit.o
CC fs/jbd/recovery.o
CC fs/jbd/checkpoint.o
CC fs/jbd/revoke.o
CC fs/jbd/journal.o
LD fs/jbd/jbd.o
LD fs/jbd/built-in.o

Does this mean anything to you?
Long-shot but hey, I'm an idiot!


Another unrelated problem is that when I do "make xconfig" all the fonts are screwy and are just random patterns (not wingdings or anything like that so I presume there's a lib or two in error).
All the Kconfig files located with the untarred kernel are in good old English so that's another POSSIBLE source out of the way.

I have no idea what any of the output from 2.6's make means.

Setting something as a module causes it to be built as a '.ko', eg ext3.ko. This is then copied from the source tree to /lib/modules/2.6.5/kernel/fs/ etc.

The initrd has a partial copy of this /lib/modules/... tree, and loads modules needed during boot.

Theoretically mounting the initrd 'mount -o loop ./initrd /mnt/loop0' and then copying the new modules from /lib/modules/2.6.5/kernel/fs/... etc to /mnt/loop0/lib/modules/2.6.5/kernel/fs/..., then umount the initrd, and throw in an 'e2fsck ./initrd' for luck, should solve the problem.

Compiling in support for the bits that won't load will also solve the problem, but you may get odd error messages appearing in your log files as the initrd still tries to load them.

I use menuconfig, so I cant help with xconfig problems!

Haven't tried your 'mount -o loop....' stuff yet but I'll try it tomorrow. Too tired to go into complex stuff.

I have noticed this line at the end of my compile:

if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.6.5; fi

Does this have something to do with the fact that I've called my bzImage, vmlinuz-2.6.5_Custom, and my System.map, System.map-2.6.5_Custom?
Does this mean I need to link my new Sytem.map-2.6.5_Custom to something or does it only deal with replacing the standard System.map?

Also, /lib/modules/ contains a 2.6.5 folder. Does this need to be 2.6.5_Custom? The other entries are 2.6.3-4mdk and 2.6.3-4mdkcustom for my current and previous (and unaltered) compiles respectively.

I know I'm asking a whole load of questions before even trying your suggestions but I'm still hoping my spidey-senses can guide me (or at least make me feel big).

I haven't ever tried changing what the kernel calls itself. Making the kernel call itself 2.6.5_Custom probably involves changing the makefile, rather than renaming the bzImage.

If there is a 2.6.5 folder under /lib/modules, then the kernel will be calling itself 2.6.5. [Also check 'uname -r'].

I think that last line is running depmod with the symbols for the new kernel. [http://www.dirac.org/linux/system.map/] explains. Just copy the new one, and create a link from it to /boot/System.map so that anything that needs it can find it.

You need to do a 'make modules_install' to get the correct modules for your kernel.....you do this after the make.

what is happening in your case is that you are getting the jbd.ko module for the previous kernel.

the module versioning helps to keep modules from failing by making sure that you run the module on the same version of the kernel for which it was compiled...i normally turn this off since it can be a pain when putting modules on other similiar systems...but the kernel is slightly different.

cheers,

Mark.

WHOOOOOOOOAAAAAAAAAAA!

Forgot about this thread for a few months there.

I found the problem was down to me compiling support for my root partition as a module (and the fact that mandrake is buggy - not in this instance but just in general).

I'm on slack10 now and I'm lovin' it to borrow a horrible marketing slogan.

Thanks though for replying after so much time of inactivity.