Building kernel modules for stock kernels is a hell of a job!
Hello, After having worked with Debian testing for about 2 years, I'm getting fed up with the seemingly unnecessarily complicated way of building kernel modules for the stock kernels. I'm talking about packages like lm-sensors-source, the nvidia kernel modules (haven't done that in a year though, I switched video cards), and the experimental Debian packages that provide CVS versions of the DRM module by Michel Daenzer (for my ATI card). Currently, I'm having the following stock kernel installed: kernel-image-2.4.21-4-k7, meaning my kernel modules are in /lib/modules/2.4.21-4-k7. The procedure I'm going through is as follows (being root all the time) 1) install the kernel source for the kernel, e.g. kernel-source-2.4.21 2) go to /usr/src and tar xjvf kernel-source-2.4.21.tar.bz2 3) do the usual ln -s kernel-source-2.4.21 linux 4) to avoid having to configure the kernel again, copy the configuration: cp /boot/config-2.4.21-4-k7 /usr/src/linux/.config 5) apt-get install [modulename-source] (sometimes -src), e.g. lm-sensors-source. 6) this should give [modulename].tar.gz in /usr/src; extract it: tar xzvf [modulename].tar.gz now, the source is in /usr/src/modules/[modulename] 7) and now, I always do the following (in bash): export APPEND_TO_VERSION -4-k7 if this is omitted, the kernel modules will be installed in the wrong directory, in this case in /lib/modules/2.4.21/, which doesn't even exist (it is created though). 8) go to /usr/src/linux and type: make-kpkg modules_image this will build the sources and should result in a Debian package in /usr/src, named something like this: [module-name]-2.4.21-4-k7_[version_of_module_source_package]+10.00.Custom_i386.deb If you didn't use the export in step 7, you'll see that the name is like this: [module-name]-2.4.21_[version_of_module_source_package]+10.00.Custom_i386.deb Probably you can also get this version number correctly by using a --append-to-version command line option in the make-kpkg command line 9) install the just built package(s) with dpkg -i [package_name] now the kernel modules should be in the right dir in /lib/modules and modprobe (or modconf) can find them. That's it. Notes: - If you have just installed a new kernel-image package (i.e. a new stock kernel), you need to do everything from the start *after* booting this new kernel - In my experience, if you forget the export of step 7, you have to wipe your whole kernel source tree and start at step 2. I know I'm supposed to do a make-kpgk modules clean, but that didn't do the trick; I still got errors like "The changelog says we are creating 2.4.21-4-k7, but I thought the version is 2.4.21" or something similar (I didn't actually copy paste this from a real situation, it might have been the other way round). - If you have more modules to build, repeat steps 5, 6, 8 and 9 for all the source packages. - all of the above really works, so I must be doing something right. QUESTIONS: A) Why isn't this procedure documented properly somewhere? Especially the APPEND_TO_VERSION was something that took me very long to figure out. It also wasn't mentioned in the installation instructions in the NVIDIA packages at the time I installed them. This caused a lot of mental suffering for me. (Which brings us to another thing: WHY oh WHY, isn't the procedure to get and install the NVIDIA drivers more automated!?) B) Is there a faster or easier way to this? If not, why not? There's a lot of trivial stuff there that could easily be automated, I think. If so, (again:) why isn't it properly documented somewhere!?? See also this: http://lists.debian.org/debian-devel/2002/debian-devel-200203/msg01794.html and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=189513 People, stock kernels are very comfortable, but building modules for them is not! Please tell me what I did wrong, or make the procedure a lot easier! (The latter especially applies to the maintainers of that NVIDIA package...) Luckily, David Z. Maze has the lm-sensors as binary package in unstable nowadays... :) (Although not yet for 2.4.21...) THANKS in advance. Best regards, A quite frustrated Manuel Bilderbeek :-)
Re: Re: Building kernel modules for stock kernels is a hell of a job!
2) go to /usr/src and tar xjvf kernel-source-2.4.21.tar.bz2 Why don't you use the kernel-headers packages and use them as partial kernel source? They provide header files (including the complete kernel version) and the .config that belongs to them. Because for some of them it wasn't enough. So, to be on the safe side, I used the sources. A) Why isn't this procedure documented properly somewhere? Especially This is not the default procedure. Working with kernel-headers is documented in some FAQs and many README.Debian files of the ...-src packages. I haven't seen any README.Debian package that had a description of the procedure that worked out-of-the-box. Most of the time, using stock kernels is not taken into account, so the APPEND_TO_VERSION stuff is missing. NVIDIA packages at the time I installed them. This caused a lot of mental suffering for me. (Which brings us to another thing: WHY oh WHY, isn't the procedure to get and install the NVIDIA drivers more automated!?) I fail to see your problem. Read /usr/share/doc/nvidia-kernel-src/README.Debian.gz and follow the steps in the section: METHOD #1 Using a kernel-headers package *** At the time I still used it (again, one year ago or so), this didn't work out-of-the-box, because of the APPEND_TO_VERSION stuff. I see this has been fixed in the meantime, in step 4 of the installation instructions in the file you mentioned. Still, couldn't this be a lot more automated? -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Re: Re: Building kernel modules for stock kernels is a hell of a job!
Hello, Kernel 2.4.22 got into testing, so I have to go to the procedure again. #include * Manuel Bilderbeek [Sun, Aug 24 2003, 04:32:45PM]: The procedure I'm going through is as follows (being root all the time) 1) install the kernel source for the kernel, e.g. kernel-source-2.4.21 2) go to /usr/src and tar xjvf kernel-source-2.4.21.tar.bz2 Why don't you use the kernel-headers packages and use them as partial kernel source? They provide header files (including the complete kernel version) and the .config that belongs to them. OK, but that doesn't work! See this: goemon:/usr/src/linux# make-kpkg modules_image We do not seem to be in a top level linux kernel source directory tree. Since we are trying to make a kernel package, that does not make sense. Please change directory to a top level linux kernel source directory, and try again. (If I am wrong, and this is indeed a top level linux kernel source directory, then I have gotten sadly out of date with current kernels, and you should upgrade kernel-package) So, only with a full kernel source tree and the copied .config you seem to be able to use make-kpkg. I can't help it. Please tell me I'm wrong. :) -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Random (?) terminals get killed after booting and logging in with GNOME2
Hello, Since the GNOME 2 stuff got into testing, it seems that I have the following problem: when I boot my Debian testing system and log in (xdm, gnome-session), after a few minutes one of the terminals I launch per default are getting killed. I'm launching 4 terminals (saved with "Save Session") by default. Most of the time the top left one gets killed... Today I ran a program in one of the terminals, just after having started the system and having logged in. After a minute, the terminal I started the program from and the program itself just got silently killed... I can't find anyting weird in my system logs. Anyone having the same problem? Or know the cause and solution? It's really very annoying and I'm not tending to upgrade my Debian testing system at work to GNOME 2 until I know what this is... Please help! Best regards, Manuel Bilderbeek
Re: Random (?) terminals get killed after booting and logging in with GNOME2
Manuel Bilderbeek wrote: Hello, Since the GNOME 2 stuff got into testing, it seems that I have the following problem: when I boot my Debian testing system and log in (xdm, gnome-session), after a few minutes one of the terminals I launch per default are getting killed. I'm launching 4 terminals (saved with "Save Session") by default. Most of the time the top left one gets killed... Today I ran a program in one of the terminals, just after having started the system and having logged in. After a minute, the terminal I started the program from and the program itself just got silently killed... I can't find anyting weird in my system logs. Ah, I forgot: it only happens when I log in just after booting. So, when I log out and log in again, no terminals get killed. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Debian wxWindows - XML Resources?
Hello all, I originally sent the message below to [EMAIL PROTECTED], but it seems he's not responding to my mails. Ron is the maintainter of the wxWindows packages for Debian. I was hoping that sending it to this mailinglist would be more fruitful. Please let me know if there's something better I could do. :) OK, here's what I sent: Me and a friend just started to work on a project that uses wxWindows (in C++) and we'd like to use the wxWindows XML Resources, to easily separate the UI from the actual implementation. But, it seems that the wxWindows XML Resources are not included in Debian. Is that correct? (I get link errors when compiling...) If you need more information, please let me know. Thanks in advance for your reply! Best regards, Manuel Bilderbeek
