I'm looking to upgrade my kernel on my Slackware 14.1 system because I believe it'll solve a problem similar to the one in this thread but the problem is, I am unsure of just how to go about doing this.

Looking in http://mirrors.slackware.com/slackwa...ernels/huge.s/ I see three files: System.map.gz, bzImage, and config. I'm guessing I put bzImage in my /boot folder then update lilo.conf to add lines like so:
right?

What do I do with the System.map.gz and config files?

No. Instead you should build and install yourself a kernel and modules for your Slackware version and architecture (the link you provided is for 64 bit not 32 bit, by the way).

You could take as a basis a config file provided here (the huge-smp to make things simpler or the genric-smp that would need an additional step: making an initrd). Follow this.

I've used Eric's guide to build a new kernel. Back up your data before you attempt upgrading your kernel.

http://alien.slackbook.org/dokuwiki/doku.php?id=linux:kernelbuilding&s[]=kernel&s[]=compile

You should definitely look at http://alien.slackbook.org/dokuwiki/...kernelbuilding

Essentially this would work. But you still need to install the modules for the current kernel, 3.14.12

Another way is to download the kernel and module packages from the http://mirrors.slackware.com/slackwa.../slackware64/a directory.

Then upgrade your system:

#upgradepkg kernel-huge-3.14.12-x86_64-1.txz
#upgradepkg kernel-modules-3.14.12-x86_64-1.txz

Take a look at the /boot directory to see how the package install system handles the bzImage, config and System.map.gz

The bzImage ends up as /boot/vmlinuz-huge-3.14.12
The config ends up as /boot/config-huge-3.14.12
The System.map ends up as /boot/System.map-huge-3.14.12

Since a symbolic link /boot/vmlinuz points to /boot/vmlinuz-huge-3.14.12 the lilo entry can look like this:

Thanks for the answers, but I would really rather use a precompiled kernel and modules from the -current branch than roll my own from the -testing branch.

I still have nightmares about "make config && make clean && make...", coming back four hours later when the compile finished (maybe), installing it, then booting to a blank screen back with Slackware 10.

Okay. I am not advising you to do this, but, you can edit /etc/slackpkg/mirrors and comment out your present version of Slackware (put a # in front of your present mirror) and then uncomment a -current mirror of your choice (remove the # in front of the mirror). Save and exit.

# slackpkg update gpg
# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all

Run lilo at the end of this. You will then be running Slackware-current after the reboot. You need to upgrade to Slackware-current if you're going to run a -current kernel. There are risks associated with this.

1 members found this post helpful.

Okay, I've downloaded the kernel-huge-3.14.12-x86_64-1.* and kernel-modules-3.14.12-x86_64-1.* files.

If I use installpkg instead of upgradepkg it'll install the new kernel alongside the current 3.10.17 kernel in /boot, correct? And then I can modify lilo.conf as above, changing filename from bzImage to vmlinuz-huge-3.14.12? I wish to keep the ability to boot the old kernel until I'm satisfied there are no issues with the new kernel.

What is the purpose of the System.map file? Will it cause any harm if I leave the symlink alone for now? It points to System.map-huge-3.10.17 right now. Does anything ever make use of it?

Same questions for config->config-huge-3.10.17 too, but I'm guessing its purpose is just to document what options the kernel was built with.

Actually that's my intention, to upgrade the system to -current. But the document I'm working from specifically says to use installpkg to update the kernel, not slackpkg, but doesn't say how to go about doing that although the rest of the instructions in the document appear pretty straightforward.

It's pretty usual for first try at kernel compilation, it's the way you gain experience. But you have to find what you forgot (missing root filesystems, HDD drivers, video, bootloader config etc)

The slackpkg utility is not recommended for upgrading 14.1 to -current, but, I can tell you from first hand experience that it works without a hitch. I have done this myself many times. The slackpkg utility will upgrade all aspects of your system so that you are running -current. The commands that I listed will work to upgrade your system to --current. You can also run the command # slackpkg clean-system to remove any obsolete programs that remain after the upgrade. Your mileage may vary. Back up your system. Best of luck which ever method you use.

Actually that's what happened the last time I compiled a kernel, not the first. At one time you had to compile the kernel if you wanted support for some particular device (such as a NIC) since all device drivers had to be compiled into the kernel. Now we have kernel modules. But yeah I've been down the kernel compiling route; it's a long, tedious error-prone process that I don't see gaining any real benefit from. Yes I would gain experience but I wonder if the experience would be of any more use in the future than my experience with ipfwadm and ipchains is today.
As it turns out using installpkg for the kernel itself and the kernel modules worked well enough, although I did also have to change the symlink in /etc/rc.d to point rc.modules at rc.modules-3.14.12.

Thanks to all for the help and suggestions.

1 members found this post helpful.

Yup, experience gained mostly to know better what drivers a particular hardware needs.
ipfwadm and ipchains is already old stuff though, replaced by iptables

Yup, my point exactly. When I built my current system nine years or so ago, I ran into a number of issues while setting it up. I don't recall the specifics of any of those issues, but I doubt any of the solutions would have much relevance to the issues I'm running into today with the new system I'm trying to build.

Greetz
While one of the main advantages of Linux is being able to "do it your way" and if it works for you then nobody has the right to say you're wrong. Choices that actually work just amount to tradeoffs that hopefully give the owner a net value. In that vein, I think it is a little bit irresponsible to dismiss a still valuable process to others as something vaguely antiquated and useless like custom kernel building. If you read Alien Bob's "How I build a Kernel" page you'd see that specific CPU architecture, scheduling, and other memory support items are among still important choices, especially to those who game or work with multimedia files, having considerable, even "make or break", impact.

Nobody compiling a kernel ever uses (and rarely ever used) "make config" and running "make clean" after it would destroy anything you did anyway by returning it to generic source. The proper commands were "make mrproper" (no longer needed in 2.6.x) followed possibly by "make oldconfig" and either "make menuconfig" or "make xconfig", etc.

I figure anyone serious would recognize that if someone with as deep a knowledge (and as much on their plate) as Alien Bob would bother to take the time to build a custom kernel AND devote a webpage to precise instructions, that device could not be useless.