I have a Packard Bell Easynote M5 284 laptop (same as NEC Versa M400).

I am currently compiling Kernel 2.6.15.4 and there a loads of modules being compiled that I will never need, after all you can't upgrade a laptop to the same degree as a desktop unit.

Is there an easy way to remove all these unwanted modules?

I have always thought that this is a process that could be made easier by using hardware detection, and an interview script, or even a database of config files for laptops.

Or is there a web site/howto/document that explains what modules are as some of the descriptions/names are cryptic.

Samac

You can get rid of them by not compiling unwanted modules in the first place. Run "make config" or "make menuconfig" or "make xconfig" to trim down tour kernel build by disabling the functionality of which you think it is unwanted.
Note that unneeded modules do not use up memory - they are only loaded into RAM when needed by the kernel (hotplug is one of the methods of determining what modules should be loaded on boot).

Eric

I trim it (the kernel) down all the time.

While it's true that modules do not take up RAM, they do take disk space, and time when compiling, so I also get rid of all I don't need.

Just my two cents

Many thanks for the replies.

Perhaps I should have explained more clearly.

The mechanics of removing the modules is easy and well understood, it is as cwwilson721 has said it is the extra time when compiling that is the pain.

What the question is, is what parts not to compile? because what normally happens, is I take out something that seems to bear no relevance, and it breaks something else.

I like clean, simple, no clutter for my computer, yet the kernel by its very nature has to support everything that is and everything that could be. For a laptop this is overkill.

Perhaps an easier way to start would be bottom up rather than top down, ie What is your architecture? Then build up the options for your hardware, then .... etc.

Have you any suggestions for a cleaner build?

Samac

Good luck.

When I used 2.6.13, it took 3 tries to get it to boot, then 8 more recompiles to get everything working the way I wanted it to.

Just compile, recompile, and recompile again.

(Hint: Once you get it bootable, use the same config file for the revisions. Then just reconfig, make, make modules_install. It's fairly quick then.)

But always have a 'good' kernel to boot to in case the 'new' kernel fails you.

This does speed things up, thanks

Samac

Hi,

I agree it can be difficult to get your system trimmed. I generally start from the hardware standpoint. I use the lspci -vv to get system information. Or use systemrescuecd aidat option to get all system information. With this data at hand you can easily trim your config for hardware needs.

As from a sub systems configuration. That would be dictated by how your system is used. The network configuration options is a good place to start. Trim the options that you think will not be needed. Of course you would need tcp/ip but probably not atalk protocol unless you are communicating with a MAC OS. Many other areas you can trim, just note what protocol you will need or possibly need.

Filesystems are another place you can trim rather easily as you should know what you will be using.

Just document your changes and there resultant. Sure your config will point this out but a log will assist you by providing a trail that you can reflect on.


HTH!

I always prefer to first use "make oldconfig" when I go to a new kernel level. Instead of getting the defaults for any new options, you get the chance to change them - say all the (new) "M" selections to "N".
Saves a bit of leg-work later when in the config.

And yes, no-one in their right mind should over-write a known good kernel image. Delete it later when you are happy with the new guy.

I was just saying for fine-tuning (Such as : Oops forgot to add my ethernet card in there....lol).

NOT for new kernel level. You should use oldconfig then, or mrproper

Thanks again

I like the idea of a log (gwsandvik), and I used the oldconfig to get the kernel working.

However consider this. ACPI was being a ***** (insert your favourite expletive) to set up. All options were selected in the ACPI section and it still would not work, I selected something completely unrelated in the sound drivers section (alsa oss compatibility I think) and ACPI started to work.

This is what makes me think that a there must be an easier way, for example if livecd's and most distributions can autodetect hardware and other operating systems on your computer, surely they could output this information in a format that "make (config, menuconfig, xconfig)" could read, after all it is only a plain text file, this along with a script that asks questions such as "Do you use your computer to watch TV?"

Am I just living in cloud cuckoo land or is this possible?

Or could it be that the kernel is just so complicated as it evolved that way?

Could it be time for a shake up, for example, a start would be; "Your computer has i686 architecture you will not need isa bus support so this will not be shown." There must be an awful lot of architecture specific options in the kernel.

I know this is a bit of a rant, and as I am not a programmer, completely irrelevant, however I do believe that life should be as simple as possible, and this is one of those things that could be simpler.

Many thanks again, the log is a good idea and the oldconfig is what I currently use.

What follows should be a rant, which was logical and entertaining, but the forum ate it when I tried to post it, so here is a short version, which is likely to be less logical and entertaining.

Second attempt.

I now have ACPI working, but although all options were selected in power management / ACPI I needed to select an option in sound drivers / ALSA for ACPI to work.

This is just plain wrong.

Many hardware options are specific to architectures eg. I would not think that there is a computer out there which is i686 that has an isa bus.

So why do the kernel configuration programs not take their information from the computer not the operator, after all if live cd's can autodetect so can the kernel configuration program?

Any way I know this is probably caused by evolution of the kernel, but that does not mean it is right. As I cannot program for peanuts, this would be beyond me, but there must be a simpler way after all, all the tools are already in place, they just need to be put in a more logical order.

Samac

*********************************************

It appears it was not eaten after all, and now you know that I am prone to stretch the truth as the previous article was neither entertaining or logical.

Samac

*********************************************

Don't feel too bad - it's even topical on LKML ...
Look here

I got a question for you guys. Every once in a while when I am through doing a bunch of compiling and recompiling because I well know what it is like to not have the little ******* boot, I get this message that says something to the equivelant of "Something in Lilo EDBA is overlapping something else". Has anyone had any experience like this and if so can anyone tell me what it means and how not to do it again. Hasn't happened in a while so I don't know the exact error message but it's pretty obvious if you got it and the kernel just hangs.
thanx
M

Lucky me, i only need once to make it work (but without optimization and missing ALSA module), and the second compile works like a charm