Hi,
I've been trying FAI (under Debian Sarge), and instead of using the pre-built kernel, I'd like to use
my own one, patched with latest i2c/lm-sensors stuff. So I got 2.4.27 from kernel.org, patched it with
i2c and lm-sensors 2.8.7, copied the .config file of the 2.4.26 Debian kernel, did a make oldconfig
to add only new stuff, and ran make-kpkg --initrd binary modules.
Unfortunately, the new kernel doesn't boot:
VFS: Mounted root (cramfs filesystem) readonly.
...
.../ide-core.o: insmod ide-detect failed
.../ide-core.o: insmod ide-disk failed
Journalled Block Device driver loaded
pivot_root: No such file or directory
/sbin/init: ... cannot open dev/console: No such file
Kernel panic: Attempted to kill init!
Since the original Debian kernel works, and I didn't modify the .config
(except for the new features), I cannot see what has gone wrong here.
Of course I might change the .config to include IDE support into the kernel,
but the main idea is to achieve maximum flexibility... FAI, y'know...
Any ideas?
Steffen
tried debian sources?
Why don't you use the debian sources, contained in the package kernel-source-2.4.27? It consists of the kernel.org-sources with the (few) debian patches applied. At least in older releases (when I still used 2.4) it contained cramfs-initrd patches, which were important for initrd booting.
If you are lucky, the kernel-patch-2.4-lm-sensors and kernel-patch-2.4-i2c packages already support 2.4.27, in this case you only have to set $PATCH_THE_KERNEL and make-kpkg does its job. This way you don't even have to enter patch command lines by hand.
debian vs pristine
I tried to patch 2.4.26, with i2c and lm-sensors, and make-kpkg
failed miserably.
2.4.27 is still in sid, right? probably there are newer i2c/lm
kernel modules, too.... will have a look although I'd rather stay
with sarge.
kernel.org but no sid-kernels?
Kernels in sid are definitely more stable than kernel.org-kernels.
At least they get the security fixes, which kernel.org only receive in the next revision.
As an example, the 2.6.7-lseek-bugs are fixed in the debian 2.6.7-sources, and debian never offered 2.6.8 without the .1-fixes...
I did not suggest to get everything else from sid instead of sarge, but if you despise sid-kernels, why do you use the even worse kernel.org-kernels, instead of waiting for them to get into sarge?
BTW: what do you mean by "make-kpkg failed miserably"? What horrible things happened to you? Did the patches stop make-kpkg working, or what else happened? IIRC it only calls the kernel makefile in various ways and packages the result, so does the normal kernel build fail as well? Are the patches ok? I just never had problems with make-kpkg as an entity. Have you followed its advice and removed version.h? And used --append-to-version? Tried make-kpkg clean? Or as a last resort, patched the version number in debian/changelog?
kernel.org kernels, distribution kernels, and feedback
I looked through the patches which came with Debian 2.4.26 sources -
and would have expected at least a small part of them to be included into the 2.4.27 mainstream kernel. Almost none. If this is the new kernel development model, we'll be running into Babel tower problems pretty soon - which author of software can keep track of all possible
platforms? (There are the "rude" ones who would require you to run the same kernel as they do - I won't name the author of this nice software to write onto silvery platters called CDs.)
I'd like to be able to use "foreign" patches (ex.: web100.org) to tune my machines according to their tasks.
At least Debian would release a 2.4.xy kernel shortly after the pristine one has been made available (with the Big Distros I would have to trust the guys to have backported all the fixes to 2.4.18, and still miss network drivers for e1000). So far so good, but IMHO not optimal/ideal (which isn't the same BTW).
Since using the 2.4.27 stuff produced an overall good result (except that I probably won't be able to include the web100 patches, but I'm not under pressure here), I'm too lazy to go and re-try 2.4.26 (which
stopped with asus_acpi compile problems, obviously unrelated to the patches applied). Next time perhaps...
Thanks to the Anonymous who suggested to try sid. I owe you a can of beer... --- case closed.