How to upgrade kernel?
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: Code:
image = /boot/bzImage What do I do with the System.map.gz and config files? |
Quote:
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
|
Quote:
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: Code:
image = /boot/vmlinuz |
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. |
Quote:
# 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. :) |
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. |
Quote:
|
Quote:
|
Quote:
|
Quote:
Quote:
Thanks to all for the help and suggestions. |
Quote:
ipfwadm and ipchains is already old stuff though, replaced by iptables |
Quote:
|
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. |
All times are GMT -5. The time now is 05:54 AM. |