Kernel Compile help
 

Hello. I 'm using slackware 12 and i want to complie a new kernel. I dont have idea how to so i am looking for some full instructions that will help me to compile. I found this link but i dont know if somethings has change.so if u have a better guide feel free to post it:) i dont want to mess up my system again :cry:

It's an excellent guide, and you can use it with a new version of kernel.
The only difference is, you won't be able to get a complete config file to start with. Which kernel are you compiling?

Download Linux Kernel In A Nutshell. It really helped me.
Regards,
Bill

Hi,

Welcome to Slackware!

The link you provided is a good guide but I prefer Alien_Bob's 'Building a Linux Kernel from source'. A good wiki.

This link and others are available from 'Slackware-Links' .

I have to disagree with the instructions in that link. Read the README file located in /usr/src/linux/README, and this book mentioned below, and you will find the discrepancies.

The Linux Kernel in a Nutshell book is correct, and I agree with TSquaredF -- it's very good. It's author, Greg Kroah-Hartman, is a present Linux kernel developer. The author of that guide you posted is not. I recommend that you download this book, study it before, and use it as you recompile your kernel.

Read and follow the directions of the README file that comes with the kernel source ... located in ./linux-x.x.x/README after you unpack the new source. It is really very simple to build, configure, and install a kernel from the normal users home directory.

Here's my very simple kernel rebuild guide that works, and I'm going to do just this on a fresh install of Slackware-12.0 on my test box as I type for you ...

Download the latest stable kernel source (2.6.24) from the mirror nearest you. As per Linus Torvalds, and Greg Kroah-Hartman's, instructions make a directory somewhere under your /home/<username> directory to build the kernel. I use /home/mingdao/kernel/ -- you can create it while in your home directory just issue "mkdir kernel". The move your kernel source to there ... i.e., "mv linux-2.6.24.tar.bz2 kernel/" from wherever you downloaded the source. Then change to that directory with "cd kernel/" and untar the source by issuing "tar xvjf linux-2.6.24.tar.bz2". Then change to that directory by issuing "cd linux-2.6.24" You can start with the kernel .config file you're using in your present Slackware kernel. Now that you're in the directory for your kernel source, just issue "cp /boot/config .config" and you will copy the config file from your present kernel into that directory as .config. Now the easiest way to go from here IMO, if you've never rebuilt a kernel, is to issue "make xconfig".

That's going to give you a nice looking GUI where the options and information about them can be easily seen. Since you have used the .config file from your present working kernel, everything you have working in your system will be there. This is the point where you want to use the information in the Linux Kernel in a Nutshell book.

NB: Building your kernel this way, and under the user's home directory, you can keep running your system with nothing to worry about. You don't start X as root or anything and you're not going to even use root until you INSTALL the kernel. That's the only time you'll need root privileges.

After you finish making your choices for the new kernel, save that file from the menu, then close the xconfig window. Now, still as a normal user, issue "make" -- that will take some time. After it finishes, you need to su to root. Issue "su" and then enter root's password. You should still be in the /home/mingdao/kernel/linux-2.6.24/ directory (except your username and not mingdao). Now you have just a few steps to do as root. First, issue "cp System.map /boot/System.map-2.6.24 ; ln -sf /boot/System.map-2.6.24 /boot/System.map" to copy the System.map file to /boot as System.map-kernel-version and update the /boot/System.map symlink. Then issue "make modules_install" to install the modules. Now copy the kernel itself to /boot under some new name, like so: "cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.24"
NB: In the configuring of your kernel, if you include support for your root filesystem and hard disk controller as built-in (Y or a check mark), rather than as a module (M or a dot), then you don't need an initrd image. If you have the support for your root filesystem or controller as a module, you should also build an initial ram disk image (initrd). To do this, change to the /boot directory by issuing "cd /boot" and follow the instructions in the file "README.initrd" before proceeding to the next step.

You have now configured, built, and installed you new Linux kernel. Now you need to edit the bootloader so it will be available when you reboot. Use the editor of your choice -- mine is vim. Replace vim with your editor, and issue "vim /etc/lilo.conf" and add the following lines:
just after the very first line which reads "# Linux bootable partition config begins" ...
NB: You must replace sda6 with the partition of your root filesystem. It will already be there in your /etc/lilo.conf from the default install.

One more thing we must do to finish ... we must issue "lilo" to reinstall the bootloader.

Now you should be able to reboot and select either your old kernel or the new kernel, so if the one you just built won't boot, you can boot into your old kernel and fix whatever is wrong with your new kernel. Always keep a working kernel in place. It doesn't neccessarily have to be the kernel you installed with, but that one is always left in place on my systems. I think it's good practice, because it's using the original kernel headers and glibc your system was built with.

This was followed, copying and pasting, to recompile a kernel for my test system. Here's some info:
Another "gotcha" to prepare for ... if you use the Nvidia driver, you'll have to reinstall it when you boot into your new kernel. So keep it under /home or somewhere you'll have it available.

If you ever want to work with kernel sources that are already installed under /usr/src you can do this as a normal user, but you need to specify some more args during the build process.

