hugesmp or not
 

OK folks,

I have installed slackware12 this week and have been busy configuring it and installing packages. The only thing I don't have working is my touchpad, but I'm working on it.

I installed the hugesmp kernel, and it all seems to work fine, the only issue I have is that it is slow to boot, but I guess thats to be expected from using one of the huge kernels...

I have read a few posts that say you should only use the huge kernels for install and use the generic kernels once installed. What is the reason for this? Is there a major problem with using a huge kernel now I have slack installed or can I keep on using this kernel?

If I do recompile my kernel, can I copy over the .config file from the huge kernel and then just remove features, rather than starting from the ground up?

I presume I could compile a kernel and keep it along side my existing huge kernel, untill I can make sure it boots OK, I would just need to make sure there is a modules directory and that rc.modules points to that directory?

I have recompiled a kernel before and ended up with no sound, this is what is making me nervous about recompiling my kernel. I don't want to lose support for anything that I currently have working

Stuart

More info about hugesmp can be found here.
It's always good to compile your own kernel. A very good guide is Alien Bob's and yes, you can use the old config file (but you can read al about that on the link I posted to Alien's site).

As you said yourelf huge kernel is usualy only used for installs. After install you change it to generic one or recompile your own, well atleast that's what i do anyway.
There is no problem using the huge kernel if you want. but if you use the generic one or recompile your own the footprint of the kernel will be much smaller and you can free up some of the memory.
You can copy over your .config but dont forget to run "make oldconfig" (im not sure if this it the right command :)).
I usualy delete the modules directory when recompiling my own kernel.

The huge kernels have basically everything that can be compiled into the kernel, compiled into the kernel. It would I think waste memory (since more stuff is loaded), but would certainly increase bootup time if nothing else. It also becomes a problem when modules that shouldn't be loaded on your system are compiled into the kernel. Sometimes programs have difficulties with so many modules built into the kernel and you may have to blacklist modules. In general it's just better to switch to the generic kernel. Instructions for doing that are everywhere in these forums multiple times -- but I will say that you MUST create an initrd (initial ramdisk) in order to use the generic kernel (the filesystem modules are not compiled into the generic kernel and must be loaded in order to boot your system, hence the need for an initial ramdisk). If you have no idea what I'm talking about, search the forums for initrd and read /boot/README.initrd (which is a symlink to /usr/doc/mkinitrd-1.1.2/README.initrd).

If you don't believe me about using the generic kernel, here's a note from the man himself (Pat V):
However, if you insist on using the huge kernel, read this (also from Pat):
Both quotes are from the "CHANGES_AND_HINTS.TXT" file available on the install CD/DVD (or from your favourite mirror).

You say that you delete you modules when compiling a new kernel, however doesn't that mean that if you need to boot with your old kernel, hte modules that that kernel uses will no longer be there.

Am I safe to just leave the existing kernel and modules where they are, and compile a new one and its modules in parallel, and then reference the new kernel in lilo.conf, then if there is a problem with my new kernel I can still get in with the old one? Its really the modules that are worrying me!?!

And is the .config file for the hugesmp kernel in /boot ?

Stuart

stu_mueller, yes that's definitely possible. I never delete the old modules when I compile a new kernel just in case I screw it up. However, if you are compiling an identical kernel version, (ie if you are recompiling 2.6.21.5 instead of a newer kernel version), then the modules directory located in /lib/modules may be overwritten. If you are compiling a DIFFERENT kernel version you don't need to worry in the slightest (unless you build multiple versions of that kernel), but otherwise you should change the CONFIG_LOCALVERSION value in your kernel build. See this thread for details (posts number 10 and 12 are very helpful): http://www.linuxquestions.org/questi...ules+overwrite

That will ensure that the modules directory is not overwritten -- it will put them in a new folder in /lib/modules that has the value of CONFIG_LOCALVERSION appended. Note that I may be providing slightly incorrect information here since I've never had to use this option (I don't usually recompile the default Slackware kernels and just wait for a new kernel release before compiling), but the idea at least is correct (read the linked thread for more info). I think it's a good idea to always keep the default kernels and modules around just in case something happens, since they are basically guaranteed to work.

[edit]And yes, the .config file for the huge-smp kernel is in /boot, but is called /boot/config-huge-smp-2.6.21.5-smp[/edit]

Thanks for that. one finally thing, (I think) if you use the generic kernels you need to configure an initrd. I presume because they don't have the file systems built in.

If I am compiling my own kernel I can build the filesystem support into the kernel and not bother with an initrd, correct?

