HOWTO: Realtime 2.6.20 kernel!

Share your own howto's etc. Not for support questions!

Postby jongi » 2007-05-12 17:37

Using lenny/sid and trying to compile 2.6.21.1 and I found that I had to change the line in /etc/kernel-img.conf to

Code: Select all
ramdisk = /usr/sbin/mkinitrd.yaird


from

Code: Select all
ramdisk = /usr/sbin/yaird


Also, when I re-run the nVidia driver installer, x no longer starts on the old kernel and I have to reinstall for the old kernel. But then that means if I want to use the new kernel I have to rerun the installer again for the new kernel.
jongi
 
Posts: 477
Joined: 2007-04-15 02:41

Postby berti » 2007-05-24 22:25

fvs wrote:After doing all of the above I tried to install, But got this,
LD .tmp_vmlinux1
kernel/built-in.o: In function `clocksource_watchdog':
clocksource.c:(.text+0x15541): undefined reference to `tick_clock_notify'
make[1]: *** [.tmp_vmlinux1] Error 1
make[1]: Leaving directory `/usr/src/linux-2.6.20.3'
make: *** [debian/stamp-build-kernel] Error 2
debian:/usr/src/linux-2.6.20.3# dpkg -i *.deb
dpkg: error processing *.deb (--install):
cannot access archive: No such file or directory
Errors were encountered while processing:


Hi. I'm getting the same error when trying to compile the kernel with the patch applied. Did you get around this problem?

Also, does the patch-2.6.20-rt8 only apply to the 2.6.20.3 kernel? Or is it suppossed to work with any 2.6.20.x kernel?

Thanks in advance
Happy cat
has run out of happy :(
berti
 
Posts: 1
Joined: 2007-05-24 22:21

Postby jjmac » 2007-05-24 23:11

thamarok,


A bit feeble for a HOWTO.


Not only do you not mention the required development packages for the gtk based configuration front end, but you don't mention them later when it is obvious that they are not installed on the persons box.

And you don't give mention to the compiler packages, make, or anything to do with the compilers tool chain.

Also,

fvs wrote:
>>
Started all over from scratch got to this point and here i got stuck,

apt-get install libqt3-mt-dev
make xconfig

bin/sh: g++: command not found
make[1]: *** [scripts/kconfig/qconf.o] Error 127
make: *** [xconfig] Error 2
debian:/usr/src/linux-2.6.20.3#
>>


Then thamarok writes:
>>
Run xhost + before that.
Try also apt-get install g++
>>

Then thamarok writes further:
>>
Try running it with sudo
I'm running out of ideas; it has worked for me every time I tried
>>

thamarok, obviously the compiler availability is incomplete, or not available completely. Which suggests there may be other missing compiler related packages as well ...

Where you got the idea that a ...

]$ xhost +

was going to solve anything, one can only imagine. And as for 'try it as root' ... :) the imagination stretches even further.

But i will say you do attempt to give the impression, well, you try to use the <cough> developer terms :wink:


thamarok also writes:
>>
Try with make gconfig.. If that didn't work I think your best bet would be menuconfig
>>

The later requiring a greater kernel configuration familiarity of course.

menuconfig, being a linear term window based configuration, with out a back trace facility, does require some familiarity with the configuration set to start with.

So, i would think that getting some familiarity with the configuration process first, would be more productive.

Firstly ... any running kernel worth anything will have its' configuration available in ...

/proc/config.gz

By copying that to the /usr/src/linux directory, decompressing and prefixing it with a 'dot', you will have a config for the currently running kernel. Which will be auto referenced by any of the make configuration styles you choose. And wiped with a 'make mrproper'. So backing it up, with out the 'dot' prefix, would be advised.

]$ make help

The above command is worth looking into.

The trick then is, if you are just doing a single patch, as it would seem here, and the source being used matches the running kernel, then it would simply involve just running 'make oldconfig'. You will then be presented with only the options that are new to the current source. Being in this case those provided by the patch.

The wider the sources are in version from the running kernel, then the more options you will get presented. So if the sources are far ahead, then it would be advised to get a configuration file that relates to your set up. Or at least as close to it as you can.

In any case, the over all configuration does take some practise to get familiar with. And i would advise anyone new to kernel building to start with sources that are versioned matched to your current kernel first. Rather than just jumping in to a much later kernel.

Always back up your good current kernel as well, and leave it as the default in your boot loaders menu. At least until the new one is proved to be functional.

When your applying patches, you really do need to get a version that actually matches the kernel source.

You are talking about a linux 2.6.20.3.tar.bz2 source package but also a patch-2.6.20-rt8 patch. While it is close, it isn't a match and you mention there are failed hunks, but not what they relate to. While i do concede that at times, failed hunks can be ignored. It does depend on the patch. And shouldn't be thought of as a general rule. By the sounds of this particular one, i would think that failed hunks would indeed be important. Is there not a closer patch. Wouldn't it be better to back off on the source version in order to get a clean patching result. I would be looking for a matched source/patch version here.

>>
I recommend to use xconfig as it's easier to use, but it requires an X Server.
>>

hmmm, i really would think an X server is actually running thamarok :wink:


---------------
Howdy fsv,
---------------


Yes, i would start from scratch and try to find some kernel source that more closely matches the patch. Or find a patch that actually matches the source.

You will need the compiler and associated the associated tool-chain installed, along with the gtk packages for the gtk config front end. If you want to do a 'make gconfig'. In any case, the gtk/glib devl packages will likely be needed at some stage, so it is probable advisable to have them installed anyway.

Code: Select all
Package libgtk2.0-0:
Depends: libgtk2.0-common (>= 2.10.6-1), libgtk2.0-bin (>= 2.10.6-1), libatk1.0-0 (>= 1.9.0), libc6 (>= 2.3.2.ds1-21), libcairo2 (>= 1.2.4), libcupsys2-gnutls10 (>= 1.1.23-1), libfontconfig1 (>= 2.3.0), libglib2.0-0 (>= 2.12.0), libjpeg62, libpango1.0-0 (>= 1.14.7), libpng12-0 (>= 1.2.8rel), libtiff4, libx11-6 | xlibs (>> 4.1.0), libxcursor1 (>> 1.1.2), libxext6 | xlibs (>> 4.1.0), libxi6 | xlibs (>> 4.1.0), libxinerama1, libxrandr2 | xlibs (>> 4.3.0), libxrender1


Package libgtk2.0-dev:
Depends: libgtk2.0-0:
libgtk2.0-common (>= 2.10.6-1), libgtk2.0-bin (>= 2.10.6-1), libatk1.0-0 (>= 1.9.0), libc6 (>= 2.3.2.ds1-21), libcairo2 (>= 1.2.4), libcupsys2-gnutls10 (>= 1.1.23-1), libfontconfig1 (>= 2.3.0), libglib2.0-0 (>= 2.12.0), libjpeg62, libpango1.0-0 (>= 1.14.7), libpng12-0 (>= 1.2.8rel), libtiff4, libx11-6 | xlibs (>> 4.1.0), libxcursor1 (>> 1.1.2), libxext6 | xlibs (>> 4.1.0), libxi6 | xlibs (>> 4.1.0), libxinerama1, libxrandr2 | xlibs (>> 4.3.0), libxrender1


Aptitude, Synaptic should drag in any of those that are missing. Those required for g++ should also respond in that way as well.

Once those development files are all available, you will be able to build from your user account and install as root. You definately do not need to run 'xhost +' at all, and doing it as 'sudo' is also not required.

The main problems i can see is in getting a matching patch for your source version and a working kernel '.config' for those sources.

Maybe if you try building a few kernels first would be a better idea, before going straight into a 'rt' experiment. Start with the sources for your existing installed kernel, as that will have a relevant config already available in your /proc directory, and then working it up through the versions ... which can be achieved quite simply by applying patches to the source. You don't need to down load whole source packages each time. There may well be a 'rt' patch archived for your current kernel. It is important to become familiar with the overall standard config options, especially as they relate to your particular processor/hardware set up first in order to retain any performance benefit from the exercise. It is easy to miss-configure, especially for the processor, or to omit required filesystem, facilities etc, and end up with a poorly performing kernel as a result.

Another course would be to post and ask if any one would have a working .config that matches your hw set. You never know :)

In any case, i think i've basically expressed what i intended here ... Will check back later to see ...


good luck


jm
jjmac
 
Posts: 387
Joined: 2005-12-28 23:34
Location: Australia

Previous

Return to Docs, Howtos, Tips & Tricks

Who is online

Users browsing this forum: No registered users and 4 guests

fashionable