Compiling a Vanilla Kernel
Someone asked for directions for compiling a 'vanilla' kernel from kernel.org. Below are some notes on how to do that.... Feel free to shoot holes in it. I download the kernel files to a directory named '/ftparea' so the following instruction will use that in the examples. I would think that the module-init-tools that come with 9.1 would be the latest because the tools haven't changed in quite awhile. But remember that whenever you go to grab a new kernel from kernel.org, that you should check to see if there is a newer version of module-init-tools in: kernel.org/pub/linux/utils/kernel/module-init-tools/ The latest module-init-tools is: module-init-tools-3.0.tar.gz Assuming you have downloaded: linux-2.6.6.tar.bz2 KERNEL 1) cd /usr/src 2) rm -r linux (removes sym link to current kernel source but does not erase the main directory) 3) tar xjvf /ftparea/linux-2.6.6.tar.bz2 (extract the new kernel source into /usr/src/ 4) ln -s linux-2.6.6/ linux (make a new symlink) 5) cd linux 6) make mrproper Note: Make mrproper should be issued just once, immediately after you load up the new source files. make mrproper will do some setup but it WILL ALSO GIVE YOU A DEFAULT .config file. The .config file is your configuration file. Since you are going to be making changes to the .config, you don't want to lose those changes later on after spending a lot of time configuring your kernel. 7) make xconfig (see notes below) 8) *** Not used for 2.6.x kernels but does no harm. make dep 9) make clean 10) make bzImage (note the capital 'I') 11) Assuming no errors, make modules 12) Assuming no errors, make modules_install 13) cp -p arch/i386/boot/bzImage /boot/vmlinuz.266 14) Modify /boot/grub/menu.lst a) copy your current kernel line(s) to a new group and modify with the name of the new kernel (vmlinuz.266) b) Remove the entry for mkinitrd if you compile everything needed at boot time into the kernel (best). Otherwise make a new initrd file for the new kernel and name it properly. (mk_initrd) 15) Re-boot That's it! At this point (after 15 above) you would have: 1) A new kernel for 2.6.6 in /boot which is separate from your current kernel (use uname -r to see the name of any running kernel) 2) A new entry in /boot/grub/menu.lst that is separate from your current boot entry. 3) A set of modules that are totally separate from your current modules. (see /lib/modules) In otherwords, everything is separate! and you can always reboot to the original (current) kernel. Nothing has been destroyed. Play to your hearts content. Now for a few additional notes: (you knew that was coming, didn't you :o) Note: All of the above assumes you have the needed parts to do a kernel compile such as the gcc compiler. You may have to load things that have been missed. Step (8) make xconfig The above assumes you are running under KDE or some gui interface. If not, use: make config or make menuconfig for text mode. (there are other ways of setting up a .config) If you get an error about a display not being available while running as root in a term console, go back to being a normal user and issue 'xhost +' and then go back as root and continue where you left off. Now... you can always bring over a .config file from a previously compiled kernel (such as 2.6.5 if you had compiled for that) but in the case of using the stock SuSE kernels, I would suggest that you branch off and start fresh. The SuSE kernel has almost every bell and whistle turned on since they don't know what hardware will be running. There is a way to bring over an SuSE .config called cloneconfig but I've never used it. In fact, I have to admit that I have never done anything with the SuSE versions of kernels but feel that I have avoided a LOT of problems because of that. The make xconfig will present you with a LOT of options, many of which you won't know anything about, but there will always be a HELP button or information to click on which will explain the option. (the explanation will sometimes go over your head too but they usually give a 'best option' suggestion such as "if you don't know whether you want the hydradublicab option, say No here") Plan on spending some time with the xconfig but you will learn a LOT about linux in the process. Modules: It is good in almost all cases to check off any options you want as 'modules' rather than have them compiled in if there is a modules option. The one exception to this rule is for hardware items that are needed at boot time. For example, compile in the drivers needed for your HD's and your eth0 interface (if any). Compile in ANYTHING needed at boot time since (a) then you won't have to worry at all about INITRD problems and b) there's no sense in making them modules anyway since they would get loaded right off and stay loaded forever. (see /etc/sysconfig/kernel and the label INITRD_MODULES for those things currently in mkinitrd. Best to compile them into the kernel) But for most options, there's no harm in making things modules and in fact, there may be options you're not sure you want but if they are made as modules, they really don't cost you anything in storage or performance if they are not used, yet they are there to use if/when you wish. Your hardest item in the above lists will be making up the .config, but once you've made it up (about a 1/2 hour) you're pretty well covered for ever. You can bring forth any .config file for new kernels and you will by then know enough about the .config process that it won't take long to start from scratch. It may take you a couple of tries to find the right option mix. In general this is not a problem, but it *is* possible to pick an option that might conflict with another and cause a compilation error or have some hardware that isn't picked up properly. You will lose your graphical boot screen (the initial one where all the boot messages fly by) when you use a vanilla kernel. Some people think this is a big loss but then, if you boot that often, maybe you have bigger problems. :o) There are supposed to be some patches on the SuSE site to put it back if you really have to have it. I didn't mention how to add a new boot item to lilo. I don't use lilo but basically you take your current boot-definition such as: image = /boot/vmlinuz label = linux root = /dev/sda6 initrd = /boot/initrd append = "enableapic" and duplicate it with a new label and new image: image = /boot/vmlinuz.266 label = linux-2.6.6 root = /dev/sda6 # initrd = /boot/initrd append = "enableapic" Note that I have commented out the initrd. That assumes you have compiled the necessary drivers into the kernel as I described. Take a look in /etc/sysconfig/kernel for the line: INITRD_MODULES="aic7xxx scsi_mod xfs" for the modules which are needed at boot time. These are the drivers that should be compiled into the kernel. Questions?
On Sunday 23 May 2004 17.50, Bruce Marshall wrote:
2) rm -r linux (removes sym link to current kernel source but does not erase the main directory)
3) tar xjvf /ftparea/linux-2.6.6.tar.bz2 (extract the new kernel source into /usr/src/
4) ln -s linux-2.6.6/ linux (make a new symlink)
No no no. /usr/src/linux should be reserved for the kernel source/headers used to compile glibc, not for the kernel du jour (Linus Torvalds). You can put the kernel sources you're compiling anywhere, I put them in $HOME/src/
5) cd linux
6) make mrproper
Note: Make mrproper should be issued just once, immediately after you load up the new source files. make mrproper will do some setup but it WILL ALSO GIVE YOU A DEFAULT .config file.
It does? Where? I can't see one
The .config file is your configuration file. Since you are going to be making changes to the .config, you don't want to lose those changes later on after spending a lot of time configuring your kernel.
7) make xconfig (see notes below)
7.5) Edit the top-level makefile and set EXTRAVERSION to something identifiable, to distinguish this build attempt from others
The above assumes you are running under KDE or some gui interface. If not, use: make config or make menuconfig for text mode. (there are other ways of setting up a .config) If you get an error about a display not being available while running as root in a term console, go back to being a normal user and issue 'xhost +' and then go back as root and continue where you left off.
Argh! You know better than that Use 'sux' or 'kdesu'
On Sunday 23 May 2004 12:02 pm, Anders Johansson wrote:
On Sunday 23 May 2004 17.50, Bruce Marshall wrote:
2) rm -r linux (removes sym link to current kernel source but does not erase the main directory)
3) tar xjvf /ftparea/linux-2.6.6.tar.bz2 (extract the new kernel source into /usr/src/
4) ln -s linux-2.6.6/ linux (make a new symlink)
No no no. /usr/src/linux should be reserved for the kernel source/headers used to compile glibc, not for the kernel du jour (Linus Torvalds).
You can put the kernel sources you're compiling anywhere, I put them in $HOME/src/
Put them where you want, but I disagree with your statements. The above seems very standard to me and I've never had a problem with it. It would be a minor nit in my view.
5) cd linux
6) make mrproper
Note: Make mrproper should be issued just once, immediately after you load up the new source files. make mrproper will do some setup but it WILL ALSO GIVE YOU A DEFAULT .config file.
It does? Where? I can't see one
Ok... a misconception. It DELETES your .config which will give you a default .config next time you to go make config changes. Same difference.
The .config file is your configuration file. Since you are going to be making changes to the .config, you don't want to lose those changes later on after spending a lot of time configuring your kernel.
7) make xconfig (see notes below)
7.5) Edit the top-level makefile and set EXTRAVERSION to something identifiable, to distinguish this build attempt from others
If you want.
The above assumes you are running under KDE or some gui interface. If not, use: make config or make menuconfig for text mode. (there are other ways of setting up a .config) If you get an error about a display not being available while running as root in a term console, go back to being a normal user and issue 'xhost +' and then go back as root and continue where you left off.
Argh! You know better than that
Use 'sux' or 'kdesu'
I knew I would get hit when I saw that. This is an old writeup which I modified. Yes, 'sux' is what I use now. -- +----------------------------------------------------------------------------+ + Bruce S. Marshall bmarsh@bmarsh.com Bellaire, MI 05/23/04 12:08 + +----------------------------------------------------------------------------+ "Health nuts are going to feel stupid someday, lying in hospitals dying of nothing."
On Sunday 23 May 2004 18.15, Anders Johansson wrote:
On Sunday 23 May 2004 18.13, Bruce Marshall wrote:
Put them where you want, but I disagree with your statements.
It's not mine. I didn't put (Linus Torvalds) in there for the hell of it. It's simply not the way it's meant to be
http://www.linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html
On Sunday 23 May 2004 5:24 pm, Anders Johansson wrote:
On Sunday 23 May 2004 18.15, Anders Johansson wrote:
On Sunday 23 May 2004 18.13, Bruce Marshall wrote:
Put them where you want, but I disagree with your statements.
It's not mine. I didn't put (Linus Torvalds) in there for the hell of it. It's simply not the way it's meant to be
http://www.linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html
Having read the reference, I agree with the argument. But section 10.2 of the Administrators Guide for 9.1 argues that the -/linux directory should be a symlink to the current kernel and says YaST should do this for you. I am a tad confused by this. If I do my own kernel, in the -/linuxMyWay directory, I actually use headers from the -/linux directory? This seems fine for linking library functions, but for linking concurrently compiled kernel modules, this seems wrong. Are we actually talking here about the difference between #include <SomeLibraryHeader> and #include "SomeConcurrentlyCompiledModuleHeader"? I am not so far into kernel hacking yet, but my Long Delay before Kernel Boots problem is forcing the matter, and this discussion seems to be providing some possible answers as to why I can't compile kernel.org kernels before 2.6.4 on 9.1. Vince
On Sunday 23 May 2004 22.27, Vince Littler wrote:
Having read the reference, I agree with the argument. But section 10.2 of the Administrators Guide for 9.1 argues that the -/linux directory should be a symlink to the current kernel and says YaST should do this for you.
I see that. That only proves that even suse can be wrong
I am a tad confused by this. If I do my own kernel, in the -/linuxMyWay directory, I actually use headers from the -/linux directory?
No, not at all. When you compile a kernel in directory /foo, you use include files from /foo/include
This seems fine for linking library functions, but for linking concurrently compiled kernel modules, this seems wrong.
Are we actually talking here about the difference between #include <SomeLibraryHeader> and #include "SomeConcurrentlyCompiledModuleHeader"?
The kernel doesn't use 'normal' include files. It compiles with (among other things) the gcc flag -nostdinc. Everything it uses comes from the kernel directory
I am not so far into kernel hacking yet, but my Long Delay before Kernel Boots problem is forcing the matter, and this discussion seems to be providing some possible answers as to why I can't compile kernel.org kernels before 2.6.4 on 9.1.
I haven't tried. 9.1 uses some kind of version of gcc 3.3 with several features in it that have been back ported from 3.4. gcc 3.4 changed a few things that broke several apps, for example mplayer had to be updated to compile with 3.4, so it is possible that earlier kernels just aren't compatible with gcc 3.4
Anders Johansson wrote:
On Sunday 23 May 2004 18.13, Bruce Marshall wrote:
Put them where you want, but I disagree with your statements.
It's not mine. I didn't put (Linus Torvalds) in there for the hell of it. It's simply not the way it's meant to be
I put mine in /usr/src, e.g linux-2.6.6-mm5, there doesn't even need to be a /usr/src/linux, I don't have one. When the kernel is built, it knows exact;ly where its header files reside, I suppose you could build it in /dog for all the difference it makes, except some packages that need the kernel headers will be hard coded to look in /usr/src/linux - easily modded. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer Linux Only Shop.
On Sunday 23 May 2004 17:02, Anders Johansson wrote:
On Sunday 23 May 2004 17.50, Bruce Marshall wrote:
2) rm -r linux (removes sym link to current kernel source but does not erase the main directory)
3) tar xjvf /ftparea/linux-2.6.6.tar.bz2 (extract the new kernel source into /usr/src/
4) ln -s linux-2.6.6/ linux (make a new symlink)
No no no. /usr/src/linux should be reserved for the kernel source/headers used to compile glibc, not for the kernel du jour (Linus Torvalds).
You can put the kernel sources you're compiling anywhere, I put them in $HOME/src/
you gotta be joking kernel automatically goes to /usr/src/ linux****** when you unpackit so where do you get this strange malformed idea from ?. Duh
5) cd linux
6) make mrproper
Note: Make mrproper should be issued just once, immediately after you load up the new source files. make mrproper will do some setup but it WILL ALSO GIVE YOU A DEFAULT .config file.
It does? Where? I can't see one
The .config file is your configuration file. Since you are going to be making changes to the .config, you don't want to lose those changes later on after spending a lot of time configuring your kernel.
7) make xconfig (see notes below)
7.5) Edit the top-level makefile and set EXTRAVERSION to something identifiable, to distinguish this build attempt from others
The above assumes you are running under KDE or some gui interface. If not, use: make config or make menuconfig for text mode. (there are other ways of setting up a .config) If you get an error about a display not being available while running as root in a term console, go back to being a normal user and issue 'xhost +' and then go back as root and continue where you left off.
Argh! You know better than that
Use 'sux' or 'kdesu'
i got one thing ot say about that YUK! so many problems trying that way permissions go T**s up every time -- G6NJR Pete otherwise known as "Quinton 11" A Linux Only area Happy bug hunting M$ clan Pete,,,,, :-)
[sorry Peter, meant to reply to list] On Monday 24 May 2004 9:55 am, peter Nikolic wrote:
On Sunday 23 May 2004 17:02, Anders Johansson wrote:
On Sunday 23 May 2004 17.50, Bruce Marshall wrote:
2) rm -r linux (removes sym link to current kernel source but does not erase the main directory)
3) tar xjvf /ftparea/linux-2.6.6.tar.bz2 (extract the new kernel source into /usr/src/
4) ln -s linux-2.6.6/ linux (make a new symlink)
No no no. /usr/src/linux should be reserved for the kernel source/headers used to compile glibc, not for the kernel du jour (Linus Torvalds).
You can put the kernel sources you're compiling anywhere, I put them in $HOME/src/
you gotta be joking kernel automatically goes to /usr/src/ linux****** when you unpackit so where do you get this strange malformed idea from ?. Duh
Having followed the rest of this thread, that might be what happens, but it is not necessarily right. About 5 minutes before your post arrived, I right clicked on linux-2.6.2.tar.bz2 in Konqueror, selected "extract to..." and extracted to ~/home/vince/kernel and compiled. What's more, I did this under 9.0, I want to try the kernel for running 9.1, which won't compile it and I don't want to touch my 9.0 setup, where I am very happy with my 2.4 kernel. And I get a clean compile, and I know that doing it not as root, I can't touch anything. Malformed idea? Duh? Anders' link to Linus' email explains. It is sound. Vince
peter Nikolic wrote:
On Sunday 23 May 2004 17:02, Anders Johansson wrote:
On Sunday 23 May 2004 17.50, Bruce Marshall wrote:
2) rm -r linux (removes sym link to current kernel source but does not erase the main directory)
3) tar xjvf /ftparea/linux-2.6.6.tar.bz2 (extract the new kernel source into /usr/src/
4) ln -s linux-2.6.6/ linux (make a new symlink)
No no no. /usr/src/linux should be reserved for the kernel source/headers used to compile glibc, not for the kernel du jour (Linus Torvalds).
You can put the kernel sources you're compiling anywhere, I put them in $HOME/src/
you gotta be joking kernel automatically goes to /usr/src/ linux****** when you unpackit so where do you get this strange
Check with "tar jxfv linux-2.6.6.tar.bz2", you will see that /usr/src/ doesn't figure in it, although I do it in /usr/src, the /usr/src/linux link isn't really necessary, I don't have it and I build every -mm kernel that comes out, most packages you build will either detect where your running kernel sources are, e.g nvidia video driver or ask you to supply it --- linux-2.6.6/ linux-2.6.6/arch/ linux-2.6.6/arch/i386/ linux-2.6.6/arch/i386/kernel/ linux-2.6.6/arch/i386/kernel/process.c linux-2.6.6/arch/i386/kernel/vsyscall.S linux-2.6.6/arch/i386/kernel/cpu/
malformed idea from ?. Duh
5) cd linux
6) make mrproper
Note: Make mrproper should be issued just once, immediately after you load up the new source files. make mrproper will do some setup but it WILL ALSO GIVE YOU A DEFAULT .config file.
It does? Where? I can't see one
The .config file is your configuration file. Since you are going to be making changes to the .config, you don't want to lose those changes later on after spending a lot of time configuring your kernel.
7) make xconfig (see notes below)
You can copy your current .config over and make oldconfig, make ?config or whatever, make mrproper is only rarely needed, I haven't needed mrproper in years, make clean is good enough.
7.5) Edit the top-level makefile and set EXTRAVERSION to something identifiable, to distinguish this build attempt from others
The above assumes you are running under KDE or some gui interface. If not, use: make config or make menuconfig for text mode. (there are other ways of setting up a .config) If you get an error about a display not being available while running as root in a term console, go back to being a normal user and issue 'xhost +' and then go back as root and continue where you left off.
Argh! You know better than that
Use 'sux' or 'kdesu'
i got one thing ot say about that YUK! so many problems trying that way permissions go T**s up every time
It's a bone simple operation, the README in the kernel sources is good enough, the only point I disagree with is the EXTRA CAUTIOUS "make mrproper", I guess it's there if one is building the kernel without experience and makes sure a newbie doesn't get into a pickle when you upgrade the same kernel directory multiple times and the hardware possibly has changed. Even rebuilding the kernel when moving the HD from one laptop to another with completely different hardware, "make mrproper" wasn't needed. It used to be needed at times with up to 2.2 kernels. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer Linux Only Shop.
participants (5)
-
Anders Johansson -
Bruce Marshall -
peter Nikolic -
Sid Boyce -
Vince Littler