Why make kernel compiling so confusing?
 

I was reading tons trying to get an idea since this was going to be my first kernel compiling/upgrading. Why do people make it such a task to try and figure out? Are there added benefits to doing it other then the way I did below?

I edited the .config file with make menuconfig.
Compiled the kernel make
Then set the new kernel make install
The biggest part was going through the config menus trimming off what I did not need. Finally adding a GRUB boot selection in menu.lst for the new kernel.

Thanks,
Kyle

Which people? There are more than a billion ways to do it other than the way you do it and each way has its benefits.
For example, some people patch the kernel because they want to add a functionality that is not present in the default vanilla one. Some other people may want to use a script like genkernel, because it's quicker. So what are you talking about exactly?

There are some .config in your current linux under /boot/
I usually copy .config and extend from there.

Yeah the patching was the next thing I was going to check out. Right now I just did a basic 2.6.25 kernel and will attempt to add the .6 patch. What I was going on about is you do a google search, read forums, do what ever and no one just said how to do a basic upgrade of a kernel. I was just really surprised it was as simple as a normal compiling and installing of another application.

I guess the whole "kernel compiling is difficult" mind set and things people say made me expect something more and go on a wild search for what was not there.

I'm glad I finally figured it out and stopped the search. :-)

The setup I have is a basic debian install so the config is not fully configured. I probably could have saved some time by going though its .config instead of a new one.

Kyle

The advantages of having packages rather than files here and there that you forget to remove when uninstalling, handling versions,..

I always start with "make oldconfig" before "make menuconfig" to start with the the options of the current running kernel. If you are compiling a newer version, you will be prompted for any newer features. Some options I might leave alone simply because I don't understand an item well enough.

Well you listed two ways, could you please list the other 999,999,998 ways for us. :D :D

There are lots of sites that go over a basic upgrade/compiling of a kernel. It is just a little bit complicated to go over one, because you know SOMEONE is going to follow the "basic" upgrade and take it as 100% and end up compiling their kernel with an unknown config most likely for a kernel version they are most likely not using. If that makes any sense.

DragonM15

Now that makes sense to have a cleaner way of doing it. Guess either have the latest kernel or the latest kernel package(which might be a few kernels back). Am I correct thinking this way?

Thats what I thought oldconfig did but was not sure since I just did a standard install and never really configured the kernel before. From now on I will. :-)



Sorry you kind of lost me on that... you mean they compiling 2.6.25 from a .config that was setup for say 2.6.18? If thats what you mean I guess I understood lol other wise, I probably am just like everyone your talking about. ;-)

Thanks for the replies,
Kyle

Yeah, that was exactly what I meant. Sorry, I'm kinda tired.

DragonM15

Ok glad to clear that up. :-) thanks for the pointer on why things are the way they are.

Package everything. I got so used to it that now, I really hate "make install" which usually doesn't have a make uninstall. A bit like on windows where you end up with so many dlls in system32 and you have no clue where they come from.

My comment was more general, for the kernel it's easier as it should only install in seperate directories.

For debian, latest kernel packages:
2.6.26-rc6
Last one has been packaged today (a week after kernel.org release).
http://wiki.debian.org/DebianKernel

Not only that, but you can also overwrite files that belongs to other packages and suppress them with make uninstall when you should not, or you can uninstall that is a dependancy for another package and make the other package no longer work correctly. The package manager is definitely a better way to manage your packages.
One or two packages installed by make install is no great pain, especially the kernel and provide more flexibility, but it should be an exception and the rule should be to use the package manager. To get the best of both worlds, just get yourself a distro that has portage, which is the best package manager I've ever seen in my life for linux.

Each one has his/her own ways.

I, for one, maintain it in my home, because I find that having to be logged as root to compile your kernel is just stupid, unnecessary, and a pain. Additionally, this allow me to:

1. download only the patchlevels, which means 7kb vs. 40-50mb, do you want more?
2. ease to handle my custom patches, I don't have to put manually stuff on system folder
3. I can configure and compile as user, I only need to be root to "make install modules_install", which is why su -c exists
4. I don't idiotically add fragmentation to my root filesystem, the kernel tree is not an easy piece of cake in which regards fragmentation

For those having a binary distro, probably this would be a hassle. For me it's just perfect.