Why wouldn't they build the filesystems into the kernel in the generic kernels, is that not just making it harder?

Yes, if you build the file system support into the kernel (select "y" for built in, not "m" for as a module) you won't need an initrd.
I'm not at my Slackware box now, but I think if you read the readme in the /boot directory about how to create an intitrd, I think Pat explains why file system support is not built into the generic kernels. I know I read it somewhere, just can't remember exactly where atm.

OK this really is the finally question before I make the plunge and recompile my kernel ;)

I would prefer to use 'make menuconfig' when choosing the options, but will this pick up my .config file?

Alien Bobs guide to compiling a kernel says to use 'make oldconfig', and doesn't mention 'make menuconfig'

do I use 'make oldconfig' to import the .config file and then 'make menuconfig'? or do I just use 'make oldconfig' and cannot use 'make menuconfig' if I have a .config file?

I have just changed my kernel from huge-smp to generic-smp. I have also made /etc/rc.d/rc.wireless NOT executable (don't need it) and the improvement in the boot time is from 1m25s to 1m20s. A bit sad really. What can I do to speed it up a bit?

I'm working at recompiling my kernel right now, and stu_mueller, I believe that menuconfig will work as long as you copy the config file from /boot to .config at least it seemed to work for me... I've got a question though, what individual would be crazy enough to use 'make randconfig'???? that just looks like a disaster waiting to happen...

well, just waiting for my compiling to finish (PII 350MHz) ie. detached screen session :) haven't tried compiling a kernel since slack 10.2, and I gave up because either I messed something up or I just didn't have a clue of what I was doing. but I ended up with no sound, so I stuck with the default kernel then.

wish me luck.
nekkutta

Same goes for me, i tried it on a slack 11 machine, and ended up with no sound. The how tos make it sound so easy... I'll give it a go tonight, and will probably have to reinstall the night after :eek:

stu_mueller, I know you finished your kernel (from the other thread you created), but for future reference `make menuconfig` works perfectly with an existing .config file allowing customization based on that .config file. You generally use `make oldconfig` when you have already setup your .config from a previous kernel version and want to compile a (slightly) newer version. Since you can't show only the new options in `make menuconfig`, it would be difficult and laborious to search through all of the options looking only for the new changes (since presumably you won't need to change any of the old stuff). Therefore, using `make oldconfig` shows only the new kernel options so you can decide what to do with them. I usually use `make oldconfig` to setup a new .config file since I've already created a nice, working .config for previous kernel versions. However, I usually use `make menuconfig` to check my kernel options afterward to make sure everything went ok. menuconfig is nicely branched, but oldconfig attempts to implement a branched structure in a linear question-asking format, which can be annoying and confusing. So I usually just check that I didn't cut off any whole branches of options by accidentally answering 'n' to the wrong option from oldconfig by checking the .config with menuconfig. (Confusing enough?)

zoran119, don't expect much of a bootup improvement just from switching kernels. You could try compiling a kernel that includes only options suited for your hardware, which might improve bootup time a BIT, but it won't be noticeable enough. I usually stick with the generic kernel until a new kernel version comes out -- I like to stay current with my kernel, so I compile my own, but I don't just recompile the default kernel because it really doesn't save that much time. As for improving bootup speed, the best thing you can do is disable services that you won't use. If you don't use ssh (or won't use it as a server, anyway), remove the executable bit on /etc/rc.d/rc.sshd. Likewise with the other options. Other than that, you're basically stuck.

nekkutta, I agree with you about the `make randconfig` option. I think it's mainly a testing feature to see if a randomly generated .config file can cause the compilation to fail (ie it's designed to track down possible warnings and build errors). As for the sound problem in your previous attempt, I wish you better luck this time. ;) Problems like that can usually be recovered from playing with other sound options (or by googling your specific sound card). I like to check what modules are detected for my hardware using the generic kernel BEFORE compiling a custom kernel so I know what hardware-specific modules to enable.

Stu and Nekkutta,
If you haven't seen this yet, here is a great reference for compiling your kernel. The whole book is available online here:
http://www.kroah.com/lkn/

Recompiling Kernels
 

Hi Guys,

I used to re-compile kernels and strip everything I could.

However, I have found over the years that there is a great advantage
to use the kernel from the install CD.

That is that when something goes wrong and your box won't boot, it's
very nice to boot from the install CD with a parameter like "root=xxxx",
and boot into the real filesystem with the correct modules.

I have had everything go wrong that can, and this is why I don't
re-compile kernels again.

Exeunt