I'm back after getting some sleep. Paul E Condon wrote:
On Thu, Dec 30, 2004 at 01:45:46PM +1000, R G Cottrell wrote:Paul E Condon wrote:On Thu, Dec 30, 2004 at 12:17:44PM +1000, R G Cottrell wrote:Hi folks, I asked this on debian-kernel about 8 hours ago but didn't get any replies. I've tried about half a dozen times over the last year to compile a working kernel for my old 233MHz machine. I thought I might have had a defective processor (a K6) but I've changed it to a genuine Intel Pentium and still had no success. I can successfully install one of the precompiled kernel images, but compiling one on my box has failed so far. At one point I filed a bug report but Herbert Xu was unable/unwilling to help.I am currently running RC1 of sarge with a 2.4.27 kernel that I downloaded as a kernel image, but I've previously tried with3.0r1 with 2.4.18 and other 2.4.x kernels, as well as an early 2.6.x kernel source. I now have: kernel-source-2.4.27_2.4.27-6_all.deb (30M) I thought I knew what to do with this, but my past failures in compiling kernels on this box make me wary. I also have kernel-image-2.4.27_2.4.27-6.tar.gz (95K) but I can't understand what I'm supposed to do with it. I've unpacked it but it seems to be for those who already know how it works - there's no readme or help I can see. I also have: kernel-build-2.4.27_2.4.27-6_i386.deb (8K) but I don't really know what to do with it either. I do have kernel-package installed. As far as I can tell, the latest testing kernel image for Pentium is: kernel-image-2.4.27-1-586tsc_2.4.27-6_i386.deb (11.5M)
:-( Not any more. I wonder if I'll run into the compile-time bug described for the -6 version. We'll see.
Surely it can't hurt to have an identical file sitting around on the hard drive.What commands do I need to issue in order to generate a .deb that is _identical_ to that? I assume I have to use make-kpkg, and it probably depends on the precise version of the compiler.The Debian way really does work. I suggest that you stick with it.I'd certainly prefer to be able to do it the Debian way.You use make-kpkg as your main tool. Making a kernel package that is _identical_ to the precompiled package that you have already downloaded is unwise. You need, at least, to change the version/rev.number or something so that your computer can distinguish between the two (and so that you can distinguish between the two inorder to tell whether or not you have succeeded)Well, I was planning to rename the original, downloaded kernel-image, after verifying that it would boot my machine. It should. I'm currently running on the -2 suffixed kernel, so the -6 should work too, I hope.The instructions for setting up this change are in man page (I think). Choose an ID stringthat includes something personal, such as you initials.I think I see how to do this, now that I've been directed to: http://www.debian.org/doc/manuals/reference/ch-kernel.en.htmlThen copy the config file of the prepackaged kernel from /boot into the source tree under /usr, and follow the steps in the man page.Makes sense.Making a near identical copy of a Debian kernel package is a good training exercise, and good first step. If it fails, you know that your new kernel is not failing because of a poor choise of kernel config options, you are using the ones that you know work for your hardware. After you have succeeded at this exercise, you can start tweeking the config parms and recompiling. HTHThe point of making one that is byte-for-byte identical to the downloaded kernel-image is to check for subtle errors. If I get a kernel-image that is similar but not identical, it would be difficult to rule out user error ifthe thing doesn't in fact boot. If I can create one that is identical, thencustomising it should be a snap.The kernel image (i.e. the actual file that is used to load the kernel into RAM) contains its own name, as internal data. You will have a muddle if you try to have two kernel images on your harddisk that have the same name. If you have an image whose name is different from what it thinks it is named you will also have a muddle. Think of adifferent way of verifying that you have succeeded.
I can go back to booting the 2.4.26 kernel and avoid any problem with the modules, by scrubbing the 2.4.27 modules before installing any modules I compile.
Maybe I'm stubborn, but I want to use cmp to verify that it is possible to build an identical package. One thing that might defeat me is if there are timestampsIf you create a new kernel image package with a new name, but using the same config options, and then install this new package you will have a new config file in /boot which will have your new name and will contain the options selections that were used to produce it. Diff of this against the one that was already there is one check that you can do. But, diff of the kernel images will surely fail to show identity. Think of somethingelse to do to give you confidence in your work.
inside the kernel image as well.
Also, the name of the kernel image is also used to select which set of runtime loadable modules are used by the kernel. You need to keep yournewbie modules out of the way of the working kernel so that you can revert to the old working kernel if you do make a mistake.
As mentioned above, I can go back to the 2.4.26 kernel and modules. I'll check that my system will still boot 2.4.26.
I've been through the process quite a few times (unsuccessfully) and read quite a bit, but it never seems to come out right. I have successfully compiled a kernel or three on a different machine using an old copy of red hat, and I've been programming in C and other languages onand off for almost 2 decades, but Debian kernels seem to give me trouble. Maybe it's just some subtle fault in this old box.Having kernel image contain self documenting data internally is beyond anything I had ever seen when I first built a new kernel. Subtle, but nota fault.
Hmm... I appreciate your concern for the safety of my system. I'll try itboth ways, and be extra careful not to hose my system by ignoring the pitfalls.
I'll let you know how it goes. Regards, Rossc.