How Do You "Drop In New Kernel" For Slack?
 

Hi all,

Well I've come to the point in my slackware experience now that I can really screw things up, so here it goes LOL.

I thought I read somewhere on the internet, that with Slackware you can just "boom" drop in a kernel patch and zip zip your updated to the latest greatest.

But for the life of me I cannot recall or find the web-site that I saw this at.

I figured it would be a great way to kill some time Hhahahah.

Does anyway have a link to a nice how to?

Thank you in advance.

stick with the old but gold:

http://www.linuxquestions.org/questi...d.php?t=127095

Old and gold, but it will take you hours to extract the correct information from that thread... it staggers from left to right all the time.

This is a short recap of how I build my 2.6 kernels.
====================================================

*** Update: ***
I copied this guide to my Wiki page at http://alien.slackbook.org/dokuwiki/...kernelbuilding so that is does not drown in this forum after a couple of days.
***

I run the commands from a X terminal, and at some point start the X based kernel configurator. I run my desktop as "myself" but I build my kernels as root. In order to let root use my X display, I do the following in my X terminal: get root rights; merge my own (alien's) Xauthority file with the one from the root user, and set the DISPLAY variable. After doing that, I can run X applications from the "su" terminal.

Now that the build environment is set up, continue with the sources.

Download a new kernel, unpack it into /usr/src and create the "linux" link so that the commands are a little more generic. I will take a kernel version of "2.6.16.15" as an example. If yours is a different version, you'll know where to change the version strings in the rest of the story below.
You will probably notice more linux-* directories in /usr/src but it is common to let the "linux" link point to the kernel you are working with.

Now, get a Slackware kernel config file for a headstart during your own configuring. Pat's config files are pretty generic. By the time you read this, there might be a config for a newer 2.6 release available:
Run "make oldconfig" in the kernel source directory so that the defaults are used from the .config file you just installed. Because your kernel sources are probably newer than the .config, there will be new options to choose from. You will only have to answer these (press ENTER for the default answers which are mostly fine, or "m" to build new drivers as modules).
You now have configured a pretty generic kernel (that is the reason why Pat calls them "kernel-generic" probably :-) but you will want to change some of the defaults to suit your needs. Run the X based configurator (if you do not run X but are at a text console, just run "make menuconfig" to get the curses-based dialog program instead)
Walk through the forest of options. What I change is:

* build the ext3 and reiser fileystem drivers into the kernel instead of compiling them as modules - I do not need to create an additional "initrd" then (see under "Filesystems" in the configurator).

* enable support for dual procesessors and hypertreading (under "Processor type and features" > "Symmetric multi-processing support").

* enable 4GB of RAM. The Slackware default setting is to only support ~800 MB of your RAM, so any additional installed RAM is never used! (under "Processor type and features" > "High Memory Support (4GB)").

* enable the "low-latency" kernel if you run a desktop/laptop computer (under "Processor type and features" > "Preemption model" > "Preemptible kernel").

* set a 1000Hz timer (under "Processor type and features" > "Preemption model" > "Timer frequency").

* ... and more I can't think of right now. You can decide to disable a lot of the modules that the default config will build, to cut down on time, if you don't have the hardware in your computer. You could also looka at software suspend and CPU frequency scaling (under "Processor type and features") if you own a laptop.

And finally save your configuration if you're satsfied.
Now, start the build of kernel and modules, and install them to the proper places.

Edit /etc/lilo.conf and add a new section for your new kernel. Remember, your new kernel may not even boot if you made a mistake somewhere, so you will want to leave the sections for your current kernel(s) intact. Your current /etc/lilo.conf will have a section somewhat like this, near the bottom of the file:
Add another section just below (adding it below will guarantee that your current kernel will remain the default to start):
After adding a stanza for your new kernel to /etc/lilo.conf and saving the file, run lilo to activate your changes:
Now is the time for a reboot, to test the results! In the lilo boot screen, select the "newkernel" option instead of the default "linux" option.
If the new kernel boots fine, you can add this line to the top of /etc/lilo.conf and re-run "lilo":

Other packages that contain kernel modules

Most certainly you will have packages installed that contain kernel modules that are not part of the default kernel. Slackware has "alsa-driver" for instance, and if you installed any wireless driver, these are basically kernel modules too.
Now, with the installation of your new kernel, you will lose these modules, and you have to recompile the sources so that the binary modules match the new kernel.
You can get an overview of all packages that have installed a kernel module for your current kernel by running this command (i.e. you must run this command while still running your old kernel):
All the mentioned packages will need a recompile.

For ALSA you have a choice: either enable the ALSA driver that is part of the kernel you've just downloaded, or leave the kernel configuration like Slackware's: disable all ALSA support in the kernel and instead re-build the alsa-driver package.

Good luck with it all!

Eric

Very good guide, Bob, but...Patches are a little different. For example, I just did a patch last night.
You need:

• The kernel patch (right now, latest/greatest is 2.6.17-rc3
• The next lowest 3 number kernel (in this case, 2.6.16)
• Beer, Whiskey, or 'relaxant' of your choice

Unpack/untar kernel source and patch. I put them in separate directories in /usr/src.

cd to your source directory, and typeAfter patch is complete, continue as usual.

What is the 'relaxant' for? Something, somewhere, may go haywire. Patch won't work right. You didn't use a 3 number kernel. Your dog pees on the keyboard. Whatever. Just keep trying. I had to do mine 3 times last night to get the driver I need for my wireless to show. (That's what I get for doing it the first time a few weeks ago after getting home from driving 1100 miles that day, being totally tired, and patching/compiling. Woke up the next day, and everything worked....Too bad I didn't write down what I did)

Patching does get you the 'bleeding edge', but can be a hassle

BTW, Bob, EXCELLENT tip on the merge idea. THAT has been driving me bonkers for awhile.

I wrote a little How-To on it. Hope it works if you decide to use it.

Guide

Alien Bob: wow! Thanks for taking the time to type all that out for us newbs trying to work up the courage to compile a 2.6 Kernel. This will save me TONS of time.

Thank you for the help guys. I've been able to compile kernels as cwwilson walked me thru a few weeks back, however there are so many things in that long thread and Eric's post that I did not know. The "merge" for root using a users window for one, and finding out which modules are needed too..very nice.

cwwilson, how long does it take for the patching to run assuming that the patch worked the first time? when I compile a kernel it takes about 10 minutes on my pc to do "make". does that save alot of time?

and I guess lastly, could you simply tar/archive your current kernel before you do the patch and if it didnt take just restore/overwrite by untar and try again?

You could do the 'tar' thing, It can help.

Patching took me about 1 minute. It modifies the kernel rather quick

Very nice. Thanks.

Yeah for sure this is really good.

Anyone use any "optimization flags" when they run make? I heard it can make the "make" go faster.

What a great post Alien Bob! Slackers are amazing, no doubt

great write up on kernel compiling!
Hope you include more options you choose during xconfig for the benefit of newbies like me.

Yeah truly a great write up. My only problem with kernels now is finding out Should I or shouldn't I include the IPV6 at all in my kernel compiles? If I put the ipv6 in, now I could be doing it wrong, but I get a ton of errors. Maybe my guard-dog is too old? DOesnt' support it? or I'm not supposed to have ipv4 and ipv6. I gotta read into it to be honest.

I saw cwwilson posted his kernel config I'm gonna go check that out and see.

I can expand that post of mine, if people are interested. What I'd like to know, if my story added more insight after having processed DaOne's "kernel compile guide for 2.6"? What did you miss in either threads that you feel is missing from the "newbie" point of view?

I'm thinking of copying the instructions into my Wiki so that I can polish it further and make it more "sticky" - like the two posts up here in the Slackware forum.

Eric

I believe what was "new" news to me, tho it might have been in that thread and I really dont have the time to double-check was:

"make bzImage modules" I didnt know you could do that at once. I liked Shilo's thread but he uses gnome. To me gnome is like mac. I dont like mac. So I dont use gnome. sorry gnome writers. so i used the slackers bible to learn how to compile and it was not written there that way.

giving root the user's console view was definitely new to me. this will stop me from having to pull the network cable when i load then install everything and set it up while running as root to do so in the beginning, altho now that i've gotten further i just drop out of X and go. this saves time. was totally new to me.

the wget was nice as I didnt know how to do that for kernels. i've used it on other distro's when i first started out.

i think you may want to add about the gpg import key feature of the kernel archives and gpg verify.

the tips you added were dead on, short and sweet. the only issue of concern for some of those items from what i read is if the user wants to use ndiswrapper. you may want to caution on 4k v 8k stax.

the listing of modules was only new to me even now.

Eric, I think the beauty of your post compared to many web-sites or other wiki's was that it just listed the commands in a row. The user can see that it's only about 10-15 steps to do it and get done. You get the impression that "hey i can do this". Whereas web-sites go in to explaining, spread out over many pages, etc which is good, but tends to leave you with the feeling of "oh my god what am I about to get myself into."

I think if you do a wiki you keep it short...put a quick link like this {1} which points to a different page if they want a description of what that all means, but just keep it running down like a quick cheet sheet. Not inundated with words. Just here's what you do, boom boom go get pizza boom boom done.

You may want to touch on compiling on one pc and copying it over to another.

Hope that the above gives you the feel for someone like me, just 2 months or so just into linux thinks.

The thing that sets your write up apart from the other write ups I've seen is all the wordiness the others writers put in between steps, which is great for explaining whats going on, but tends to make me lose the continuity of the process. I like Old Fogie's idea to link to pages with further explanation. Also some other write ups even said 'do this and that step as outlined in this write up from previous versions' which again is totally do-able, but makes it that much harder to follow. I like how yours lays it out. I can "see" the process more easily.

I hope that doesn't make it sound like I dont appreciate the effort the others have done, just saying why I liked yours so much. I think it'd be awsome if you expanded it, especially since I'm about to take the leap and compile a 2.6 kernel on my laptop(last 2.6 compile didn't go real smooth (on my old desktop) so I'm a bit nervous since my system is working like a clock so far).

I copied my kernel compile guide over to my Wiki pages and will keep updating it there. Thanks to Old_Fogie, I added a chapter on verifying the kernel archive's GPG signature.
I will also add this link to my original post in the thread. Comments are welcome on the "discussion" tab in the Wiki page.

Eric

hiya, well i'm running a make right now following your site and this thread at same time.

I'm going to try and use the same kernel that slack current is runnning. I wanna see if I can get video to work for me in slack10.2 w/the latest ATI drivers.

You know I'm going thru your site and still finding some things I didnt know, or catch my eye :D

Let's hope it works.

hmmm...doesn't this need to be two lines?

look like this:

I tried it as one line like you had, and console said: ln: `System.map': File exists

and should I do this at all?

in my /boot directory before I do lilo?

yeah... it's a typo... you could also just separate the commands using a semicolon...ordoesn't really matter... lilo won't care either way... config links like that are usually just to make things easier for the user... so for example, like, to look at my current config i'd just need to do a "less /boot/config" instead of typing-out the whole version number and stuff...

Oh Ok thank you.

Hey I got my radeon working in a 2.6.16.19 kernel now :D

I told all the fella's in the DRI in slackware thread at http://www.linuxquestions.org/questi...90#post2275190

Thanks again Eric.

I never thought of using the generic config from testing to use for me now here. I had been using a 2.4 upgraded to a 2.6.10 and then tried going up to higher, and I couldnt seem to get it right.

Now off to add in real time Anti-Virus protection and play w/my Dazuko. :D

Bye.

I like this thread, it has all of my favorite posters in it :)

I had a quick question about this:
I don't have a big background as far as Linux knowledge goes, I just kind of figure stuff out by playing around and reading my system files (which could probably be quite dangerous ...good thing I have nothing important on my computer) Anyways, root being denied access to my users X sessions was really starting to piss me off so I was able to fix it by doing this as root:
which I had to add to my '/root/.bashrc' since it broke every time I reloaded X. I was wondering what the difference was between your method and mine. I'm not really sure what my method actually does, other then the fact that it seems to work. Does your method add anything extra or is it more secure/less buggy? I only ask because I'm not just happy with something working, I like to know why something works. If anyone could elaborate more on what is going on behind the scenes with all this .Xauthority stuff, I would greatly appreciate it.


Also, in regards to kernel compiling; I am a pretty lazy person so I made a small bash script called 'makekernel' that backs up my existing kernel to vmlinuz.old/System.map.old then runs all the commands to build the kernel in '/usr/src/linux'. This way lilo always has the option to boot to the last good kernel and I only have to run one command to backup/build my new one. Just wanted to put that out there for any other lazy people that might read this.

regards,
...drkstr

**edit**
oops, I meant vmlinuz, not bzImage

I also :D


WOW that's really, really intense.

:D Thanks but it's not as hardcore as it sounds:

And in my lilo.conf:
Not much to it. I just typed the commands into a text editor instead of the console.

regards,
...drkstr

this part here the "make clean" i've seen written on the net a few times, that and "make mrproper"

would that be done on a sytem that already has a custom kernel sitting on it?

for example tonight, I compiled this new kernel on a new install of slack. so i should think that I dont need to do "make clean" right. But additional kernel compiles I probably should?

does that sound right?

if you have previously run mrproper on the source you are building, then no - you won't need to run mrproper again (although it doesn't hurt)... as for the clean, it's recommended that you do NOT skip the clean before you start the build (make bzImage, etc.)...

http://www.digitalhermit.com/linux/K...ild-HOWTO.html

Well, your method works OK, and there is nothing wrong with it as long as you are the only user on your computer.
Basically, you make the user root use the X "magic cookies" for your own account that are stored in your own ~/.Xauthority file, so that as far as X is concerned, there is no difference between user "you" and user root accessing the X display. If you were to create a second user account "you2" and that account were to run X, then again you would not have the possibility for that user "you2" to do "su -" and start X applications as root.

My way of doing things is better if you have more than one user account on your computer that you use to run X sessions. The command exports the X cookies out of "alien"s ~/.Xauthority file and merges these with any cookies already present in root's ~/.Xauthority file. That way root can accumulate X authority cookies from many users.

A second reason to avoid making a symlink is that I never like symlinks that point from root's homedirectory to files in other users' homedirectories - it adds a way to hack into root's account if you mess with the file that the symlink points too.

NOTE:
By the way Old_Fogie, I fixed that typo in the Wiki page.

Eric

My newest box is an AMD64 with 1Gb RAM. I've been playing with it for over a month, but I'm still using the stock kernel. I just checked, and sure enough, I'm missing some RAM. I hadn't even noticed. One thing's for sure, Linux keeps me humble. Every time I learn something new, I realize that there are 100 more things I don't know.

Thank you for the information.

i allways use the same steps to install a new kernel, exept that
i keep the sources in my home directory.
( i just have a dir. ~/kernels/ )

that has some advantages like:
-no need to be root to place and extract the sources.
(extracting tar archives as root is "dangerous" )
-root doesn't need the X-screen as you do the config step as normal user.
-if you want to do a fresh ( clean )install for some reason, you don't have to backup the
tarball of the kernel you use ( if you have a separate /home partition )

this is also the advised method to install a kernel.
see the README-file in the kernel-sources.
is there any special reason to use /usr/src instead ?

egag

You brought up a great point of mention. I've actually done about 2 hours searching these forums and the internet on this topic of making, building your kernel in a "sandbox" in your home directory, And you're right, supposedly we're not supposed to remove the linux symlink in /usr/src.

Apparently this is a really hot topic. I've seen arguments for both sides. But I heard one very good point someone made that said if you remove your existing symlink e.g. /usr/src/linux put in your new kernel you are fine, as most programs pull to 'uname -r' anyway so that you should be fine. Many times programs like alsa need to be recompiled or built into the kernel because they are kernel dependent. For example, madwifi wont work if I boot into my 2.4 kernel but will if I go 2.6. The generic programs dont seem to mind, oofice, kwrite.

I play it safe. For me, I load up slackware w/the default kernel. Put in all my programs then my updates, except video and wireless, the put my new kernel, then my dazuko/antivirus and video and then I'm done. I only keep the stock kernel and my tweaked kernel on my daily slack.

If I want to play w/a new kernel I have another partition that has an exact copy of my slackware's regular default install, and I play there and make my packages, etc. Then when I'm done playing/testing I dump it and do the final install on my regular daily slackware install. I can afford the 3 gig extra to have a full install playground that seems to be really best for me. I make alot of typo's :D

My mind works this way on this topic. Mr. Pat V recommends all noobs to come here and use the forums. Most people in these forums who are helping me go this route of building in /usr/src/linux, Shilo, Eric, cwwilson, drkstr, etc. If they're doing it this way, I dont wan't to be different really becuase I've really been relying on their help, and to date these guys never let me down. :D

I would also hope that Mr. Pat V probably hits these forums once and a while to see what we're all saying. I'd think that if he really felt it were that taboo, he might intervene. LOL, he probably loves the thread where everone says they 'hate Pat' for making us all slackware junkies.

Bye for now.

These are both very good reasons, particlarly the last one. I only have one user so I didn't really see the negative effects of this mehtod before, but now I can see the error in my ways ;)

Thanks for the input!

FYI

2.6 kernels have a new option for:
Memory split (3G/1G user/kernel split (for full 1G low memory))

which is right bellow himem support. This will still allow for full use of 1G memory while not taking the hit in performance with using himem.


regards,
...drkstr

I just finished compiling my kernel. I've been putting it off for a month because I wasn't really confident about doing this with an SATA drive. The timing of this thread couldn't possibly have been any better. The docs earned a place in my red 3-ring binder.

Drkstr... thanks for the memory configuration tip. I have a lot more available RAM now than I did earlier today.

Great thread!

Wow. Should have checked back on this thread. The info is blowing my mind.

I just hope this DOESN'T turn into 'Well, I compile this way...' thread.

As we all know, put 5 Slackers together to compile a kernel, you'll end up with:

5 different kernels, 4 of which work, 3 different threads, 2 kernels that boot, but still don't have all the stuff you need, and at least 1 newbie who goes back to Windows.....

The info in this thread has made many things clear.

And kudos to Eric, for parting some of the fog.

And to Old Fogie, who had the guts to do four things:

1. For asking questions
2. For looking for solutions, here at LQ, and elsewhere
3. For posting his results, good and bad
4. And for sticking with it.

Keep it up, everybody.

Sorry, another addition (kinda off topic):

I think I may need to explain why and how I do things here.

I have between 5-8 computers running at the house here, from laptops to blade servers, running Slack 3.1 (an old Compaq I setup years ago to be a modem server, isolated from my other networks, and still humming away...), Slack 10.2, 1 laptop running 'current', and 3 XP boxes. (5-8 because I'm always upgrading, and hardware does break...)

I use the 'current' laptop (the one I'm writing this on) as my only link to the internet on this network (3 networks here...long story), and as my 'mess about' box. The reason for this is manyfold:

1. The hardware is older, so it is well supported
2. The hardware does not change
3. I don't really care if I mess it up, it is not critical to anything for me.

What I do is experiment with the laptop, then apply the knowledge to my 'critical' boxes, thus saving me tons of grief, and downtime.

Great thing about Slack: My servers (web, mail,news,nfs,samba, and ADS) are rock solid, and my desktops are up.

I beleive it is because of my 'laptop first'policy...lol

But I also do things different on the laptop, because I couldn't care less if it gets hacked or crashes. It won't affect the other networks. So I get sloppy with it, compiling shortcuts, testing software, etc, and security goes out the window on it. It is my 'garbage can', I guess.

So the kernel config files are from one setup of this laptop, the xorg.conf is from a different 'install', etc... (I don't and will NEVER reveal what confs and stuff is running on my critical stuff.)

So if you do use my files, they may, and probably do, have gaping security holes in them, but I post them for reference for others to use.

Just my 2cents...

BTW, I'm a 'favorite poster' now? How the heck did that happen?....Where did these kids in my house that call me Dad come from? When did I buy a house? When did I graduate from school?
And, worst of all, where is my Geritol?

I agree CW, it's really a good idea to have a pc you just play with and test. I use a separate partition, but same theory.

Regarding, not disclosing what you do on your mission critical. I can definitely understand that.

I chuckled at your analogy on # of slackers vs. the outcome of their kernel compiles ahahahah. Very funny.

of course there are more ways to get a new kernel installed, and there
is not one that's " the best".( that's why some discussions never stop :) )
if you have found a way that works for you, just stick to it.

but working in a "sandbox" in your own home-dir. has some advantages.
( ...and maybe also disadvantages ? )

but the symlink you mention ( /usr/src/linux) is never used.
if you compile some sources that need the headers of the kernel that's used,
the link "/lib/modules/<kernel-version>/build" is used to find the sources.
( this is the case with kernel-modules like alsa, madwifi, nvidea-& ati-drivers
and such)
other programs won't mind.

someone on this forum has a sig :" there's no answers, only choices ".
that hits the nail on the head... :)

egag

Hi all,

I'm trying to do a kernel on ubuntu so it runs faster in qemu, and while doing that kernel compile, I noticed something that may ?? be helpful on my slackware boxes and was wondering if you had any thoughts or experience with this.

edit forgot link sorry:
http://ubuntuforums.org/showthread.php?t=157560

Basically, If you look at this ubuntu guide for kernel compiles, the ubuntu folks recommend applying a "performance patch" before compiling a new kernel.

Now I thought that at first that this was an 'ubuntu' specific thing at first, however, the files that you use to compile a kernel for ubuntu is from kernel.org and it's a standard kernel.

Is there any advantage to me doing this on my slack boxen? Has anyone done this?

Thanks.

If you live on the razors edge and don't mind bleeding. Calling the patches performance patches is a misnomer. Your best bet for performance is to customize .config for your specific setup and use

make oldconfig

on the updated kernel trees to make a decision on the new features that are being added. If following the changelogs you see something that you really want that works if you update with the patch, by all means grab it.

Hiya! :D

Yeah I'm thinking that the performance patches really dont do anything on ubuntu, so I'm not even going to bother for slackware.

It was really just "a hmmm...is that a good tweak for me" kind of question ya know.