LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Build scripts for 3.0 kernel? (https://www.linuxquestions.org/questions/slackware-14/build-scripts-for-3-0-kernel-893852/)

storkus 07-26-2011 09:06 AM

Build scripts for 3.0 kernel?
 
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).

Any suggestions on either option?

Thanks, Mike

willysr 07-26-2011 10:15 AM

I don't think there will be a big changes in the script, since it's just a numbering issues as Linus said

compiling a Linux kernel will take about 1 hour on my case

Woodsman 07-26-2011 10:38 AM

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.

tuxrules 07-26-2011 02:55 PM

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 2.6.39.3 so I don't believe anything went wrong because of missing drivers.

dive 07-26-2011 05:55 PM

The problem seems to be that although the source is 3.0, the uname is 3.0.0. There seems to be a problem with depmod working with 2 digit numbers.

Upshot is make the $VERSION 3.0.0 in whatever script you use for modules.

My kernel+modules script still works fine (update 2 boxes over last couple of days without problems)

http://www.dawoodfall.net/index.php/kernel-packaging

storkus 07-26-2011 08:29 PM

Quote:

Originally Posted by willysr (Post 4425602)
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.

Thanks again, everyone!

PTrenholme 07-26-2011 08:43 PM

For what it's worth . . .
Code:

$ uname -r
3.0.0-1.fc16.x86_64

<edit>
Oops! :redface: I didn't notice that this thread was in the Slack forum.
</edit>

dive 07-26-2011 10:02 PM

Quote:

Originally Posted by storkus (Post 4426176)
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'.

storkus 07-27-2011 12:29 AM

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...

qweasd 07-28-2011 08:57 PM

I waited till 3.0.0 went stable (which, by the way, just happened). Making it was enirely uneventful. My install script (below) worked perfectly just as it was. uname seems to work fine:

Code:

Linux ghash 3.0.0 #1 SMP PREEMPT Thu Jul 28 13:39:02 EDT 2011 x86_64 Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz GenuineIntel GNU/Linux
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

Code:

#!/bin/bash
LINUX_SOURCE_PATH=/usr/src/linux
IMAGE_PATH=arch/x86_64/boot/bzImage
INSTALL_PATH=/boot
VERSION_MAKEFILE=version-makefile

# Exit on most errors.
set -e
# 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.
cd $LINUX_SOURCE_PATH
head -4 Makefile > $VERSION_MAKEFILE
echo -e 'all:\n\techo $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)' >> $VERSION_MAKEFILE
KERNEL_VERSION=`make -s -f $VERSION_MAKEFILE`
KERNEL_RELEASE=`cat include/config/kernel.release`
if [ $KERNEL_VERSION != $KERNEL_RELEASE ] ; then
    echo "Kernel version $KERNEL_VERSION differs from release version $KERNEL_RELEASE. Aborting." >&2
    exit 1
fi

# Install modules and the image, build initrd.
make modules_install
cp -v $IMAGE_PATH $INSTALL_PATH/vmlinuz-$BRANCH_NAME-$KERNEL_VERSION
cd $INSTALL_PATH
mkinitrd -o initrd-$BRANCH_NAME-$KERNEL_VERSION -k $KERNEL_VERSION



All times are GMT -5. The time now is 05:19 AM.