Building New 2.6.x Kernels For Suse 9.[12]

Hello,

After reading several generic and SuSE-specific kernel build guides, I have arrived at the following procedure which worked very well for upgrading SuSE 9.2 to the 2.6.9 kernel from www.kernel.org. I think it will work for SuSE 9.1 as well.

Feel free to comment on it.

MST



SuSE Linux 2.6 Kernel Build HOWTO
-----------------------------------------

Note 1: For purposes of generality:
<new_kernel> is something like "2.6.9"
Substitute your kernel version string for <new_kernel> in the steps below.

Note 2: It is assumed you have downloaded the kernel source tarball from www.kernel.org.


1) Extract linux-<new_kernel> source in /usr/src

2) cd /usr/src/linux-<new_kernel>

3) make mrproper

4) Copy old .config file to linux-<new_kernel> (if you have one)

5) Edit Makefile and place a "-X" for EXTRAVERSION:
(X can be any number you want it to be)

<new_kernel_name> = <new_kernel>-X

6) make oldconfig (if you are upgrading an old .config file)

7) make menuconfig (or xconfig if you prefer it) (if changes are required)

Make sure ext2 and reiser are built into the kernel, not as modules.
Turn kernel preemption on if you feel lucky - I had problems with some apps in KDE locking up the kernel .
Make sure kernel hacking|Use 4KB for kernel stacks is on.

Subfs: SuSE 9.1 uses subfs which tells the kernel that your drives are mounted
always (like in Windows) without the need to mount them. This feature is not
supported in the 2.6.X_proper kernel, you can ether try to use the source code
from the SuSE kernel and build the subfs module yourself, or edit your fstab to
say:
/dev/dvd /media/dvd iso9660 user,ro 0 0
/dev/cdrecorder /media/cdrecorder iso9660 user,ro 0 0
Make sure you backup the file just to be safe, the fstab is in /ect.

Note for nvidia cards: the Riva option is broken for frame buffer, use the
VESA option which works great otherwise you will get a blank screen during boot.
There is also a option for a linux logo which puts a nice picture of Tux at the
top during boot, you'll find it in the Graphics support sub menu.

8) make clean

9) make

10) make modules_install

11) Edit the grub config file (/boot/grub/menu.lst) and add a new section for <new_kernel_name>. YaST is handy for this.

12) Confirm in /boot that the current running kernel files are named
appropriately - i.e., vmlinuz-2.6.8-24.3-default, System.map-2.6.8-24.3-default,
initrd-2.6.8-24.3-default, config-2.6.8-24.3-default.

13) Confirm that the current running kernel filenames match the corresponding
grub section.

14) make install

15) Confirm that install created the same named files in /boot as you
set up in grub for <new_kernel_name>.

16) ln -sf <new_kernel> <new_kernel_name>

17) If nvidia card is present, edit runlevel to boot into runlevel 3 and obtain
current nvidia driver linux install script (www.nvidia.com).

runlevel 3: use YaST|System|Runlevel Editor -OR- edit /etc/inittab directly.

18) Reboot into the new kernel.

19) Confirm proper operation.
uname -a
lsmod
dmesg | more
ifconfig
etc...

Re-config and rebuild until you are happy with the kernel config and operation.
To do this, return to step 7 above.

20) Copy /usr/src/linux-<new_kernel>/.config to /boot/config-<new_kernel_name>

21) Edit the grub config file (/boot/grub/menu.lst) to use this kernel as default (if desired). YaST is handy for this.

22) If nvidia card is present, build, install, config (sax2), and test nvidia
driver - then change default runlevel back to 5.

build and install: sh NVIDIA-Linux-x86-1.0-6629-pkg1.run (cannot be running X)
config: sax2
test: startx
runlevel 5: use YaST|System|Runlevel Editor -OR- edit /etc/inittab directly.

23) Smile and be happy!

rhe:

Thanks!

I have already - the main differences are:

1) You don't mention the "oldconfig" target. This is very useful to bring the .config file up to the kernel version you are about to build. It only asks you to make decisions for new config items - everything else is left as it was set in your old .config file.

2) I don't think the "sux" step is necessary - you are already running KDE.

3) You don't mention the EXTRAVERSION setting in the kernel Makefile - very useful to keep track of build versions.

4) I don't break out the build into bzImage and modules targets - the 2.6 kernel build environment was improved to allow the building of modules and the kernel simultaneously - why go back to the old 2.4 build paradigm? Besides, I like to follow the instructions given in the README file distributed with the kernel.

5) I provide a few specific things to check such as the SuSE subfs usage in /etc/fstab and how to deal with the Nvidia driver.

6) I use the built-in install target "install" instead of copying things by hand. Again, to be consistent with the kernel distribution. It builds the initrd and names the kernel properly in the /boot directory.

Those are the main differences. I read your post along with others and several online tutorials before doing my upgrade (then documenting it).

MST

I guess everyone got his own ways for doing things, thats one of the advantages of linux.
There are many ways to rome.

Yes, yes, linux is a beautiful thing - especially for desktops
I have been using FreeBSD for servers lately - fewer frills, not great on the desktop, but handles load better and is just faster through the network stack in general.

WRT upgrading SuSE kernels, this has always been my only gripe about the SuSE distribution (and the only thing I liked about RedHat/Fedora Core): it was not straightforward or clean to upgrade your SuSE distribution with kernel source from kernel.org. It is still a bit messy, but thanks to rhe and others I have been able to standardize the process and document it so it is manageable.

MST

I modified the procedure to note the problems I had with turning on kernel preemption. It definitely was more responsive, but I experienced several kernel lockups (jedit and konquerer).

MST

I have used xconfig many times in the past - somewhere around SuSE 8.2 or 9.0 it was corrupting .config files. That's why I have been using menuconfig. I used xconfig over the weekend with good results, so it must be fixed now.

MST

BTW, where is Storm going?

Your procedure is too riddled with idle mental wanderings for my taste. It also does not follow the build procedure as documented in the kernel README file.

But it was a decent starting place along with some other better sources.

MST

Originally posted by mteel@Nov 30 2004, 20:54
BTW, where is Storm going?

Storm is not going anywere.

Except maybe the bar.

Originally posted by 69_rs_ss@Nov 30 2004, 22:29
Except maybe the bar.

You got an good point there 69_rs_ss B)