This is great information...my only question is regarding the .config file. When I install from the RH distro. CD, the kernel is built during the installation process, however, there is not a .config file created. I have attempted to build the kernel with the W4L patch, however, without the original .config file, I keep missing components that were discovered at initial install time. I there a way to generate this file once booted?? On Tue, 19 Jun 2001, Phoenyx wrote: > Hi all, > > FWIW, here's my 2 bits on kernel building. I picked up these habits from Red > Hat 4, way back when, and they have never failed me. IMHO, every Linux user > should be able to build their own kernel. At the very least, it speeds up the > Linux boot time. Unfortunately for some, this info is Red Hat/Mandrake > oriented but then, so is Win4Lin. I guess the general feeling is that Debian > and Suze users should be smart enough to adapt these things. :-) > > Most, if not all, distributions are configured to run on as many systems as > possible and leave the optimization and customization to the end user. This > capability is one of main reasons I love using Linux. It is also the bane of > most new Linux users, especially those converts from Windows where > customization is limited and often discouraged. With a proprietary OS like > Windows you will never be able to use the full power of your system. > > I'm sure this project scares many new Linux users since it sounds technical > but it really isn't that bad. I often test various programs against several > versions of the Linux kernel and often wind up patching and/or building > kernels. So often that I even created a simple script to automate the compile > section which I run after the configuration step. > > First and foremost, be prepared. This means keeping the ability to boot the > system no matter what. My method is to keep the original configuration > intact and compile from a modified copy of the source or a completely new > version. I prefer using pristine source from kernel.org (please use a mirror > site :-) ) but you can use the source from the distro if you change the > EXTRAVERSION value in /usr/src/linux/makefile. > > FWIW, I have never needed the 'make clean' step when building a kernel. My > method also ensures that modules will always match the kernel without any > older modules interfering. Keep in mind that the kernel and modules are the > heart of your system and as such deserve the utmost care when building > them. Yes, it requires more time, especially on older hardware but in the > end it will pay off in system stability. > > Another important point when using multiple source versions is keeping the > /usr/src/linux symlink pointing to the correct source tree. I use the Red Hat > aka Mandrake init script /etc/rc.d/rc.local which runs at the end of the > system boot cycle. It only needs a few lines added. > > -- cut here -- > > # get the kernel version, if you want to clean up the script a little, use > # this variable in the console section to replace the uname function > # used there. > v=$(uname -r) > # ensure the source symlink matches the running kernel version > rm -f /usr/src/linux > ln -s /usr/src/linux-$v /usr/src/linux > > -- to here -- > > As mentioned by another user, I also save configurations in a unique file in > case I need to change something. It makes adapting a new kernel a little bit > easier when I only need to change a few settings. Just make sure to verify > all the settings during the initial configuration. Should something not work > and you need to rebuild, follow the same steps and load the settings file > during the make menuconfig (or xconfig) step. > > It should also be mentioned that modules get installed into a directory > which matches the kernel version and this directory should be clean, ie no > existing files. In spite of what some may have heard, it is safer to always > perform a clean build. Especially when the kernel changes are as deep as the > W4L patches are. > > ex: /lib/modules/2.4.3-20.w4l > > FWIW, I prefer to use Midnight Commander (console ver.) which simplifies > copying the kernel source and modifying the /usr/src/linux symlink as well > as editing any files which may need it. IMHO, it is the most versatile > utility I have used in Linux. However, you should use whichever method you > prefer. > > The actual source tree should be in a directory which matches the kernel > version in the makefile. Here is an example listing of the /usr/src > directory. > > /usr/src/.. > ~linux > linux-2.4.3-20mdk > linux-2.4.3-20.w4l > linux-2.2.18.0 > > In this sample, ~linux points to /usr/src/linux-2.4.3-20.w4l To patch the > kernel source, this symlink must exist or the patch will apply to the wrong > source tree. I use a modified W4L patch script which lets me install patches > to various kernel sources using a command similar to the following; > > dopatch w4l > > Where w4l is the name of the patch file and ends with the .patch suffix. > Note, the .patch suffix is not needed in the command line. The patch names > are usually some long and descriptive name which relates to the version. > > -- cut here -- > > # a simple W4L patch script /usr/bin/dopatch > patch -p1 -d /usr/src/linux -b <$1.patch > > -- to here-- > > You should ensure that any patch installs properly. > > Here is the build script I use. > > -- cut here -- > > # build kernel script > # > # this script uses the && to execute the next step only if the current > # one completes properly (as my understanding of it.) and the \ to > # join the lines into one command which is passed to bash. It could > # have been written on a single line but it is easier to read this way. > # > # edit the following line to match the kernel version > a=2.4.3-20.w4l > # > make dep && \ > make bzImage && \ > make modules && \ > rm -Rf /lib/modules/$a && \ > make modules_install && \ > cp -f /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-$a && \ > cp -f /usr/src/linux/System.map /boot/System.map-$a > > -- to here -- > > At this point you should have this configuration or one very similar: > > 1) A system which boots the original setup with matching source tree. > 2) W4L/kernel source in it's own directory tree. > 3) makefile with version info which matches the directory name > 4) build script with matching version info (unless you prefer to enter > the commands yourself :-) ) > 5) modified init which sets the proper symlink > > The only complicated procedure left is the actual kernel configuration which > depends upon the hardware in your computer. > > To recap, assuming you have made the bash scripts, enter these commands to > build your kernel. > > make mrproper > make menuconfig (or xconfig. I prefer the console for this) > ./build > > If the configuration is correct the kernel will compile and the files will > all be in their proper place. Now you are ready for the boot configuration > steps. If this is the first time compile, you will need to add an entry into > your boot loader. Use the existing entries as an example. > > For 'grub' you enter this info in the /boot/grub/menu.lst file. Then save > the file and reboot the computer. > > For 'lilo' you enter it into /etc/lilo.conf and execute the command > /sbin/lilo which rebuilds the boot info. > > If you have been paying attention, you will notice the lack of 'initrd'. I > prefer to avoid using this method unless there is no other alternative. When > booting from lilo or grub with a custom kernel, it is seldom needed. I have > used this method on my server which uses software raid with a Reiser file > system. All that matters is the important pieces are built into the kernel > and not modules. > > One more caveat which applies to any W4L users who overclock their system. > If you are having any problems whatsoever, turn off the overclocking and try > things again. > > Sorry this message is so long but I guess I'm making up for all the time I > spend just reading the digests without contributing. :-) I still miss the > old beta test group. I think many of the problems mentioned here would have > been corrected well before the official release. Unfortunately, NeTraverse > was often maligned by some users and I can't blame them for eliminating > it. As always, IMHO. > > Cheers, > Mike T. > _______________________________________________ > Win4Lin-users mailing list > [EMAIL PROTECTED] > https://lists.netraverse.com/mailman/listinfo/win4lin-users > -- David Frager [EMAIL PROTECTED] _______________________________________________ Win4Lin-users mailing list [EMAIL PROTECTED] https://lists.netraverse.com/mailman/listinfo/win4lin-users
