Slackware Linux Essentials question - Selecting a Kernel...
 

Hello:

Slackware 13.1 is installed using the installer defaults and I have do nothing else, that I know of, other than installing wireless. (wicd)

(I originally installed lilo to the MBR which did not include LMDE in the menu so I re-installed LMDE and Grub included Windows, Slackware and LMDE in the boot menu, as I wanted.)

The book, in section 4.2 talks about 'Selecting a Kernel'

I don't understand the 'why' of this section. Slackware is working, right? 'It talks about compiling a Kernal from source' - do I need to do this? Why?

Thanks for any guidance,

At the beginning of the installation you can choose a kernel. Unless you've got some specific reason to do so, you don't need to choose any other kernel or recompile it. The default kernel is fine for the majority of users.

The default kernel will be just fine; no, you do not need to compile it (or any other kernel). However, you can, if you want or need to, compile a stripped-down kernel customized for your hardware. As it is, the default is built with modules that load as required but otherwise don't bother you and you'll be able to use it without worrying about it.

The can is so you can learn how (it's not trivial but it's not rocket science either). The basic concept of Linux is that you can do whatever you want to with it; want to learn how to compile a custom kernel? Go for it.

So, essentially, leave it alone and enjoy it until the time comes that you really want to dig in and find out what's what and why's why.

Hope this helps some.

I believe I choose the 'huge' kernel. A screen shot of my boot directory is attached (I think) - is it OK?

I used to think that compiling a kernel was a "good thing", & maybe when I started out, it was. But I no longer feel that way. The generic kernel works fine for me, at the slight added cost of making an initrd. I do not use any special hardware (RAID, etc) to boot, so just following the README.initrd in the /boot folder is sufficient. If you do need a bit fancier initrd, Slackware includes Eric's program "/usr/share/mkinitrd/mkinitrd_command_generator.sh", which will produce the proper command line to build a custom initrd.
Edit: I was really outgunned this time. However, using the "huge" kernel is not recommended. You really should switch over to the generic kernel & an initrd. See the "Changes And Hints.TXT" in the root of your install media for the reasons for this.
Regards,
Bill

The output of:

would be better in this case as it'll show us more information, but AFAIK the huge one is the default one. That's good. There's less chance that some hardware won't work because some module is not loaded.

You shouldn't need to compile a kernel unless you want to. You should, however, switch to the generic kernel as Bill already mentioned. I included instructions for this procedure in the following Slackware configuration tutorial:

http://genek.net/LinuxAdventures/ins...ackconfig.html

Gene

Here it is:

Yes, as you can see:


System.map, config and vmlinuz are symbolic links to the files belonging to the huge kernel.

Once you've installed the system and are happy with it, you can, if you want, switch to the generic one, as suggested by others.

I followed Gene's tutorial and now I have this:

The only problem is that I cannot tell whether I am still HUGE or if I have become GENERIC - can you tell me how to know?

Oops! I didn't run lilo because that instruction is included in the "While We're at it, Let's Ditch the Boot Prompt (not for dual-booters)" section.

Now that I have re-booted, is it safe to run lilo now?

Thanks,

Yeah, go ahead and run lilo. Always run lilo after doing anything at all to lilo.conf.

I got some msg's:

Should I still re-boot or have I screwed something up?

If it matters, I am using a Lenovo X61 laptop.

Thanks,

I forgot that I was waiting for some advice and re-boot and selected Linux_G; here is what I see now:
Am I GENERIC or HUGE and how do I know?

Thanks,

Hi Robert:

when I started with Linux I hadn't a clue what all this was about. Debian didn't help because the developers had already done the work for me. Only when I moved to Slackware did I begin to understand.

Here's one way to understand it:

let's say you have a Windows XP partition and a Slackware partition on your computer. If your Linux kernel hasn't been compiled with NTFS file system support then Slackware won't "see" or mount the Windows partition, meaning you won't be able to copy stuff from your Windows folders to your /home directory. So NTFS file system support must be compiled into the kernel if that's what you want to do. The huge kernel has NTFS compiled in, but the huge kernel has *everything* compiled in, just in case, including support for hardware devices you're unlikely to ever use. Compiling a kernel allows you to trim the huge kernel to your own needs. A generic kernel is usually a kernel where the trimming has been done for you and support for hardware and filesystems and suchlike is compiled in as modules, meaning it's not hard-coded into the kernel but compiled in in such a way that if the hardware is there the driver is loaded and if the hardware is not there then the driver is not loaded.

Here's what I do with kernels. I download the vanilla 2.6.37 kernel from kernel.org and extract it to /home/user/build as an ordinary user (it's a good idea to check the integrity of the download first but that's for another thread). Download the kernel (bz2) first and then in a terminal do the following:

For ease of use I then symlink (shortcut, in Windows-speak) the new linux-2.6.37 directory that has just been created:

Now I change into the new linux directory:

I then get my hands on a config file for the generic kernel. Use your browser to go to the following address:

