Re: Building kernel modules for stock kernels is a hell of a job!
Hi, On Tue, Sep 30, 2003 at 12:27:29AM +0200, Eduard Bloch wrote: kdist_clean: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean Are those $(MFLAGS) really useful? I thought they were not because $(MAKE) also had the flags, but I'm not sure anymore... MFLAGS are the flags that make got on the commandline. The calls above copy the make call with options. Well, I just checked the gnu make manual (section 5.6.3) and, if I understand it correctly, it says that using $(MFLAGS) is now useless thanks to the $(MAKEFLAGS) variable... Is there something wrong with my inderstanding of this manual? Or is this a gnu-only feature, that we should not depend on? Regards, Nicolas
Re: Building kernel modules for stock kernels is a hell of a job!
Scripsit Manoj Srivastava [EMAIL PROTECTED] He said use the kernel-headers package, not kernel-package. Any debian packaged module shall work with something like: ./debian/rules KVERS=2.4.21 KSRC=/usr/src/kernel-headers-2.4.21 KPKG_DEST_DIR=../ KDREV=blah kdist_image Interesting. Just out of curiosity, where is that supposed to be documented? Knowing this might have enabled me to make use of the debian packaging [1] of a module I needed a couple of weeks ago, but I could not find any applicable docs in either the kernel-package, kernel-source-XXX or the module source itself. (Btw, is it a bug for the debian/rules in a module package to run dh_testroot from its 'build' target? I know it's not allowed in the debian/rules in a _source_ package, but perhaps the conventions for kernel-module packages are different). [1] Actually ended up inserting the module source in the kernel directory tree and patching Makefiles and Config.in's to trick it into building together with a kernel image. Yuck. -- Henning Makholm However, the fact that the utterance by Epimenides of that false sentence could imply the existence of some Cretan who is not a liar is rather unsettling.
Re: Building kernel modules for stock kernels is a hell of a job!
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Manoj Srivastava [EMAIL PROTECTED] He said use the kernel-headers package, not kernel-package. Any debian packaged module shall work with something like: ./debian/rules KVERS=2.4.21 KSRC=/usr/src/kernel-headers-2.4.21 KPKG_DEST_DIR=../ KDREV=blah kdist_image Interesting. Just out of curiosity, where is that supposed to be documented? All of the information is in /usr/share/doc/kernel-package/README.modules, though not with a single command line like that as such. (Btw, is it a bug for the debian/rules in a module package to run dh_testroot from its 'build' target? I know it's not allowed in the debian/rules in a _source_ package, but perhaps the conventions for kernel-module packages are different). I don't consider it a bug. I do think the kdist and kdist_image targets should reinvoke make under $(ROOT_CMD), though, just to be sure. The i2c-source debian/rules file has: kdist_image: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules binary-modules $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean kdist: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules binary-modules dpkg-genchanges -b -e$(KMAINT) $(KEMAIL) -u$(KSRC)/.. $(CHFILE) debsign -e$(KMAINT) $(KEMAIL) $(CHFILE) $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean kdist_clean: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean ...with some magic early on in the file to figure out the name of the .changes file $(CHFILE). -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
Re: Building kernel modules for stock kernels is a hell of a job!
On 29 Sep 2003 15:31:42 +0200, Henning Makholm [EMAIL PROTECTED] said: Scripsit Manoj Srivastava [EMAIL PROTECTED] He said use the kernel-headers package, not kernel-package. Any debian packaged module shall work with something like: ./debian/rules KVERS=2.4.21 KSRC=/usr/src/kernel-headers-2.4.21 KPKG_DEST_DIR=../ KDREV=blah kdist_image Interesting. Just out of curiosity, where is that supposed to be documented? Knowing this might have enabled me to make use of the debian packaging [1] of a module I needed a couple of weeks ago, but I could not find any applicable docs in either the kernel-package, kernel-source-XXX or the module source itself. *Shrug*. This is a direct consequence of the way the kernel-package interacts with modules; and the details are in every kernel-package (/usr/share/doc/kernel-package/README.modules) and kernel-source package. patches and additional docs are always gladly received. manoj -- It is the quality rather than the quantity that matters. Lucius Annaeus Seneca (4 B.C. - A.D. 65) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Building kernel modules for stock kernels is a hell of a job!
Hi, On Mon, Sep 29, 2003 at 01:43:05PM -0400, David Z Maze wrote: I don't consider it a bug. I do think the kdist and kdist_image targets should reinvoke make under $(ROOT_CMD), though, just to be sure. The i2c-source debian/rules file has: kdist_image: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules binary-modules $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean kdist: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules binary-modules dpkg-genchanges -b -e$(KMAINT) $(KEMAIL) -u$(KSRC)/.. $(CHFILE) debsign -e$(KMAINT) $(KEMAIL) $(CHFILE) $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean kdist_clean: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean Are those $(MFLAGS) really useful? I thought they were not because $(MAKE) also had the flags, but I'm not sure anymore... Regards, Nicolas
Re: Building kernel modules for stock kernels is a hell of a job!
#include hallo.h * Nicolas Boullis [Mon, Sep 29 2003, 11:42:59PM]: On Mon, Sep 29, 2003 at 01:43:05PM -0400, David Z Maze wrote: I don't consider it a bug. I do think the kdist and kdist_image targets should reinvoke make under $(ROOT_CMD), though, just to be sure. The i2c-source debian/rules file has: It is not a bug - there is AFAICS no way to tell make to run a rule _twice_. You cannot say: kdist_image: clean kdist_configure binary-modules clean and expect the last clean in the list to be executed. Even the order of the rules execution is not guaranteed when -j is used. kdist: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules binary-modules dpkg-genchanges -b -e$(KMAINT) $(KEMAIL) -u$(KSRC)/.. $(CHFILE) debsign -e$(KMAINT) $(KEMAIL) $(CHFILE) $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean Just for the record, module-assistant includes such things ready to be sourced by other Makefiles. kdist_clean: $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean Are those $(MFLAGS) really useful? I thought they were not because $(MAKE) also had the flags, but I'm not sure anymore... MFLAGS are the flags that make got on the commandline. The calls above copy the make call with options. MfG, Eduard. -- Es ist offensichtlich, daß das menschliche Gehirn wie ein Computer funktioniert. Da es keine dummen Computer gibt, gibt es also auch keine dummen Menschen. Nur ein paar Leute, die unter Windows laufen.
Re: Building kernel modules for stock kernels is a hell of a job!
On Tue, 23 Sep 2003 20:39:04 +0200, Manuel Bilderbeek [EMAIL PROTECTED] said: Hello, Kernel 2.4.22 got into testing, so I have to go to the procedure again. #include hallo.h * 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: He said use the kernel-headers package, not kernel-package. Any debian packaged module shall work with something like: ./debian/rules KVERS=2.4.21 KSRC=/usr/src/kernel-headers-2.4.21 KPKG_DEST_DIR=../ KDREV=blah kdist_image 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. :) I think you may well be. manoj -- I find you lack of faith in the forth dithturbing. Darse (Darth) Vader Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
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 hallo.h * 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/
Re: Building kernel modules for stock kernels is a hell of a job!
#include hallo.h * Manoj Srivastava [Mon, Aug 25 2003, 03:50:33PM]: Okay, I think I have found a solution for the people with different points of view. First, let's summarize some. This is my view: the kernel headers and the configuration used when compiling a stock kernel are to be viewed as an *integral part of that kernel*. The headers should be installed by default, ... Of course, it all used to fall apart for user who had multiple kernels installed, and woh used to swithc in between, people who ... Of course, but aren't those people (except for those with limited space) usually the ones that can cope with that? If you're knowledgeable enough to use multiple kernels, it can be assumed that ... There are two constituencies here. One set wants to just have the minimal install, and another wants both headers and the kernel image. The obvious solution is to give people a choice, which is what we do now. ... Difficult? My solution is called: module-assistant. This package is small enough to be installed with basedebs and will help the user (note: end users are difficult by default) with the compiling of kernel module packages. It will suggest to install the right headers, it will select the headers directory or the source directory for self-compiled kernels and a planned feature is a fakesource function to restore the kernel-source directory for some existing kernel-image package. It keeps track about installing source version and display when package upgrade is possible. It will also provide some sugar for developers: it will simplify building whole package series for different kernels. It also installs Makefile includes [1] used to calculate different things, create changes files and sign them. [2] Package maintainers with some non-convential views about the ways to fetch the modules source (like apt-src fanatics) can install their own control scripts to adapt module-assistant's behaviour. For those who are interested, wait for FTP master to install the package into unstable or visit: http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/module-assistant/?cvsroot=modass (provisoric, public Subversion repository comming soon) NOTE: this package is not intended to make kernel-package obsolete. It just takes a subset of its functions and makes them useable in a more comfortable way. [1] The code from dh-make template is also included in a separate file, but *b* only use it if you really like it [2] I really hope that most kernel-package maintainers will start to use this solution and contribute improvements. Currently, there are dozens of private solutions, some maintainers use stolen code from alsa-source or from pcmcia-source and others invent something new. Of course, depending on a central package create a single point of failure but it really helps to avoid the present chaos. Have fun, Eduard. -- Im Falle eines Falles ist richtig fallen alles. pgpdKoKmP18z4.pgp Description: PGP signature
Re: Building kernel modules for stock kernels is a hell of a job!
On Sun, 24 Aug 2003 19:50:18 -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: On Sun, 24 Aug 2003 20:16:21 +0200, horrorvacui [EMAIL PROTECTED] said: This is my view: the kernel headers and the configuration used when compiling a stock kernel are to be viewed as an *integral part of that kernel*. The headers should be installed by default, Heh. You are describing how things used to be, with the kernel-headers always installed by kerel-image, and the symlink kept in place. Looking at the CVS, you could have any number of headers or sources in place, and the /usr/src/linux symlink was kept pointing to the latest version, as determined by the most recent kernel-image isntalled. Yes. The symlink is more or less unnecessary topping, but this is how it should be. Of course, it all used to fall apart for user who had multiple kernels installed, and woh used to swithc in between, people who had limited amount of space in /usr, and people who wanted to compile for a different machine than the current one. Of course, but aren't those people (except for those with limited space) usually the ones that can cope with that? If you're knowledgeable enough to use multiple kernels, it can be assumed that you can be burdened with the responsibility of having /usr/src/linux pointed at the right direction, depending on the currently running kernel. I'm no newbie, mind you - I've been compiling my kernels, installing modules and making it all work together for years, yet getting the headers/source was too cryptic for me. Remember that most unexperienced users won't even know that they need a kernel in the source form, or the headers, nor will they understand why. I'll maintain that it would be a great help for users if every kernel came with headers packaged. The nice install-routine-dialogs-thingy (was that debconf? dselect? dpkg-whatever?) can ask Do you want to skip installing kernel headers and have No selected as default. Or perhaps one could make the headers a dependancy of the kernel, so the kernel packages are small and those who know how may override this. The current behaviour was introduced to allow for increased flexibility. I don't see how the flexibility might benefit from this (except for reducing the size of kernel packages). After all, if the situation still were as you described above, deleting a directory and a symlink would be all you needed to do to make it as it is currently. The other way around it's much more difficult, and if it's only about finding out what you need to do. Sorry about my insisting on this, but I see myelf in a way as the advocatus newbii (pun intended). It's a thing that might turn off many new users off Free Software. -- Horror Vacui Registered Linux user #257714 Go get yourself... counted: http://counter.li.org/ - and keep following the GNU.
Re: Building kernel modules for stock kernels is a hell of a job!
On Mon, 25 Aug 2003 20:26:29 +0200, horrorvacui [EMAIL PROTECTED] said: On Sun, 24 Aug 2003 19:50:18 -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: On Sun, 24 Aug 2003 20:16:21 +0200, horrorvacui [EMAIL PROTECTED] said: This is my view: the kernel headers and the configuration used when compiling a stock kernel are to be viewed as an *integral part of that kernel*. The headers should be installed by default, Heh. You are describing how things used to be, with the kernel-headers always installed by kerel-image, and the symlink kept in place. Looking at the CVS, you could have any number of headers or sources in place, and the /usr/src/linux symlink was kept pointing to the latest version, as determined by the most recent kernel-image isntalled. Yes. The symlink is more or less unnecessary topping, but this is how it should be. Unfortunately, several people disagree with that conclusion. Of course, it all used to fall apart for user who had multiple kernels installed, and woh used to swithc in between, people who had limited amount of space in /usr, and people who wanted to compile for a different machine than the current one. Of course, but aren't those people (except for those with limited space) usually the ones that can cope with that? If you're knowledgeable enough to use multiple kernels, it can be assumed that you can be burdened with the responsibility of having /usr/src/linux pointed at the right direction, depending on the currently running kernel. I'm no newbie, mind you - I've been compiling my kernels, installing modules and making it all work together for years, yet getting the headers/source was too cryptic for me. Remember that most unexperienced users won't even know that they need a kernel in the source form, or the headers, nor will they understand why. There are two constituencies here. One set wants to just have the minimal install, and another wants both headers and the kernel image. The obvious solution is to give people a choice, which is what we do now. The headers and sources are provided by debian in precisely the same place that the kernel images are.Any one who chooses to have headers installed can get them from the same place they got the image, and all the package management tools are there to help them do so. I don't see how the flexibility might benefit from this (except for reducing the size of kernel packages). After all, if the situation still were as you described above, deleting a directory and a symlink would be all you needed to do to make it as it is currently. The other way around it's much more difficult, and if it's only about finding out what you need to do. Difficult? __ apt-cache search kernel-image-2.4.21 | grep ^kernel kernel-image-2.4.21-4-386 - Linux kernel image for version 2.4.21 on 386. kernel-image-2.4.21-4-586tsc - Linux kernel image for version 2.4.21 on Pentium-Classic. kernel-image-2.4.21-4-686 - Linux kernel image for version 2.4.21 on PPro/Celeron/PII/PIII/PIV. kernel-image-2.4.21-4-686-smp - Linux kernel image for version 2.4.21 on PPro/Celeron/PII/PIII/PIV SMP. kernel-image-2.4.21-4-k6 - Linux kernel image for version 2.4.21 on AMD K6/K6-II/K6-III. kernel-image-2.4.21-4-k7 - Linux kernel image for version 2.4.21 on AMD K7. kernel-image-2.4.21-4-k7-smp - Linux kernel image for version 2.4.21 on AMD K7 SMP. kernel-tree-2.4.21 - Linux kernel tree for building prepackaged Debian kernel images kernel-image-2.4.21-dm - Linux kernel binary image for version 2.4.21-dm. kernel-image-2.4.21 - Linux kernel binary image for version 2.4.21. __ apt-cache search kernel-headers-2.4.21 | grep ^kernel kernel-headers-2.4.21-4 - Header files related to Linux kernel version 2.4.21 kernel-headers-2.4.21-4-386 - Linux kernel headers 2.4.21 on 386 kernel-headers-2.4.21-4-586tsc - Linux kernel headers 2.4.21 on Pentium-Classic kernel-headers-2.4.21-4-686 - Linux kernel headers 2.4.21 on PPro/Celeron/PII/PIII/PIV kernel-headers-2.4.21-4-686-smp - Linux kernel headers 2.4.21 on PPro/Celeron/PII/PIII/PIV SMP kernel-headers-2.4.21-4-k6 - Linux kernel headers 2.4.21 on AMD K6/K6-II/K6-III kernel-headers-2.4.21-4-k7 - Linux kernel headers 2.4.21 on AMD K7 kernel-headers-2.4.21-4-k7-smp - Linux kernel headers 2.4.21 on AMD K7 SMP kernel-headers-2.4.21-sparc - Kernel header files for all sparc sub architectures __ apt-cache search kernel-source-2.4.21 | grep ^kernel kernel-patch-debian-2.4.21 - Debian patches to Linux 2.4.21 kernel-source-2.4.21 - Linux kernel source for version 2.4.21 with Debian patches I am not a proponent of reducing choices (and chosing not to have kernel headers installed is a choice) for the sake of dumbing down Debian so we get rank novices who probably have no business compiling modules in the first place -- if you cant figure out which kernel image goes with which header from the above list, yes, I do mean you. manoj -- I
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: Building kernel modules for stock kernels is a hell of a job!
#include hallo.h * 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. 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 No, you don't. If some package requries it, file a bug report. To make the kernel find the modules you have to reboot anyways (so depmod is executed from the init script) or the modules package runs depmod (with the special path arguments for the new kernel) in postinst. - 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). Should not happen. If it fails, file a bug report. - all of the above really works, so I must be doing something right. QUESTIONS: 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. 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 *** MfG, Eduard. -- Ihr wollt also mit ein oder mehreren PHP-Leuten ins LinuxTag-Büro einziehen wegen Kommunikationsproblemen (mit wem?!), aber nicht sagen, warum? Und wer verteilt hier eigentlich Redeverbote? -- Klaus Knopper
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: Building kernel modules for stock kernels is a hell of a job!
On Sun, 24 Aug 2003 17:16:25 +0200 Eduard Bloch [EMAIL PROTECTED] wrote: #include hallo.h * 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. 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 snip 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. I don't. He certainly has a point, and I wanted to post a message about this, only he was faster. I recently installed debian for a friend, installed alsa and was completely helpless as to where to obtain them. I tried looking for alsa-modules, or kernel source for the stock kernel so I could compile them myself... This kind of trouble isn't something I'm used to, since I always replace the stock kernels with my own (accepting to deal with troubles that might result), but since the chap was a complete newbie, I wanted to give him a standard system. I failed, he has a standard kernel, but no sound. Now, since you say the package's name is kernel-headers, it'd go allright, but I (quite an experienced GNU/Linux user, but only using Debian for about half a year) didn't manage to find that out. justification The most trouble you get when you're convinced you know what you're doing, and don't RTFM as you should - I knew that I can compile kernel modules because I have the kernel source, so it didn't occur to me that the package might contain the headers only. /justification This is my view: the kernel headers and the configuration used when compiling a stock kernel are to be viewed as an *integral part of that kernel*. The headers should be installed by default, at the very most leaving the user the option to have them not installed, albeit dissuading from doing so. It would also be nice if an installation script would read lilo.conf and make a /usr/src/linux symlink to the default kernel headers. This way, even a newbie who's been told that he has to compile drivers for his exotic hardware could download the sources, compile and install them with little assistance, and with no knowledge of the magic that enabled him to do so. I'm a member of several newbie-help lists, and I dare say that most failures to install drivers are due to a missing kernel source. By no means should the headers be a non-intuitively named package you read about in the 27th howto or in a newsgroup months later. Don't get me wrong - I'm not trying to shove off the responsibility for my disgraceful performance to Debian, that was my fault. Only, seeing that virtually all driver packages require kernel headers, it appears to me so essentially common sense to install them that I have to wonder why virtually no distro does so. Meanwhile, I see no negative effects to this - most people have enough space to accomodate them; the installation proces wouldn't be much more complicated (after all, while installing Debian I'm asked, say, whether I want to install gnuplot with the setuid bit set - which I don't use and don't care about - so why can't a nice screen ask me whether I want to install kernel headers and call me a fool if I select no?) Again: BINARY KERNEL WITHOUT HEADERS IS A CRIPPLED KERNEL. Please, whoever has the power to do so, let no crippled kernels be installed by default. Cheers P.S: I just joined. Hi, everybody. -- Horror Vacui Registered Linux user #257714 Go get yourself... counted: http://counter.li.org/ - and keep following the GNU.
Re: Building kernel modules for stock kernels is a hell of a job!
On Sun, 24 Aug 2003 18:02:32 +0200, Manuel Bilderbeek [EMAIL PROTECTED] said: 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? Working patches gladly accepted. manoj -- Death is nature's way of saying `Howdy'. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Building kernel modules for stock kernels is a hell of a job!
On Sun, 24 Aug 2003 20:16:21 +0200, horrorvacui [EMAIL PROTECTED] said: I don't. He certainly has a point, and I wanted to post a message about this, only he was faster. I recently installed debian for a friend, installed alsa and was completely helpless as to where to obtain them. I tried looking for alsa-modules, or kernel source for the stock kernel so I could compile them myself... This kind of trouble isn't something I'm used to, since I always replace the stock kernels with my own (accepting to deal with troubles that might result), but since the chap was a complete newbie, I wanted to give him a standard system. I failed, he has a standard kernel, but no sound. Now, since you say the package's name is kernel-headers, it'd go allright, but I (quite an experienced GNU/Linux user, but only using Debian for about half a year) didn't manage to find that out. justification The most trouble you get when you're convinced you know what you're doing, and don't RTFM as you should - I knew that I can compile kernel modules because I have the kernel source, so it didn't occur to me that the package might contain the headers only. /justification This is my view: the kernel headers and the configuration used when compiling a stock kernel are to be viewed as an *integral part of that kernel*. The headers should be installed by default, Heh. You are describing how things used to be, with the kernel-headers always installed by kerel-image, and the symlink kept in place. Looking at the CVS, you could have any number of headers or sources in place, and the /usr/src/linux symlink was kept pointing to the latest version, as determined by the most recent kernel-image isntalled. Of course, it all used to fall apart for user who had multiple kernels installed, and woh used to swithc in between, people who had limited amount of space in /usr, and people who wanted to compile for a different machine than the current one. The current behaviour was introduced to allow for increased flexibility. manoj -- If anything can go wrong, it will. Edsel Murphy Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Building kernel modules for stock kernels is a hell of a job!
Manuel Bilderbeek [EMAIL PROTECTED] writes: 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. 1) install the kernel source for the kernel, e.g. kernel-source-2.4.21 Since you're singling out lm-sensors here, I can tell you that lm-sensors-source does build fine against the correct kernel-headers package; the normal binary package build-depends on a kernel-build package to get all of the kernel-headers, and uses those without any particular magic. 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] At this point, I think what I would tell you to do is (untested): cd $MODULE_LOC/$modulename debian/rules kdist-image KDREV=2.4.21-4 KVERS=2.4.21-4-k7 \ KSRC=/usr/src/kernel-headers-2.4.21-4-k7 \ KMAINT=Your Name KEMAIL=[EMAIL PROTECTED] \ APPEND_TO_VERSION=-4-k7 ROOT_CMD=fakeroot which will produce the binary package you're looking for in /usr/src. This is just using the interface required by kernel-package. 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. - 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 You shouldn't need to. (Though you go through a little more effort to get the right .config file.) - 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; 'rm -rf /usr/src/modules' is often quite theraputic for odd problems like this. Screwing up --append-to-version using kernel-package has kind of unfortunate side effects for recovering. :-/ 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...) In some ways, doing this feels a lot like a very slow game of Whack-A-Mole. The process goes something like this: (1) Notice that Debian kernel 2.4.21-1 exists. (2) Install kernel-build-2.4.21-1. Change debian/rules to reference the right kernel. (3) Actually rebuild the package. This winds up taking quite a long time for me, particularly since there are seven different kernel flavors and I'm foolishly doing the build over AFS over a cable modem. (Should probably fix that. :-) (4) Upload. (5) Wait for ftpmaster, since these are all new packages. (6) Notice that Debian kernel 2.4.21-2 exists. (7) ftpmaster accepts lm-sensors-2.4.21-1-*, which depend on kernel-image-2.4.21-1-*, which is no longer in the repository. (8) Go to 2. It's also a bit frustrating to look at cross-platform compatability, and realize that the magic to get things built is just going to be different on each platform, since the platform-specific kernel packages are all different. Plus getting stock kernel modules built is presently entirely in the hands of the module maintainers, and the glue code in debian/rules to actually do that is kind of groady. I suspect for unstable, there's just not a lot to be done. For sarge, we should probably pick a kernel and a kernel ABI (or sets thereof) and not change it, so that packages that provide prebuilt kernel modules can do that more reasonably. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
