Kernel recompile, LILO warning and Kernel-panic
 

I'm having trouble with compiling my own kernel(2.6.22.1 to be exact). I download the source, extract it to /usr/src, fix /usr/src/linux symlink to point to the new kernel tree, copy .config from old (Slack12 original)kernel to my new kernel, run make menuconfig to add some ACPI stuff to it and compile, make returns no errors, so doesn't make modules_install, but then I run make install witch installs the kernel corectly only LILO returns an warning:
And this is my /etc/lilo.conf :
Well then when I reboot I get an error that it cant mount /dev/hda2 and has tried with XFS(although hda2 is Ext3) and complains something about a block at (3,2) and then Kernel-panic.

LILO is located/installed on hda2 not on MBR.
And I really don't have any idea what's going on.

Did you make sure that the ext3 filesystem was compiled into the kernel and not as a module?
You will need an initrd if ext3 was compiled as a module.

Also, are you saying you did or didn't do make modules_install?

i like this way:
If you don't get any errors from that, but it still won't boot, you haven't compiled in your fs support or '/' device drivers.
You can recompile with these things built in, or make an initrd for fs support.
then edit lilo.conf and add this line:
IMO I would also not rely on a single lilo.conf entry. Its very helpful to leave at least your last known good kernel around as the vmlinuz and just add new entries, that way you can (theoretically) always boot.

hth

So that was the problem?
I've checked the File Systems part in te menu again and ext3 was compiled as module yes, and no I didn't have a initrd, but I did make modules_install
I've compiled ext3 fs support not as a module, I'll reboot and report. Thank you.

:twocents:
Sometimes it doesn't hurt to do inside the /usr/src/linux (this will also delete any .config* or changes you may have) Then after the make mrproper, cp .config (a working one) to /usr/src/linux and make menuconfig or make oldconfig (if using an older kernel version).
LFS recomends make mrproper: http://www.linuxfromscratch.org/lfs/...08/kernel.html
again, my :twocents:
Btw i have a similar lilo warning, still not sure how to fix it:

Hi,

Notice the lba32 in the global section of the '/etc/lilo.conf' file.

The 'man lilo.conf' explains it very well.

Thanks onebuck, i don't wanna hijack this thread; i added lba32 compact, but still the same. Maybe something wrong w/kernel .config. Will keep and eye in here and here
Anyway i still left lba32 & compact in lilo.conf, Thanks again

Hi,

What about your BIOS? It sounds like a geometric problem. Is your BIOS current?

When you put the .config from 2.6.21.5 into the 2.6.22.1 directory,
did you run "make oldconfig" first thing?

Also, have a look at /boot/README.initrd
I had to make an initrd.gz to get my 2.6.21.7 slimmed-down kernel to boot.

Good info on lba32, I was wondering about that myself.

The kernel works, but I'm stuck with 2.6.21.5 still because I have trouble finding a working rt2500 driver. When I compile it I always get that "mac" is not a member of some struct, forgot the name, but when if I comment out the line where it calls for mac from that struct the driver just doesn't work later. Oh well. Will try to download newer version and play with it a bit more, but problem in this thread was solved. Thank you everyone.

*************
Edit:
Fix that problem as well.

Hi,

Could you tell us which problem was solved and how? So the post can be brought to a close. An possibly help someone else with the information from you for the solution.

The problem with the kernel-panic. Because I didn't compile ext3 support into the kernel, but I've compiled it as a module and didn't create a initrd.
But when I've fixed that my rt2500 Wireless driver wouldn't build, so I downloaded the newest daily-CVS package from http://rt2x00.serialmonkey.com and compiled it, installed it and now I'm loving it.

Well, since it seems op Tux-Slack solved his problem...

@onebuck:
It was some years old! as a matter of fact, it had never been updated! I read some howtos in a hurry but all needed a floppy disk, which i don't have atm, so i had to use a cd that came with the mobo from (yuck) xp... The problem persisted after bios upgrade, but i'm glad i did it.
No more lba32 issues, but still the:
It ended up being that i had compiled it as a module instead of being built in the kernel, so for anybody with the same issue:
Thank you :)

Hi,

Glad too see you got it up and flying. I like to document everything that I do for any system that I work on. That way I have a trail to backtrack when needed. Unlike a computer that has a memory failure mine doesn't get replaced easily.

more thread hijaaking
 