Here's an exert from the kernel README
I usually do this when I create new kernels images based upon the kernel version Slackware is installed with. For newer kernel versions, however, I often just put it under a folder in my users home directory (as has been described above).

When using a .config from an older kernel version I usually make oldconfig. I am not completely sure if it is necessary (someone please verify this), but I was always under the impression that it was a good idea if using a .config from a much older kernel version.

I prefer using make menuconfig for configuring kernels.

If you are changing kernel versions you should run "make oldconfig" in order to add new options for the new kernel to your old .config.

Brian

The latest stable kernel.Tnx guys for help i will try to compile so may the force be with me:cool:

Originally posted by shadowsnipes
That is correct. However, in my kernel rebuild guide I never do this, because I never rebuild a kernel with the old Slackware source code. I always use the latest stable kernel, and that's never in the past been the one in a stable Slackware release. Also, there is no need for me to have the new kernel source code in /usr/src/linux-2.6.N.

Originally posted by shadowsnipes
To verify for you, it is not necessary to use "make oldconfig" with an old kernel config file to get the new kernel options (but do NOT use a 2.4 or previous version config file with 2.6 sources). You must run something other than "make config" to use it, but there are many choices listed in the README file of the kernel source. Running "make xconfig" will have the new options since your previous config listed with (NEW), as will "make menuconfig". Since someone who hasn't tested this will obviously question it, here are two things for you to read and compare.

First, from the kernel source README file:
It does not say the old options will not be available -- it says it will be minimal work because it will only ask you for the answers to new questions -- which presupposes that the old questions are already answered. If you read the MAKEFILE in the kernel source you will see how they've done this.

Second, using my 2.6.13.4 kernel config file on my laptop from Oct 10, 2005, I ran "make xconfig" and "make oldconfig" and "make menuconfig" on fresh 2.6.24 source. I did not change any options on them, and saved them so that you can diff the files. They are ALL exactly the same, and have all the options you'd get if you ran "make config" and generated and entirely new .config file. Here are those three files for you to diff:
You will notice that nothing is different in those three files except the date.

If I were going to use something other than the X windows based options, it would be preferable to use "make silentoldconfig".

I particularly like the X windows based options because they give you a screen with all the kernel options and their associated HELP on the same screen. There's no need to get help by pressing "Shift+?" like you have to do with all the text based make options. My preference is also xconfig rather than gconfig because it's laid out better and looks nicer (IMO).

please backup your reproof
 

Originally posted by BCarey
Please see my above post #9. You should check this for yourself on your own system, to find out you don't have to use "make oldconfig" to get the new options. You can use "make xconfig" as I previously stated, and have done for quite some time now.

If you see something in my guide or post that is incorrect, please supply some evidence to back up your supposition.

This makes sense to me. I remember one time where I ran make oldconfig and got interrupted during the long process of selecting choices for the NEW updates. Later I forgot that I hadn't finished it and instead ran make menuconfig. I remember seeing a 'NEW' next to certain options.

Thanks for verifying this. For some reason I had had this belief that make oldconfig not only just shows you the new options, but also reorganizes the config file in a certain way so that it still works. Apparently, others must do this as well.

What would be really nice is if menuconfig and xconfig made the new options stand out even more. Maybe if there was an option to have all the old config options grayed out it would be even easier to quickly scan for new options. Alternatively, or in addition, there could be a separate section for just the NEW config options.

Originally posted by shadowsnipes:
Check the kernel source README file for the 11 options ... that's the purpose of "make silentoldconfig":
Really, reading is A Good Thing (TM) that we don't do enough ...

That's not quite the same thing as I was asking for because both of those ask you want you want one by one. That's like saying make menuconfig is like make config.

Sorry, I thought you wanted it to skip the options you'd selected before. That's what it does. Look at this:
That's how efficient it is ... it only outputs the selections that are NEW since the previous .config file that I used. In this example, since I already configed 2.6.24 with that .config file, it returned with nothing.

Maybe you just wanted the ncurses (is that what menuconfig is) or X windows menus? Any time you want to run those "make ?config" options you can do so, check what they do, and don't save the file. You'll have your old .config file just as it was. But in the event that you forget and save after running it, no problem ... there will be both .config and .config.old in that directory.

The big difference with menuconfig and xconfig versus the plain config/oldconfig/silentoldconfig is that with the first two you can look at groups of stuff and in particular look at things in a non-linear fashion. I'm sure most people reading this are thinking "thanks, Captain Obvious", but the point is that it would be nice to have the old config options grayed out (a toggle-able feature, mind you) so the NEW options stand out more. That way it is easier to see how they fit into the groups. In addition, it would be nice to have a "group"/tab/whatever where you see only the NEW options. All of this is only useful in the context of an interface that allows you to change/view config settings in a non-linear fashion. Otherwise, yes, silentoldconfig is the way to go. Personally, I dislike the vanilla config and oldconfig because I don't typically configure a kernel in a completely linear fashion. Sometimes I even change my mind about things during the process...

I hope that clarified what I was going for.