Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Usually I follow this procedure to recompile a kernel.
cp /boot/config .config
make menuconfig // make my changes
update boot loader and reboot
However, I noticed that after running "make" I see that it is compiling modules. So I took a look at the Makefile and it says it builds modules by default. So obviously we can skip that setup and go straight to "make modules_install" and then "make install"?
Also, sometimes when I recompile a kernel, I get errors at the beginning as the modules are loading saying that the kernel modules are meant for a different kernel. I'm pretty sure this has to do with the name of the kernel not matching up the kernel that the modules were compiled for. The error is "kernel mismatch" I think. So when I do a kernel recompile, where do I specify what new kernel name to use? It's going to be the same kernel version. I just set PREEMPTION to full. Do I even need to recompile the modules? I mean they still get recompiled under "make" by default, but I mean theoretically. In any case to avoid that error, what needs to happen? I'm guessing I need to name the kernel something like 126.96.36.199-smp-preempt? Then the modules will be under /lib/modules/188.8.131.52-smp-preempt? instead of /lib/modules/184.108.40.206-smp? What causes the kernel version mismatch to occur exactly? Where does it check it and how would I fix it?
Also, I'd like some feed back on my first post as well.
Distribution: K/Ubuntu 12.04/14.04, Scientific Linux 6.3/6.4, Android-x86, Pretty much all distros at one point...
If all you are doing is building modules and not compiling them into a kernel, directly, or applying kernel patches, you can usually just use the kernel headers to compile your modules. So, it begs the question of what you are doing... ??? Building kernel modules? Patching a kernel for use with problem hardware? Customizing a kernel for optimal/streamlined hardware use?
Also, there are tools like module-assistant that make your life easier when compiling modules. Also, don't forget that you may have to recompile your backports, and other things, when you (re)compile the kernel. Plus you should make sure you are compiling within the correct kernel tree, etc. All modules must match the kernel version you are running, and many modules are found in other separately installed packages (and need to be updated too). It's usually something stupid, like not being in the right path when compiling that gives you this kind of trouble. Things like DKMS make this less painful than in years past.
I was actually surprised that a RHCE would have this issue, until I looked again at the current requirements. "Back in the day," the RHCE required more hands-on kernel config stuff. But I'm going back to around the 1999-2000 era for that. Back then, we had to config and compile our kernels on install with many distros... That meant intimate knowledge of hardware devices, etc. ... setting the kconfig,... and was a big reason that I didn't jump into using Linux, full time at home, until about 2002... or go for a RHCE cert., myself. I've since forgotten more of this stuff than a lot of typical users know now...
If you are (re-)building a Slackware kernel, you should make sure that installing your new kernel will leave the original kernel modules intact. You do this by changing the local-version part of the kernel's release number to an unique string (under “General setup” > “Local version - append to kernel release”). This kernel option corresponds to CONFIG_LOCALVERSION in your .config file. Slackware sets that value to ”-smp” for a SMP kernel to give you an idea.
The resulting kernel release value (as returned by ”umake -r”) for a kernel version ”220.127.116.11” with a local-version of ”-alien” would be ”18.104.22.168-alien”