Kernel building with abs is convoluted

haxit · 2009-03-01 01:01:06

Thanks B! Did you use any scripts to find your modules?

methuselah · 2009-03-01 02:32:42

B wrote:

haxit wrote:
zyghom wrote:
you killed me here: mine is 69M
Ye exactly! Can you teach me B?
Trial and error . A module will take more space than an in-kernel driver, that's all I can say. So anything you use (like all the time), compile it in statically. Read the descriptions in the kernel configuration interface (make {g,x,q,}config), throw out what you don't need (start with drivers, there's tons of drivers in the Arch kernel since it's a generic one-size-fits-all kernel), track your changes (diff kernel configs). It is better to do it gradually - strip stuff you know you won't need, reboot, check if all your hardware is still recognised and functional. If yes, repeat process. After you strip the drivers you can strip filesystems and stuff (e.g. network filesystems), and check each subsystem (e.g. USB) for stuff you don't need. USB has tons of extra options and drivers you probably won't use.
Basically, recompile until you hit the wall, and use different configs (diff them, save them). It takes a while to strip the stuff if you start out, but once you're in, you're in, and to keep it maintained is usually little more than updating the PKGBUILD to the new versions used. And, if you're feeling adventurous, you can still pull in some patches from e.g. the Zen kernel (I personally don't, I mostly use stable).
And also - make sure you give your own kernel another LOCALVERSION than -ARCH .
To counter the arguments made against putting a kernel build in a PKGBUILD: I like the checks and automation the PKGBUILD gives you. It takes a lot of work to set up at first, but that is a one-time operation. I for one am quite sure I won't forget to drop in some patch or stuff like that, you just run the PKGBUILD, install, that's it.

I've had a few questions about this for a while.....

question #1: Will this improve the boot time at all?
question #2: Is there anything that can't be installed directly into the kernel? (better to keep as a module)
question #3: the modules line in the rc.conf..... do I delete the modules from that line that I install into the kernel....

like all of these:

MODULES=(forcedeth snd-mixer-oss snd-pcm-oss snd-hwdep snd-page-alloc snd-pcm snd-timer snd snd-hda-intel soundcore powernow-k8 hp-wmi cpufreq_ondemand cpufreq_powersave)

question #4: And how about the HOOKS and MODULES line of mkinitcpio.conf ? Do I need to change those at all?

Thanks for the info and any other info for building my kernel better.

.:B:. · 2009-03-01 03:28:57

1. I haven't really tested it. I have an SSD and it boots very fast as it is already, I was never in it for the boot times . In theory, it might.
2. Some drivers are better kept as modules indeed, I had a peculiar case where my nForce 3 S-ATA/P-ATA driver would bork if compiled into the kernel but not as a module. I heard about some CPU frequency drivers giving problems when compiled in statically too. But again, you have to test what works best for you.
3. What do you think yourself?
4. If you compile any modules in statically that are related to the hooks you use, the hooks will produce errors when run during the initcpio generation, but it should be fine (at least, if you see mkinitcpio complain about missing modules that are now part of the kernel). Of course if you specify any modules to be built in explicitly in mkinitcpio.conf, it's best to take it out. Filtering out stuff from hooks is more bothersome because those files get replaced at each upgrade of the package that the hooks file belongs to. Other than initcpio generation there shouldn't be anything affected (instead of in the initcpio the driver will just be in the kernel, so the result will be the same).

lilsirecho · 2009-03-01 03:29:56

f4hy;

Nice subject and well attended.

To make it most delightful, edit convoluded to "convoluted" in your initial post.

methuselah · 2009-03-01 04:29:32

B wrote:

3. What do you think yourself?

Yeah, I guess that was a pretty stupid question, my bad..... I think I really meant to ask if you saw any modules in that MODULES line that I shouldn't build into the kernel as a driver.... like the forcedeth module or any of those alsa modules? (other than the CPU freq drivers like powernow-k8 cpufreq_ondemand cpufreq_powersave)

Thank you for the info, I'm gonna try some new things with my next few kernels.

Last edited by methuselah (2009-03-01 04:30:25)

Themaister · 2009-03-01 13:31:22

I actually prefer the traditional way when it comes to the kernel

f4hy · 2009-03-01 23:01:55

lilsirecho wrote:

f4hy;
Nice subject and well attended.
To make it most delightful, edit convoluded to "convoluted" in your initial post.

Thanks. I have taken the ideas people have given me from here and tried to put some of them on the wiki. See http://wiki.archlinux.org/index.php/Kernel_Compilation