Slackware 12: I'm compiling a kernel with no support at all (intentionally) for RAID or LVM. I get this when I run lilo:
but I don't get your "Failure to communicate with kernel device-mapper driver." error.

Should I do anything to remove this spurious warning?

The device-mapper error relates to the fact that your kernel isn't compiled with lvm/lvm2 support.

Now, there's 2 possibilities here -

1) you fucked up & actually have an LVM partition, in which case you need lvm - go recompile your kernel.

2) Second possibility and I suspect this is the right one, is that you didn't compile in lvm because you don't have an lvm partition and thus don't need it.

Now assuming the second possibility is correct....

I've seen various postings like this, invariably someone answers regarding the lba32 error, misunderstanding the OP's real problem.

The problem arises because the Makefile for lilo compiles in lvm support by default on 2.6 kernel. The solution is to grab the lilo sources from your local slackware mirror & patch the Makefile - at the beginning you'll see CONFIG, remove -DDEVMAPPER from that and recompile (either by combining your patch into the slackware build script, or by rebuilding manually yourself).

Note: though it shouldn't be a fatal error - the above will shut it up though.

Martin

Update: You may want to also remove -DLVM too, since this is LVM1, though I've not tested it. (I also removed DREISERFS since I don't use it).

The required patch. You only need to add a line to the build script to apply the patch and rebuild.

Note the above is my patch for me, so also removes support for ReiserFS - IF YOU NEED REISERFS YOU'LL NEED TO CREATE YOUR OWN PATCH.

or you can put this line on /etc/rc.d/rc.modules
this will load the device-mapper modules

How can you load a module you haven't compiled in?

Edit: ignore me

Hi,
Did you check the date of the post since you are into broadcasting so much detail?

The lba32 is due to the 1024 BIOS problem. I referenced the large disk howto in case you need the information.

Judge as you be judged! Pointing fingers or fault will get nowhere. People here do try to provide detail and information that will assist not tear down. WE all want to bring things to the proper solution. For some it is their own way of giving back to the community.

As to your question about module loading, it seems you have the answers. :tisk:

see the dev-mapper fatal error which is causing the problem - I've posted the solution.

The "OP" of this old thread never reported any problems with LVM/DM. The thread was hi-jacked and you thought it was necessary to revive the corpse by answering to the post that was not dealing with the original thread.
The "people" advising to load the module were exactly one person.

Eric

True, my response was in fact to MannyNix and the others who reported the dev-mapper error(s):

The OP is likely missing support for his fs from kernel, but that's not an issue with lilo :)

Hi,
It was a non-fatal 'lilo' omission.

The OP problem was indeed an omission of the lba32 in the '/etc/lilo.conf'. The hijacking seemed to cause some confusion but the original problem was a 'lilo' problem.

You did not detail your response as to addressing the dev-mapper and the hijack thread.

I think the problem of the OP was resolved and the hijack was not responded too properly. If you are so maddened by such then so be it. Just don't mis-inform or change the drift of the original thread to suit your argument. It's good that you did attempt to fix your problem on your own but to put the information back into a dated resolved thread helps no one by the appended confusion. If you address the hijack and with a proper solution then you would be helping others by addressing that problem directly.

If you had just composed and posted in a manner that wasn't proper then I or anyone else would not be wasting time. That's not helpful in my book.

As for your mental attitude about being pissed that no one had responded properly. Maybe you should take from your own statement and respond properly within the content of the thread.

Yup, that certainly sounds like "non-fatal" error.

My mistake. I mistakenly thought it was the OP not a later post that identified the dev-mapper problem. There is a number of other threads found via google, which follow the post dev mapper problem, but also the lba32 line and about 40 posts afterwards telling the OP to add lba32 to lilo.conf.

Hi,
Original Poster;

It was a non fatal lilo omission for OP. Did you read the entire thread?

The errors were lba32 and the OP forgetting to include a initrd in the '/etc/lilo.conf'. I really think the time spent defending a old thread is over. You don't seem to read the threads for understanding nor understand that the thread was hijacked therefore confusion from that tainted the thread.

BTW, when you quote something include the reference to prevent confusion thus not adding confusion to an already convoluted thread.

I think this has run it's course really. The original problem has been resolved and, since then, the sum of knowledge has been added to. If anyone has a similar problem, hopefully this thread helps and, if it doesn't, please open a new thread.

Closed.