Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Fri, 8 Oct 1999, Christoph wrote: > I'm trying to build a new kernel for my system and not having much luck. Well, here's my usual process: 1) download a new kernel/patchset. * For a kernel, just do a tar -zxvf linux-xxxxx.tar.gz. This makes a "linux" directory for you. /usr/src is a good place to do this :) * For a patchset, usually 'gunzip <patch> | patch -p0' works, I think. Whenever I forget, I look at the kernel howto. 2) Move into the directory, and do a make clean/make mrproper if it's a patchset. Clean removes all object files, etc., whereas mrproper blows away everything from kernel configuration to the compilation count (look at 'uname -a' sometime...the #xx is a compilation count). 3) Make menuconfig/config/xconfig. I usually am ssh'd in, so menuconfig is kinda nice. But, if you have an X display, xconfig might be nicer. 4) Follow the instructions after config (It says either to 'make clean; make dep' or to 'make dep; make clean'. I can't remember at the moment). *** The rest must be done as root *** 5) make install (bzInstall/zInstall). This usually takes care of all the file locations for you. 6) make modules; make modules_install 7) Look at your /etc/lilo.conf, and make sure it says what you want. Specifically, you should have an entry for your old kernel. If it doesn't, look for the old kernel - it should be in the same directory as the new one. Add a new entry by copying the entry for the current kernel, changing the image path appropriately. If you have to do this, then re-run /sbin/lilo. (install does this for you; if you change it, you have to do it again) 8) Re-boot and be happy:) > System: Intel DK440LX MB with single PII 266 (kernel I'm building > includes SMP) > OS: RedHat 6.0 OK, is there a reason you're using an SMP kernel? Would that be an SMP board? If it's a single board, then SMP is just spare code to eat up your CPU cycles (much like WinNT), and you should probably remove it in a kernel recompile. If it's a dual board with a single processor, then I don't really know what to suggest; has anybody tried a single processor kernel on a setup like that? I can't imagine that really hurting anything... > I don't understand a few key points and can't seem to find adequate > documentation. Here are my questions... How up-to-date is the kernel HOWTO? And have you tried looking under the Documentation directory for the kernel tree? > 1) How do I build a kernel with a new version identifier, such that > when it is working, uname -r will report the new version? > And more importantly, it'll find it's modules in > /lib/modules/[new-version] Once you reboot with a new kernel, it should happen automagically :) uname gets its information from the kernel itself; you can do something similar by catting /proc/version (IIRC). As for the module path, I remember 'back in the day' just using /lib/modules/default, and having an init script check the kernel version at startup, change the symlink to the appropriate real directory, check to see if all the module stuff has been done, and do it if it hasn't. Nowadays I think that RedHat does all that for you. > * Note : I just looked at /etc/rc.d/rc.sysinit and believe the > module path it actually set in there with depmod Ah, so RedHat does do it for you. :) > 2) What is the function of /boot/initrd-xxxxxxxxx? > There exists such a file for the supplied and installed kernel, > but not for my newly built kernel. Where does it come from? That I'm not sure of. I've never seen it before. I do know, however, that initrd is kinda short for init root disk, which is important for making floppies bootable. I'm not sure that you really need it. Oh, and from hat I hear, kucos for not using the kernel upgrade rpms; I hear they are a true pain in the neck. HTH, --Mark - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |