Re: Kernel compile blues
Deboo wrote:
Looks like the HA driver module the boot drive is attached to is missing
in initrd. A misconfigured LILO may also be the cause.
HA driver module? What's that?
I'm sorry: Host Adapter. I am no native speaker.
And I use grub, not lilo.
Ok, that leaves that out.
> Anyway, is it good to compile 2.6 kernels monolithic?
I'm not absolutely sure on this. Any comments?
In my opinion, it shouldn't be an issue if it is possible by
configuration, but I may be totally wrong on this. I am not
going to use 2.6 Kernels for productive purposes right now.
I would recommend trying a pristine 2.4.25 Kernel from kernel.org first.
Center on booting an unmodified Kernel, then reconfigure, then patch.
>
By unmodified, do you mean no changes to .config, and compiling
with the default options?
No. I meant unpatched Kernel sources with sensible .config changes
reflecting your system's environment. I doubt the default options
will always result in a stable (or bootable) Kernel on most modern
machines.
I do disable everything I don't need. But, I need to
compile win4lin support as well as cmpci sound+modem driver and in
it's readme, they clearly say to compile it as a module.
In this case, better follow the readme.
Not possible in a monolithic kernel.
For me, it was the same thing with the latest QLogic Fibre Channel HBA
drivers. The Kernel driver kept throwing I/O errors, so I patched the
sources to use the one from QLogic, but that wouldn't run stable, too.
The module is fine now.
I am using monolithic kernels where possible; on all machines except
those with Fibre Channel connect, that is.
I do not know C or C++. I'm no programmer.
You don't need to have to. Compiling a Kernel requires no programming
skills. Albeit they may be helpful, though.
Problems arise when I get errors, and the errors are due to some
file syntax problem by the programmer or such. And if I don't have
net access, I get really stuck.
True. But I am stuck just a little bit further down the road, too. I can
read the source and understand what's going on, but in case of errors
most of the time the source is far too complex to fix them on my own.
In my experience the stable Kernel always compiles fine. It has proven
best not to use those third party drivers and add-ons that don't. Even
when I was able to fix some of the errors myself, I often experienced
stability problems afterwards. So I leave debugging to the Kernel hacker
community. But I tend to rather do without some functionality in favour
of a stable system anyway. YMMV.
After that, the image is installed with "dpkg -i <kernel-image>".
This is the "debian way" of installing kernels isn't it?
Yes.
I'd still
like to stick compiling kernels the generic way, except for
keeping my custom compiled kernels as debs for later.
You could do both. AFAIK kernel-package does not hinder you compiling a
kernel the generic way. It just saves you the trouble building a Debian
package yourself.
--
Bye, Kai
Reply to: