# Kernel Complication Best Practices for Newbies

## oneself

Hi All,

I've just recently started using Gentoo.  I have a working kernel which I created over time using genkernel.  I first compiled it without make any changes, and then added support for more and more hardware as I was configuring different parts of my system (x-server, audio, pptp, acpi, etc.).  Based on what I've read about genkernel, I imagine I have a lot of drives I don't really need. Am I right to assume that this would slow down boot-up times?

I would like to remove unneeded drives and options from my kernel, and generally become better at building my kernel.  I don't exactly know how to map my hardware to specific kernel options, and, to be honest, I am pretty terrified by building my own kernel, and not really sure which steps and options I modified to get things to work thus far.  It was more trial, error, and praying than actually know what I'm doing.

I've tried reading online about kernel complication in general and genkernel specifically.  Most guides talk about the make process itself, what different command line parameters do etc.  What I'm looking for is a more comprehensive guide that talks about how to start from a minimal kernel configuration, and then, using tools available on the system (e.g. lspci) figure out what hardware you have running, and then figure out which kernel options should be changed.

Hope this question is not too vague.  If it is, please, let me know, and I'll be happy to clarify.

Thank you,

----------

## avx

Hi, first it's "compilation" not "complication", don't know if you just made a typo, if not, it's no wonder you're not finding proper guides  :Wink: 

As far as faster booting goes, yes, it does have some impact to have a lot of unneeded stuff in there, but on a modern machine, it really isn't that noticeable.

What concerns starting from a minimal setup, our very own @pappy_mcfae has a project named kernel seeds, which provides some configs having only the bare minimum, which you can/should read up on.

To go further, a good start would be to use some common livecd of a "does all for you"-distribution (ubuntu, fedora, ...), booting it and then check the output of `lspci -k`, showing kernel drivers in use. That will cover most things, but depending on your hardware, maybe not everything.

For other stuff, the best way is really to either google or run `make menuconfig` and read the provided help for every option, there's even more in-depth info directly in the kernel-tree (in gentoo, that's usually /usr/src/linux/Documentation).

Depending on what you are trying to do with the system, there are quite a few things to turn on/off additionally, think encryption, raid, lvm, firewall, multi-boot with access to other OSses filesystems, etc.

First try to get a working kernel, only building in the most important parts, ie. disk-controllers, filesystems needed to boot, etc. From there, you can build stuff as modules and try them on runtime, without the need to always reboot.

It's really not that hard, once you've got used to it. That's about all I can say for now, to answer more specific questions, one would need to know about the specs of your machine and what you're trying to do.

----------

## oneself

Thank you,

I'll definitely check out the kernel seeds project.  However, what I'm looking for is some direction between stock genkernel (or livecd kernel) and reading all the documentation for every available module.  For example, you mentioned booting a livecd up and doing lspci -k.  But what do I do with this information?  How do I correlate this output with actual kernel configuration?

I guess my question boils down to this: Given a working system (livecd, Ubuntu, genkernel, etc.) how do I produce a working kernel configuration without any extra unneeded modules?

----------

## Ant P.

`make localyesconfig`

----------

## gorkypl

I can only tell you how I did it the very first time many years ago. In fact it IS about 'reading all the documentation for every available module', but the experience you gain from this is invaluable.

Just reserve 2 or 3 spare hours and keep working even if you are bored. You should try to build working kernel in one session, because after one or two days you will probably forget what you have set before.

Know your hardware before getting to work - lspci is a very good way to do this, because when you do it from a working system you can see the names of modules that are in use. And do not worry about anything - the worst thing that can happen is unbootable system, so keep a kernel that works and use it if you are unable to boot.

Proceed through all the options - you will quickly notice it is not THAT hard, because some of them are obvious.  E.g. you will probably want graphics support and do not want Dallas 1wire support.

Use built-in help and read about the module you do not know. If it looks like it will not be needed - turn if off. 

Try to build a minimal kernel that works - you can add stuff like powersaving, automatic process group scheduling or even networking later on.

When you will have a working kernel that has drivers for all your hardware, take a break.

Then, come back after a day with a fresh mind and go through the options once more, trying to find the unnecessary ones. Don't be afraid to turn them off - again, the worst that can happen is unbootable system. Just use your good kernel then  :Smile: 

Ah, don't forget about make modules_install  :Smile: 

----------

## toralf

 *Ant P. wrote:*   

