But a signoff request for a new kernel has been posted by tobias:
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!
]]>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!
]]>Thanks B! Did you use any scripts to find your modules?
Lsmod and lspci output, that is all . Lshwd might come in handy though.
]]>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
]]>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.
]]>$ 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;
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
]]>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.
]]>Nice subject and well attended.
To make it most delightful, edit convoluded to "convoluted" in your initial post.
]]>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.
]]>