Building a kernel from source.
hi all, is alienBoB's howto
http://alien.slackbook.org/dokuwiki/...kernelbuilding work for a 3.* kernel? |
Yes. But if you are building a x86_64 kernel, you won't have to enable 64GB of ram. That kernel will already see all your ram. Good luck! Building a kernel is a great exercise.
|
Thanks mlangdn, I only have 32 bit systems.
|
Works. Actually, I am running kernel 3.4.11 on Slackware64 current. I just picked up config file from testing/, two options changed(processor family & Preemptible kernel) and followed Alien's instructions.
|
I've been using the smp kernel when using 13.37, should I be using the generic config for single core?
|
No, unless you have a very old CPU. If you hit "F2" at time of choosing the installation kernel this will be reminded to you:
Quote:
But maybe your question was more "should I choose a generic kernel, versus a huge one". If that is the case, and whatever you CPU be, though not mandatory switch to generic is generally recommended as in some cases having conflicting drivers buit-in *could* cause problems. |
Quote:
|
It seems I've quoted /isolinux/f2.txt included in Slackware 13.37 instead of Slackware current. Oh, well...
|
|
Then you can safely use the smp kernel. As side note, the output of "uname -p" would have been sufficient.
|
Has anyone tried starting with a config from http://kernel-seeds.org/? I was going to try this at some point to get the latest kernel running, our of curiousity not necessity, but haven't had the time yet.
|
Quote:
I just had a look there and would advise anybody wanting to tweak their kernel's configuration or install a newer kernel not included in Slackware to use one of the config files shipped with Slackware (either in /boot or in /testing) as a basis, copy it at the root of your (possibly new) kernel source tree then run "make oldconfig" followed by "make xconfig" instead. As for taking in account your hardware configuration e.g. running "lspci -k" or "cat /proc/cpuinfo", of course you can do that yourself. Use the search feature (Ctrl+F) of "make xconfig" to help you finding you way in the kernel tree and don't forget to edit the LOCALVERSION string to avoid overwriting the stock kernel and modules. |
Ok, i'm using this new kernel. I want to create a kernel package, so when I reinstall I don't have to keep building the kernel. Would the script on a previous post on LinuxQuestions work?
http://www.linuxquestions.org/questi...ackage-369142/ Maybe modifying it to add my .config file for building. |
I would suggest you use the SlackBuilds provided in /source/k instead. You will have to replace the source tarball and its signature file, the config file and either edit the VERSION variable in the relevant SlackBuilds or execute them like this : "VERSION=<your kernel version> /path/to/the/SlackBuild"
|
Thanks Didier Spaier, i'll give that ago. :)
|
Fresh off of burning my fingers with the soldering iron, I had a thought about this.
If I'm running multilib and I upgrade my kernel, is there any reason I would have to roll my own multilib to go with my new kernel? Or could I keep using Alien's (currently from 3.2.29) without problems? Of course the 3.2.29 header files would still be there, but let's say I was running a 3.5.4 kernel? Or maybe it's just the bacon smell that's getting to me?! :) |
Quote:
|
I have a question about the kernel headers and glibc.
I am making packages for kernel-source kernel-huge and kernel-modules on my slackware 14.0 64-bit system. The kernel-source package is done and I'm using 3.0.49 source tree. Nice build scrips from slackware.com will be used to build renaming pkg. Witch is kernel-huge, kernel-modules and ?? kernel-headers ?? ?? rebuild glibc ?? (there is no builds script for kernel-header,only a slack-desc file?) If the software is built from glibc that is built from kernel 3.2.29 headers and now will be running along an older kernel like 3.0.x . will my software still sync, work and compile correctly with older kernels runing? I think like this: software ---> glibc/elf ---> 3.2.29 headers -?-> >>>older kernel running different instructions<<< Wish Linus was here now. But any answer is better then none. |
AFAIK there is no need to rebuild kernel-headers nor (hopefully!) glibc.
the kernel-headers package simply copy headers from the kernel tree to /usr/include, this is why: (1) There is no need for a SlackBuild for it. (2) These headers (in /usr/include) won't be overridden if you install a new kernel-source, so there is no need to update them when you install a new kernel-source package. Oh, and in any case the sanitized kernel headers should be there *before* you re-build glibc (which is hopefully not necessary in your case anyway) as noted in glibc.SlackBuid: Quote:
|
what kind of error could show up if there where problems.
or how do I know if I need to downgrade headers and rebuild glibc? what symptoms do I look for or how to test if I'm not the lucky one? I mean if my kernel boot and nothing special happens, can I just go on and forget about it ?? |
Don't worry, just try and in case something looks weird, come back here.
Only add a new entry for the new (I should say old) kernel in /etc/lilo.conf instead or erasing the old one, just in case. |
With Alien Bob instructions and the .config from http://mirrors.slackware.com/slackwa...sting-3.6-rc4/ the 3.6.3 and 3.6.4 kernels works with only one new module not set on .config .
I'm also changed preemptive processor option and hostname, without any problems. On Alien tutorial need to change the x86 or x86_64 part of copying the new bzImage from tree if you're running x86 or x86_64 .config . |
All times are GMT -5. The time now is 04:54 PM. |