Michael Olds wrote: > > Russell, et al, > > Third draft. A couple of questions asked below still remain: > > <!--\*#---------REBUILD KERNEL------------#*\--!> > > References: > read (NOTE: we need a source for these as they are not created on a new > install or by unpacking the kernel-source...and should they be in > /usr/src/linux/ anyway): > /usr/src/linux/Documentation/initrd.txt > /usr/src/linux/Documentation/modules.txt > /usr/src/linux/README > /usr/src/linux/README.Debian
They're in /usr/src/kernel-source-2.4.18, but i have that symlinked to /usr/src/linux. > http://qref.sourceforge.net/Debian/reference/ch-kernel.en.html > This is good for using the make menuconfig method > > http://infocom.cqu.edu.au/Units/aut99/85321/Resources/Print_Resources/Textbo > ok/chap13/ > > http://www.google.com/search?q=%22kernel+headers%22+linus+quote&hl=en&lr=&ie > =UTF-8&start=10&sa=N > > http://www.linuxfromscratch.org/faq/#AEN334 > http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html > > http://www.linuxorbit.com/modules.php?op=modload&name=Sections&file=index&re > q=viewarticle&artid=532 > This is good for using the make xconfig method > > Bear in mind that debian does things a bit differently than other > distros. What is that difference? In essence, in stead of reconfiguring the > kernel and replacing it directly, the reconfigured kernel is made into a > package (.deb) primarily so that the rebuild will remain integrated into the > debian package system so that future updates of the kernel can be made using > dpkg. (I have stated this in these boldly confident terms not being sure > that this is the essence at all...hoping for confirmation or education...mo) > > R: The way that kernel headers are handled on a debian system may be > different to other distros, so clarification would be worthwhile just to > avoid confusion. > > Someone beside me needs to write this section. I am putting this together as > I am learning it as it seems the only way I have motivation enough to help > with some of the documentation gaps in Debian, but this is not to be > understood as a claim to any kind of expertise! haha. I stopped using the kpkg method when i found that the build of another program was using the wrong modules directory in /lib/modules after using the --append_to_version option. It had something to do with the wrong version reported by "uname -a", which may be a bug in the kpkg script, but it was a bit complex for me to figure out. > <---Step-by-Step---> > > [ ]A. Before 1: Download and create a recovery floppy from: > http://www.toms.net/rb/ > > [ ]1.a. Download the latest kernel source package (use a Debian source) to > /usr/src (this is where it will be installed if you use dselect, a package > manager, synaptic or aptitude). Best practices seem to indicate that the > package be built outside of /usr/src so creating a sym-link from /linux to > /usr/src/kernel~ as in step 1.d below seems to be the way to handle this. I've been doing the build in /usr/src, and it works ok. I don't think it matters on the debian system. Anyone know any different? Doing it in /root or /usr/local/src would be ok, because debian policy puts these outside the debian management system (iirc). > This way, you can have multiple source trees in /usr/src and just change the > /usr/src/linux symlink to the new tree.) > [ ]1.b. if no /usr/src/linux dir exists, make it > $ cd /usr/src > $ mkdir linux no. Just do cd /usr/src > [ ]1.c. change directory to /usr/src and unpack the source package -- use > the unpacking tools with your file manager, or: > $ su #enter root password > # cd /usr/src > # tar --bzip2 -xvf kernel-source-2.4.18.tar.bz2 (or latest) # tar -xvzf kernel-source-2.4.18.tar.bz2 (or latest) > [ ]1.d create a symbolic link to /usr/src/linux > # ln -s /usr/src/kernel-source-2.4.18 /usr/src/linux > > [ ]2. Just to be professional: go to "/etc/kernel.pkg.conf" and modify the > file by inserting your "Kernel Source Maintainer Name" and e-mail address. > > [ ]3. Make sure > [ ]"expectk" if you want to use the user friendly: make xconfig > [ ]"debhelper" > [ ]"modutils" > [ ]"libncurses5-dev" > [ ]"bin86" > [ ]"libc6-dev" > [ ]"debianutils" > [ ]"make" > [ ]"bzip2" and > [ ]"kernel-package" are installed. > R Notes: don't use gcc 3.x, but something like gcc 2.95. > Which I do not understand. Clarification? Don't know the specifics, but gcc 3.x isn't as thoughroughly tested on kernels, and the kernel may have compiler-dependent optimizations. > ================================================================== > REMOVING THIS STEP: This step breaks make xconfig for people who want to go > that way. > The Sourceforge method states: One can avoid rm -rf */pcmcia by > selecting "General setup -->" to "PCMCIA/CardBus support -->" in make > menuconfig and setting the configuration to "< > PCMCIA/CardBus support" > (i.e., uncheck the box). Which I will keep in the NOTES section > > [ ]4. Remove PCMCIA support if not needed > > $ cd /usr/src/kernel-source-2.4.18 # if this is your kernel source > $ rm -rf */pcmcia I think this is unnecessary and asking for more problems. I haven't needed to do it. Just make sure you deselect the option in menuconfig. > # [OPTIONAL] if one wants to use modules from pcmcia-cs or no > pcmcia (see NOTES below) > > ==================================================================== > > [ ]5. (on 2nd and subsequent rebuilds) Copy old configuration file to > /usr/src/kernel-source-2.4.18 > $ cd /usr/src/kernel-source-2.4.18 > $ cp /boot/config-2.4.18-386 .config # get current config as > default > > R: notes (and the Sorceforge docs confirm) that this is not necessary as the > script will pick up the oldconfig)...eliminating this step. > ========================================================================== > > [ ]6. # cd to /usr/src/linux > > $ make menuconfig or make xconfig > > and make your selections > > To do this you need to have some familiarity with your hardware and what > you are intending to use the system for. This you need to work out yourself. > Once this is figured out, it might be helpful, on the first rebuild, to make > your updates with reference to the original configuration, (called > config-2.4.18bf24 (or your kernel version)) which you should find under > /root using the "M" (module) option where a module was used and building the > feature into the kernel (*) or [y] option where it was built into the > kernel. Use the HELP option for brief explanations. This at least until you > understand which can be safely changed under your setup. > > Note: If you're using --initrd, make sure "Compressed ROM file system > support" is built in, or you'll get a kernel panic (need CramFS). > > (Side note: I see that answers my question about how to get it in > there...sorry!) > > [ ]5.a. [ ]# make-kpkg clean > [ ]# make-kpkg -revision=<!--insert your own personal rebuild > version number here: i.e.: -revision=0001) --initrd kernel_image (see NOTES > below: do not use if you do not use). > > Note: If you don't want "--initrd" leave out that option, and make > sure /etc/lilo.conf doesn't have it either for that build. Conversely, if > you do want it, make sure to add an 'initrd=/initrd.img' line to the > image=/vmlinuz stanza of your /etc/lilo.conf and be sure to run # lilo -a > after. > > [ ]6. A new kernel.version-0001_i386.deb will be placed in the /usr/src > directory > > [ ]7. Install the new kernel using # dpkg -i kernel.~.deb > kernel-image-2.4.18_mydomain.0001_i386.deb > > [ ]8. Reboot > > <---Notes---> > > NOTES: make-kpkg kernel_image actually does make oldconfig and make dep. Do > not use --initrd if initrd is not used. The current Debian initrd boot > script requires a cramfs kernel patch, if you obtain kernel source from > non-Debian archives; see http://bugs.debian.org/149236. > > On an SMP machine, set CONCURRENCY_LEVEL according to kernel-pkg.conf(5). > > Next mini: how to recover when nothing said here works. > > <!--\*#------------------------------#*\--!> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