> `make localyesconfig`

 I prefer in the mean while "make localmodconfig" (Not well documented in the sources - google around for it).

----------

## avx

While localyes- and localmodconfig do work, I'd still advise doing it manually. While they produce a working kernel, there are options which aren't default, but can make the system smoother, save power, etc.

Knowing your way around is key, at least when you get a new piece of hardware sometime in the future. It takes some time, sure, but it's worth it.

----------

## hcaulfield57

I am very new to Gentoo and kernel compilation as well. So I'm in the same boat as you are. I can honestly say that kernel compilation is not that bad, you just have to do a lot of reading.

If you press / as you would with less or vim in make menuconfig it will tell you what each individual thing does for the kernel. You will probably have to read through all the options.

The book "Kernel in a Nutshell" which can be found online has tons of good information about kernel compilation as well. 

I've found for me its mostly trail and error. I keep a kernel which I know is bootable installed and on grub, so that if I make a kernel which is unbootable, I can boot into the other and fix it. 

Kernel compilation is really rewarding, and you learn a ton about Linux by doing it, it also adds a lot to performance (as far as I can tell) because my boot time is under 10 seconds and my system usually runs under 100 mb.

----------

## oneself

Thank you everyone who responded.

I will definitely do some more reading about this.

Linux Kernel in a Nutshell is available online here: http://www.kroah.com/lkn/

I also found this helpful: http://swift.siphos.be/linux_sea/ch07.html

I think that localmodconfig/localyesconfig is a really good place to start.  I will definitely give those a try.

Thank you.

----------

## cwr

I find that when I build kernels it's easy to forget what I've done - one thing you definitely

need to add is the /proc/config.gz file (CONFIG_IKCONFIG_PROC) so that you know

what you've done.

The other helpful thing is to have two entries in grub.conf - one for the current kernel

and one for the test kernel, with the current kernel booting as the default.  You can

name the kernels with CONFIG_LOCAL_VERSION, which will add a string to their

(standard) names.  Then you can mess with the test version, and still have the

current version to go back to when it all goes pear shaped.  When you are happy

with the test version, build it as the current version, rinse and repeat.

(And keep renamed copies of your .config files - that way diff will tell you what

you have done).

Good luck - Will

----------

## avx

 *cwr wrote:*   

> I find that when I build kernels it's easy to forget what I've done - one thing you definitely
> 
> need to add is the /proc/config.gz file (CONFIG_IKCONFIG_PROC) so that you know
> 
> what you've done.

 Why I see a point here if the kernel is shared among some systems, when I use 

```
make && make modules modules_install install
```

a copy of the config is copied to /boot as config-X.Y.Z-gentoo.

----------

## Bones McCracker

I think you mean

```
make && make modules_install && make install
```

----------

## avx

Dunno, my command always worked, maybe it's too much, but it does work. I didn't make that up, that's been somewhere in the docs when I first installed Gentoo.

----------

## Arkhelion

 *avx wrote:*   

> Dunno, my command always worked, maybe it's too much, but it does work. I didn't make that up, that's been somewhere in the docs when I first installed Gentoo.

 I'd say the word 'modules' is not needed as 'make modules_install' implies 'make modules'

----------

## avx

I'll try that, better yet, have a look at the makefile, thanks.

----------

## Bones McCracker

I don't like it to run 'make install' unless everything else is ready to go, which is why I chain them all conditionally: 

```
make && make modules_install && make install
```

rather than:

```
make && make modules_install install
```

The more useful aspect of the 'install' target (which I think is a Debian thing) isn't that it copies the config and system map to /boot, but that it creates and rotates generically-named symlinks for you, so you don't have to touch your bootloader configuration.  For example, with 'vmlinuz' pointing to a copy of the latest kernel and 'vmlinuz.old' pointing to the previously-installed kernel, allowing you to simply refer to those generic names in your bootloader configuration):

```
vmlinuz -> vmlinuz-3.3.1-gentoo

vmlinuz.old -> vmlinuz-3.3.0-gentoo

```

These are symlinks by default, can be hard links if you prefer.  If your /boot directory contains no links the first time you run in, soft links will automatically be created.  However, if your /boot directory contains appropriately named hard links (e.g. 'vmlinuz' etc. are hard links) then hard links will be created.  I imagine there's a variable somewhere to control this, but this much I have observed.  I like to use the soft links simply because it's easier to visualize what the hell is going on.

----------

