Hi folks, I've compiled my own kernel numerous times but am not programming-literate; often I wish there was a howto that explained the significance of certain common problems that I seem to have over and over again. Haven't found one, though, so thought I'd write my own:
http://wiki.debian.org/KernelCompileTroubleshooting Unfurtunatley, I'm so ignorant, I can't really answer my own questions! Therefore, I'm asking for help. I'd like to hear what is wrong, misleading, or justp lain missing from this document. The current version is appended below, and feel free to carry on this ocnversation eithero n the list, or by direct modification of the wiki page (which is after all what wikis are for). Thanks, Matt -------------------------------------- KernelCompileTroubleshooting BuildYourOwnKernel Please Do not Trust This Page! Author is Ignorant! Instead, Amend with Corrections! Sometimes the standard howto is not enough. This page describes some factors that affect the success of kernel compilation and installation, for non-programmers like the author who don't really understand what happens when the kernel is compiled. BuildYourOwnKernel and the link collected their is a much better place to start! 1. Compile-time problems setting gcc version GCC is the gnu-c-compiler; it's the program used to compile all the C-based programs on your system (that's most of them). New versions of the compiler are periodically released, I guess either because the C language standard changes, or because new hardware comes on line that requires special implementations (I think, for instance, that it's easier to use recent gcc versions to compile 64-bit-processor-compatible code; but I don't really know, I already said I'm not a programmer!). In general, the linux kernel does not compile equally well with all versions of gcc. It would be nice to have a complete list of which kernel versions suggest/require which gcc versions, but I don't have one; I do know, though, that Debian/Sid kernels are currently (Oct. 2005) all compiled with gcc-4.0. However I've had lots of trouble compiling kernels 2.6.12 and lower with gcc-4.0. On Debian, /usr/bin/gcc is a symlink, so in principle you can just change the target from gcc-4.0 to gcc-3.4 whenever you like. This however is not recommended, because many packages will expect the link to point to a particular version of gcc (why is this? I'd love to know the answer.). Instead, we can easily change the version of gcc used by make-kpkg using the "MAKEFLAGS" command: * MAKEFLAGS="CC=gcc-3.4" make-kpkg kernel-image Question: Does this always really work? Or are there other factors in your environment that can influence compile-time behaviour by make-kpkg? One thing to done here is that third-party modules built for the resulting kernel must be built with the same version of gcc as the kernel-package itself. You can do that thusly: * using module assistant: o CC="gcc-3.4" module-assistant auto-install some_source_package or o module-assistant --cc="gcc-3.4" auto-install some_source_package * in the old-fashioned way: o ./configure CC="gcc-3.4" make Anyone know if this is really true? Cleaning the Tree When you compile a kernel, hundereds (thousands?) of new files are created in the kernel tree. By default those files are left in place after the kernel is built. That's great if you want to recompile the kernel soon after -- maybe you forgot to include a module? -- the computer just reuses the files from the last install, and the whole process only takes a minute or two instead of an hour. However, sometimes the files left behind can break your next compilation. I don't really know why, but here are some things I've seen: * You want to change the revision or "append-to-version" flags on your compile (maybe because, after 10 or 20 tries, you've actually made a kernel that compiles, installs, and boots, and you don't want to delete that kernel when you install the next one). make-kpkg will not let you proceed without cleaning the tree. * Somehow you've screwed up something in your build environment -- maybe on your last attempt you accidentally compiled with a different gcc-version? -- and the files left behind on your disk are corrupted. THen stuff further down the road will get screwed up too (is this really true?). So when compiling seems somehow harder than it should be, do this: * make-kpkg clean Other Problems Sometimes, no matter how many times I clean the tree or how carefully I set the gcc-version, I STILL seem to have problems. I don't know what causes them, but I think part of the issue is that the kernel is very complex, and enabling certain options and not others can create a set of build parameters which the developers didn't test -- thus leading to compile-time failure. Usually I just run make menuconfig uncheck the failing module, and re-run; once or twice I've been unable to do this because the failing module is one I absolutely need. In such cases, I just rerun make-kpkg, cross my fingers, and hope it works this time. Astonishingly, this method sometimes works, which indicates to me that I REALLY don't understand what's going on!. Boot Problems Even when a kernel compiles, sometimes it will not boot properly. Usually this is because some essential options are missing. Listed here are some "showstopper" options which really must be enabled if your kernel is to work: Device Drivers * ATA/ATAPI/MFM/RLL support o Include IDE/ATA-2 DIST support PCI IDE chipset support Generic PCI bus-master DMA support [your IDE chipset!] File Systems * Second Extended fs support (I also say "y" to all further ext2 options) Ext3 journalling file system support (I also say "y" to all further ext3 options) Initrd Support The stock Debian kernels use an "initrd" or "initial Ram Disk" to jumpstart the boot process -- a tiny virutal disk is created in memory, and (as I understand it) a bunch of kernel modules are loaded into that virtual disk. This means that, during the inital boot stages, when the kernel may not be able to locate the root filesystems (where modules are normally stored), the most important modules are nonetheless available. Afterwards those modules can be unloaded. This lets you build a very modular kernel. So usually it's a good idea to build an initrd. Sometimes though it doesn't seem to work -- for instance, I just cannot get software-suspend2-patched kernels to load an initrd (despite howtos on the website). In this case all showstopper modules must be built as integral parts of the kernel, NOT as modules. Also, I often uncheck initrd-related options from the kernel when I make a non-initrd version. I think this is just superstition, though. -------------------------- .''`. Matt Price : :' : Debian User `. `'` & hemi-geek `- -------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
