[If you would be so kind as to word wrap your lines at some good column such as 72 it would make your messages much easier to read. Or alternately set format=flowed. Thanks.] Robert Storey wrote: > I'm writing an article about Debian which will be published in a few > days (on a well-known GNU/Linux web site). I'm trying to work out > the best way to recompile a kernel. I don't want to give out an > misinformation, so I need to be sure about the following... You *MUST* read this first then. http://newbiedoc.sourceforge.net/system/kernel-pkg.html > To compile a kernel, I originally thought that all one needed to do (to generate a deb file) was this: > > "make-kpkg clean kernel_imag" Unforunately you cannot include both clean and kernel_image at the same time. Well you can. But it won't have the effect that you are desiring. The kernel_image target will still ask you to run clean if it finds a previous revision already in place. Best to run each separately. make-kpkg clean fakeroot make-kpkg --initrd --append_to_version -k7-1 kernel_image modules_image kernel_headers kernel_doc Most people only need kernel_image and modules_image. But as long as you are at it you might as well make the kernel_headers and kernel_doc packages at the same time. There are times when it is handy to have those and they build quickly. I specified -k7-1 in the above because I have an Athlon and this is the first kernel revision for me for that kernel. Beware of name collisions here. Debian kernels tend to be -1-k7 and so I reversed the order for me. Other people recommend using something completely different to avoid even the small chance of a name collision. Put your name in there if you like. > I walked this past a Debian guru, who sent me this reply: > > I suggest that you get people to use a --revision flag for > make-kpkg and also an > --append-to-version=-<hostname><revision> so that things > will work the way they expect wrt LinuxOLD. If you dont use > --append-to-version and just increment the revision then the > new kernel when you install it will overwrite the current > one and the current one will not become LinuxOLD. You need > to change the version in order for the Linux/LinuxOLD thing > to work as you might expect. > > I'm a little unclear about his syntax. > [...] > So what I'm asking is: what is EXACTLY the best syntax to use. Like > I said, I'm writing an article - readers will rake me over the coals > if I give out information that is ambiguous or unclear in any way. Everyone knows that APT such as 'apt-get upgrade' (or 'aptitude upgrade' or dselect or whatever) is really a strength of Debian. However, you may not want to have kernels offered in this way. Binary driver modules (nVidia, Broadcom, RAID, etc.) need to match the kernel. Just updating the kernel would break those. Users with those addons need to install the kernel-source and rebuild the drivers and install both kernel and drivers together. So kernels are usually specific manual installations that are selected explicitly. The --append-to-version is the way to modify the package name at build time. I don't like your guru's choice of <hostname> there. The hostname does not mean anything to me in terms of a kernel. I care about the type of the kernel. It is the specifics of Pentium4 or an Athlon or SMP or some-kernel-patch such as 'preempt' patches which I need to know in the package name. Because I will use that to select the right kernel for the machine I am installing it on. Look in /boot on your machine. You will usually find at least two images but frequently several named vmlinuz-*. Typically they look like vmlinuz-2.4.20-k7 and vmlinuz-2.4.20-2-k7. If you were to install a second kernel with the same name it would completely replace and overwrite the first. You cannot go and boot the previous kernel. It is gone. If you still have yet a previous kernel then you could boot the still previous kernel. But people expect (I expect!) that you will be able to go back to booting the immediately previous kernel. This is presented to you as options at boot time by either LILO or GRUB. (If you have 'prompt' turned on.) So naming the kernel uniquely is important. You should specify a version here. You can always add that later at -2 if you find that you need to and ignore this otherwise. This is what Debian has been doing. But you should do something different to keep in a different namespace. By convention you should always specify the machine architecture, smp if compiled that way, any patches (e.g. XFS) that you have installed as part of the name. So an Athlon compiled with SMP would be -k7-smp-1 for the first and a P4 would be -686-smp-3 for the third version and so forth. These are just my preferences. Alternately you could happily use the date as the revision with --append-to-version -686-smp-2003-09-11 or other such unique naming. The dpkg tools don't care and the limiter is what you as the admin can tolerate. And as I said they are conventions. You are allowed to have your own. If you never have different architectures then that is not going to be important to you. In that case using just the date code is perhaps a better convention for you. Go with -20030911. There is never a conflict unless and until you interact with others. The only regular interaction is with the debian.org kernels and so you should always be aware possible contention there. I personally build and install on hundreds of machines and so this is a concern for me. The --revision option can be ignored if you are always putting the revision in the --append-to-version option. For most users that is sufficient. But the --revision flag is useful for differences in packaging of the same kernel where binary compatibility is still assured. This allows you to change the packaging, upgrade the kernel, but not need to upgrade any binary kernel modules. If you built a kernel and distributed it but then found that you needed to make another revision of it then using the --revision option is appropriate. And of course so far none of this even mentions external modules or patches. Building those in seemlessly is one of the really sweet things about using make-kpkg. If you have not experienced it then you should give it a trial. I won't be going back to the old ways any time soon. I am hooked. When building kernels you should also set these environment variables. I put these in my ~/.bashrc file. Otherwise the packages will be listed as built by Unknown Kernel Package Maintainer <unknown@unconfigured.in.etc.kernel-pkg.conf> which is downright ugly. See 'man kernel-pkg.conf' for details. export KPKG_MAINTAINER="Your Name Here" export KPKG_EMAIL=you@your.domain Don't forget 'export CONCURRENCY_LEVEL=2' if you have the cpus for it. This can reduce the build time almost linearly for the first two cpus. Hope this helps, Bob
Attachment:
pgpyG_HyZUgfW.pgp
Description: PGP signature