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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