The generic-smp config will do nicely. What this means is that I now have a configuration file for a generic linux-2.6.33.4 kernel which means most of the guesswork has already been done for me. I want to use that as a template to help me configure the newer 2.6.37 kernel.

Now I copy that config into the linux directory I created earlier:

Make sure you copy it as .config - the dot is important.

Now I start compiling my new kernel. I already have a 2.6.33.4 kernel config so I can *make oldconfig* to bring my config up to 2.6.37:

It's safe to accept the default answers here - there will be quite a lot so just keep pressing Enter as this is your first go.

Once that's finished you can go through the kernel config to see if it's to your liking. Make sure you're still doing all of this as a normal user, not as root:

Now you get a tree where you can make your changes - don't go too mad here but just have a look through it to see what's going on. Have a look at file systems for example and see if NTFS is compiled in. If it's hard-coded into the kernel it will have a star and if it's compiled in as a module it will have the letter M. A module is fine because your Slackware only needs NTFS on-demand. Your Slackware root filesystem is a different matter - if it is formatted as ext4 then you MUST compile the ext4 filesystem into your kernel so that the system boots. In other words, a star, not the letter M, beside ext4. If it's ext3, then a star beside ext3. If you don't know what your root filesystem is, go to another terminal and type this:

You will see what your / directory is mounted as. Make sure filesystem support for this and other partitions is compiled in - if in doubt, put a star beside ext4, ext3, xfs, and jfs. But you're intelligent enough to know by now what's going on eh?

As I say, don't go mad changing things here - look around and get comfortable with it first. One thing you can safely do is change your processor family under "Processor type and features" - Core 2/Xeon here. Take your pick. Use the spacebar to select. Now you will get the benefit of a kernel that understands all the intricacies of your processor. Beforehand you just had a kernel with generic processor support.

OK that's enough for now. Exit and save your new config.

Now you can *make* the new kernel. If you have a multicore CPU you can speed the *make* up a bit with the -j switch.

This will take a while.

When it's finished you need to *su* to root so that you can install your modules and then your kernel:

The last step will update your lilo so that the new kernel will be selected automatically at boot. The more experienced users here will probably tell me this is a bad way to go about kernel configuration because it leaves me with no backup if things go wrong, so it's important not to make any radical changes until you know what you're doing when you're configuring.

Now if you reboot you have a spanking new kernel, with support for your specific processor compiled in. It might not make a huge difference, but it will make a difference, so it's worth doing. Type the following in a terminal to make sure you've booted up with the new kernel:

Voila. You're good to go. Hope this helps.

You're running the generic kernel now.

Thanks!

Just one question: How can you tell?

Hi Gezley:

Thanks for all your time and effort - what a great post!

I will attempt this later this evening. It is 4:52pm here - shouldn't you be asleep? (please, don't tell me that you are!!!;) )

Rob.

Just run
and this will tell you what boot image, root device and other parameters were passed during boot. Running lsmod will give you a fair idea, (once you are used to the output for generic versus huge), as the generic will have a lot more modules loaded however the first solution is safer when beginning.

Hi,

The first warning can be rid of by using the 'lba32' in the global section of your '/etc/lilo.conf'.

Second, third warning by use of the 'vga=normal' in '/etc/lilo.conf'.
Do the following with the '/etc/lilo.conf';

First line is just edit of the '/etc/lilo.conf' file. The next will test (-t) the '/etc/lilo.conf'. If you get a clean output then perform the last by removing the '-t' and running the command. I do suggest that you 'man command' things to understand fully.

When you are working on the kernel, be sure to keep a working kernel stanza within the '/etc/lilo.conf' to allow you to recover when needed.
:hattip:

Thank you, I can now see that I am a GENERIC Slacker!

No! It's just 10:18 here! But don't tell mammy I'm still up! :)

You are running huge. How to tell? See the above I have highlighted in red. System.map, config and vmlinuz point to huge-smp-2.6.33.4-smp or the huge kernel. How to switch to the generic kernel? Remove the existing links and then link to the generic-smp-2.6.33.4-smp kernel.

# cd /root/
# rm System.map
# ln -s System.map-generic-smp-2.6.33.4-smp System.map
# rm config
# ln -s config-generic-smp-2.6.33.4-smp config
# rm vmlinuz
# ln -s vmlinuz-generic-smp-2.6.33.4-smp vmlinuz

Just to make sure all is well also run this to make sure you have initrd setup.

# mkinitrd -c -k 2.6.33.4-smp [-m <needed modules here>]

Your lilo.conf should have an 'initrd = /boot/initrd.gz' statement in it.

Last run lilo and reboot.

I've modified the tutorial in question to clear up the confusion about running lilo. Sorry, Robert.

