SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I'm frankly amazed no one else has brought this up yet (or so my searches keep coming up empty), so here goes: has Pat or anyone else come up with build scripts for 3.0/2.6.40 yet? I imagine there has been enough changes that the 2.6.39-rc4 script may not work properly, but I really don't know.
I used to just manually compile my kernel after a clean install with just the drivers I needed, but with so many new bells and whistles, I'm not sure that's justified any longer, especially since the last time, configuring from scratch took 3-4 hours as I recall (in the 13.0 days).
I recall reading an article that the new kernel numbering is not a problem with building the kernel but causes problems for other packages. Mostly because build scripts and source code for some apps are hard-wired to look for 2.x, such as through the uname command.
I built v3.0 for fun yesterday and it booted fine until it wanted to use uname -r. That's when the system froze and had to do a hard reset. I switched back to 39.3 and all's well. Like Woodsman said, there is certainly uname but there may be others.
BTW, I did make oldconfig from 220.127.116.11 so I don't believe anything went wrong because of missing drivers.
compiling a Linux kernel will take about 1 hour on my case
That's 3-4 hours CONFIGURING a kernel--by hand, through "make menuconfig" usually. I suspect it may be upwards of 5 hours now. I'm really not sure I want to spend half a day going through all those menus. And then, because it's such a mess, I usually have to go in there again 3-4 times to turn something on or off because I've forced certain things off that turn out to be dependencies or vice-versa. I dearly wish they would clean up the configuration (group things in a more sensible fashion)--it would cut a lot of time out, IMHO.
COMPILING on my dual-core 1.9 GHz Turion X2 is normally less than a half hour since most of that work is removing drivers and other fluff Pat and the boys included but that doesn't exist on my system; back in the old 486/early Pentium days, you could get a huge speed up by getting rid of all that crap. Now it just seems to speed booting, though I haven't done any serious profiling.
As for the hard-coded 2.6 issue in uname, thanks, everyone, for the tip. Since all the drivers seem to work in 2.6.37 other than Nouveau (and I've decided to ditch it in favor of the proprietary blob--not happy, but KMS royally sucks), I guess I can just stick with that unless some of you know of some reason I should really go with 39.
That's 3-4 hours CONFIGURING a kernel--by hand, through "make menuconfig" usually. I suspect it may be upwards of 5 hours now. I'm really not sure I want to spend half a day going through all those menus.
Well once you have a working config keep hold of it for next time. Also don't forget 'make oldconfig'.
True, I keep forgetting about "make oldconfig". Again, though, the whole deal about compiling a custom kernel (for me, anyway) is to get rid of drivers (and their variables, dependencies, etc) taking up space in the kernel that I will never use. I can reduce the kernel size by 1/2 to 2/3rds by doing this, and that's with all my important modules compiled in. With faster machines, though, is it really worth all that effort?
And then there's the crap I don't completely understand, like cgroups and friends: I don't think I have anything using them, but that doesn't mean I won't have some program that wants things like that. The bottom line here is that the kernel is a whole lot more complicated than it was even just 5 years ago, so I tend to defer to Pat and the boys to be sure I don't really screw something up--haven't done it so far, though...
The old NVIDIA blob, of course, could not see the kernel at all, but the latest NVIDIA-Linux-x86_64-275.21.run worked. Having a free driver is great, since I am able to have working X while figuring out how to fix the blob. I really wish I had Intel and didn't have to deal with this.
I used to make kernels to get rid of drivers, but that doesn't seem to speed up anything in any kind of major way. These days I just do it for the sake of running the latest and the greatest. Pat's
generic config with a few changes that actually matter (like to PREEMPT and IA32_EMULATION) works out really well.
The script below will try to install the kernel, the modules, and the initrd automagically. It is basically a glorified make install that tries very hard to give the new kernel a good name, like vmlinuz-stable-3.0.0
# Exit on most errors.
# Customize the name of the installed image.
b=$( for w in $1 ; do echo $w ; break ; done )
if [ -n "$b" ] && [ "$b" = "$1" ] ; then BRANCH_NAME=$1
else echo "Supply a one-word branch name." >&2 ; exit 1 ; fi
# Extract kernel version.
head -4 Makefile > $VERSION_MAKEFILE
echo -e 'all:\n\techo $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)' >> $VERSION_MAKEFILE
KERNEL_VERSION=`make -s -f $VERSION_MAKEFILE`
if [ $KERNEL_VERSION != $KERNEL_RELEASE ] ; then
echo "Kernel version $KERNEL_VERSION differs from release version $KERNEL_RELEASE. Aborting." >&2
# Install modules and the image, build initrd.
cp -v $IMAGE_PATH $INSTALL_PATH/vmlinuz-$BRANCH_NAME-$KERNEL_VERSION
mkinitrd -o initrd-$BRANCH_NAME-$KERNEL_VERSION -k $KERNEL_VERSION