broch · 2009-03-02 15:37:41

you should run
make clean && make mrproper
only if if you are re-using kernel tree. Otherwise no point to do this.
make dep
is long time outdated

$ make oldconfig (only if you've copied the old .config file)

no
make oldconfig
make menuconfig
make xconfig
will invoke different kernel configuration tool interfaces. Has nothing to do with "old" config file

if you are customizing kernel, most probably you need custom mkinitcpio.conf. However customizing default file will cause problems with the installation of default ARCH kernel (if you want to keep it as a backup). In such case make separate /etc/mkinitcpio_custom.conf
then run (example)
mkinitcpio -k 2.6.28.7-whatever_name -c /etc/mkinitcpio_custom.conf -g /boot/kernel-2.6.28.7-whatever_name.img

regarding nvidia installation:
you basically are removing nvidia module from one kernel and install to another. Assuming that you have more that one kernel this makes little sense. install nvidia (ati) modules for all kernels you have so rebooting to next kernel will not leave you at command prompt.

f4hy · 2009-03-03 06:43:12

Who are you referring to about the make config stuff? I do not see anyone on this thread talking about it.
Are you referencing the wiki? In which case please update stuff on there. I certainly did not write any of it, just expanded the page that links to the different topics. The whole point of this thread is that the information kernel complication is horrible,

broch · 2009-03-03 14:28:12

this link
http://wiki.archlinux.org/index.php/Kernel_Compilation

points to this:
http://wiki.archlinux.org/index.php/Ker … rom_Source
which states

$ make oldconfig (only if you've copied the old .config file)

which is obviously incorrect

Thanks. I have taken the ideas people have given me from here and tried to put some of them on the wiki.

you would have to take responsibility for your own statements. If you think that wiki is mess, then why to create one more entry to point to another entry which is horrible according to your own words.

Last edited by broch (2009-03-03 14:33:29)

Rorschach · 2009-03-03 17:22:52

haxit wrote:

Thanks B! Did you use any scripts to find your modules?

lsmod shows you which modules are in use so why not start with them

.:B:. · 2009-03-03 18:27:03

haxit wrote:

Thanks B! Did you use any scripts to find your modules?

Lsmod and lspci output, that is all . Lshwd might come in handy though.

sultanoswing · 2009-03-04 09:12:41

THe various methods listed above were too compicated for me, and resulted in various errors which I couldn't fix.

Kludge's Kernel26parallel from the AUR solved all the hassle and stress, and with a couple of simple edits to the PKGBUILD (to allow make menuconfig and to automatically load my custom config file) it's a cinch to maintain the latest kernel releases as a trimmed down custom kernel. So simple even I could do it!

big_gie · 2009-03-08 20:43:35

Hi all,
I wanted to respond to a couple of post here but did not have the time.

But a signoff request for a new kernel has been posted by tobias:

Tobias Powalowski wrote:

Hi guys, new kernel adresses the following things:
- changes for better customizing the default kernel included
http://bugs.archlinux.org/task/12384
--> firmware needed to be split off the package.
It is now called kernel26-firmware
[...]

This is great news! It means anybody will be able to compile a custom kernel easily! This kernel is actually in testing.

I installed the stock kernel, I'll reboot in a couple of hours. I'll try to compile the stock -ARCH kernel, and a -custom one. Please test also!

Arch Linux

#51 2009-03-01 01:01:06

Re: Kernel building with abs is convoluted

#52 2009-03-01 02:32:42

Re: Kernel building with abs is convoluted

#53 2009-03-01 03:28:57

Re: Kernel building with abs is convoluted

#54 2009-03-01 03:29:56

Re: Kernel building with abs is convoluted

#55 2009-03-01 04:29:32

Re: Kernel building with abs is convoluted

#56 2009-03-01 13:31:22

Re: Kernel building with abs is convoluted

#57 2009-03-01 23:01:55

Re: Kernel building with abs is convoluted

#58 2009-03-02 15:37:41

Re: Kernel building with abs is convoluted

#59 2009-03-03 06:43:12

Re: Kernel building with abs is convoluted

#60 2009-03-03 14:28:12

Re: Kernel building with abs is convoluted

#61 2009-03-03 17:22:52

Re: Kernel building with abs is convoluted

#62 2009-03-03 18:27:03

Re: Kernel building with abs is convoluted

#63 2009-03-04 09:12:41

Re: Kernel building with abs is convoluted

#64 2009-03-08 20:43:35

Re: Kernel building with abs is convoluted

Board footer