The only important symlink there is System.map --> System.map-generic-smp-2.6.33.4-smp, and I'm not 100% sure whether that's needed either.
That would tell you what kernel you are actually running -- if it outputs true, then you're running the generic kernel. False means you are probably running the huge kernel (though you could change the path to /boot/config-huge-smp-2.6.33.4-smp and expect an output of true to verify that). The config-* files are really just for your benefit -- the kernel itself doesn't care about them (it stores its config file internally accessible via /proc/config.gz, and even if it's compiled without that option I don't believe the kernel uses the config file for anything post-compilation). The vmlinuz symlink is only necessary if you don't explicitly name the vmlinuz-generic-smp-2.6.33.4-smp file in lilo.conf (ie if you just use /boot/vmlinuz). So the presence of that symlink is not indicative of which kernel you are actually running. The System.map file is trickier...it is used to lookup symbol information and is mostly valuable for kernel oops debugging, and your system would run perfectly fine with an incorrect System.map file (though if you get a kernel oops you'd get some bad results). I've been looking for proper information on this, but my searches have come up empty. klogd looks for /boot/System.map-$(uname -r) first -- but because Slackware's System.map files have the generic/huge identifier added, I'm not sure if klogd actually grabs the right one. I'm running the generic kernel on Slackware64-13.1 with System.map still pointing to the huge kernel's System.map file, but there are no messages about the wrong System.map file being used in any of my logs. See here for more information, but alas it does not provide the information I wanted (neither does `man klogd`). Using strace alongside klogd doesn't give me any valuable information either.

Anyway, the System.map symlink couldn't hurt, so you may want to change that -- but if you want to be 100% positive that you are running the generic-smp kernel, use the first command I mentioned.

Thanks! It's TRUE, I am GENERIC.

Here is my output:

Hi Gene:

Pls forgive me for being persistent about this but I 'need' to know how you knew that my system was GENERIC...

Did you determine that from my 'ls -l /boot' output above, and if so, 'how' do you know?
or,
Did you know that if I followed your tutorial correctly, that I would be GENERIC?

Off-topic comment:

Thank you for your great tutorials - ever since I discovered them, I refer to them all the time. I am certain that your efforts are making 'that fog called linux' lift for many readers!

I knew because you selected Linux_G at your prompt screen, and if you followed my instructions that can only be the generic kernel. I've gone through this process enough times myself to have confidence in it.

Glad you like the tutorials. I'll have another one up soon on file permissions.

Thanks! I needed that! :)

Hi Gary:

Here is my output now:
Only one warning.

Here is my etc/lilo.conf:

What is the problem that is causing the warning?

Thanks for you time with this,

Hi,

By using the directive option '-b /dev/your_device' you are not using the 'boot=/dev/sda' within the '/etc/lilo.conf' thus the warning to ignore 'boot entry'.

You don't need any of those symlinks IF you are specifying the exact kernel to boot from (e.g., vmlinuz-generic-smp-2.6.33.4-smp) in lilo.

Using symlinks is standard practice and make things simple.

Personally, symlinks complicate things. If all you have is one boot option, compile your own kernel, and 'install' it without copying over the files your self, you may end up with a system that doesn't boot and will need a CD to recover.

Hi,

I will point you to ' System.map Explanation' and 'The system.map File' notes by rworkwan. Read the referenced links and then come back. You may not need it but it would be nice to have it when you do;
Just one of many reasons that justify and provide a means to get information at times to diagnose.

Your system to do as you like but a generic statement as you put it. Not on my system!

I'll keep things clean and clear so that when problems do come up then I'll use all the tools available to help diagnosis.
:hattip:

Symlinks to kernel versions are ONLY useful if you don't use LILO in my opinion. You have to run `lilo` after editing lilo.conf every time anyway, and if you change the symlink it won't work at boot-time without re-running lilo because it is referencing the inodes of the old kernel image (if it still exists). If you use GRUB, then symlinks to kernel images make things much easier. If not, then it's really no help at all.

Did you read my post?

I was replying to this:
What I said with this:
Exactly were in my post did I say that System.map was not needed?

One could also name the System.map file System.map-2.6.33.4-smp.

At any rate a Linux system should run just fine with out System.map symlinked. I did not advocate doing so I simply said the symlink is not needed. Please feel free to give me some specifics in which the symlink is needed to run Linux, not debug it.

Did you know in Slackware klogd does not use System.map, it hasn't for quite some time. From rc.syslog:
The 2.6 kernel can decode most kernel oopses and produces decent dumps on it's own with out the use of System.map. Both the generic and huge kernels are built with CONFIG_KALLSYMS.

In the for what it is work department; I do symlink System.map to match my kernel.

Just for kicks, I am running another Slackware box without the kernel System.map linked, renamed to System.map or using the 'uname -r' suffix. I am keeping the standard Slackware names.

Thanks for the full explanation; I hadn't thought to look into klogd's passed parameters and frankly didn't know you could forgo reading the System.map file. I haven't seen this information anywhere, and thus why I stated I wasn't sure if the symlink was needed. Anyway, the other symlinks are frivolous and may be helpful on a personal level but still do not definitively indicate whether or not you are using the symlinked kernel -- if one did not run an error-free lilo after editing lilo.conf the symlink may still exist, the system may boot, but they may still not be running the kernel they think they are. It is for unlikely scenarios like this that I suggested checking /proc/config.gz instead of relying on the circumstantial evidence of a symlink.