Compiling the kernel and staying compatable?
I have probably asked this question in 15 different ways in the last month, but I feel I have only made marginal progress in understanding. I downloaded the kernel source and compiled it. All went fairly well. I'm now working on getting everything into modules which I'm hoping will be supported by the new modutils-2.4.2. One thing I still don't understand is how ALSA relates to the kernel modules. It is my understanding that ALSA provides its own modules which are distinct from the kernel's. One such module appears to be named 'snd-card-sbawe.o' and is found in /lib/modules/2.4.0-4GB/misc/ /lib/modules/2.2.18/misc/. I can see by rpm -qlp k_deflt_24-2.4.2-4.i386.rpm that this module is in the kernel RPM file for the updated pre-built kernel. If you know the answer to #5 below that would be a great place to start. So what I want is: 1) My sound to work. 2) Do the least amount of work to maintain functioning sound, and still be able to compile the kernel. 3) Get the modules that 'should' be in the /lib/modules/<version> tree into that tree at the proper place. This means the modules which are from my build, as well as the ones that do not come from the kernel, e.g., the ALSA modules. 4) Get /lib/modules/<version>/modules.* for my build configured properly so that these modules load when the system boots, or whenever they are 'supposed' to load. 5) Install the new pre-built kernel from my directory rather than from the FTP site. In the past the only way I have installed the pre-built kernel has been by selecting yast-> System Administration -> kernel and boot configuration -> Select boot kernel. I have never installed an updated, pre-built kernel because I know how to build the kernel, but I don't knwo how to install an updated pre-built kernel. I'm sure that sounds backwards, but that's how things have been till now. IIRC if I merely install the RPM for the new pre-built, that doesn't do everything I need done. YaST does not let me choose where to look for the kernel it installs. At least I don't see the option. 6) Have some clue as to what I'm doing. TIA, Steve
On Sat, 3 Mar 2001 20:16:40 -0500
"Steven T. Hatton"
I have probably asked this question in 15 different ways in the last month, but I feel I have only made marginal progress in understanding. I downloaded the kernel source and compiled it. All went fairly well. I'm now working on getting everything into modules which I'm hoping will be supported by the new modutils-2.4.2. One thing I still don't understand is how ALSA relates to the kernel modules. It is my understanding that ALSA provides its own modules which are distinct from the kernel's. One such module appears to be named 'snd-card-sbawe.o' and is found in /lib/modules/2.4.0-4GB/misc/ /lib/modules/2.2.18/misc/. I can see by rpm -qlp k_deflt_24-2.4.2-4.i386.rpm that this module is in the kernel RPM file for the updated pre-built kernel.
If you know the answer to #5 below that would be a great place to start.
So what I want is: 1) My sound to work.
If I understand you correctly, ALSA is not working with your own compiled 2.4.x kernel? If you use to compile sources for both the kernel and ALSA then it should be a matter of telling ALSA where to put the modules in the compilation process. To do this, tells explicitly the modules path to the ALSA's configure script with "--with-moddir=/lib/modules/2.4.x/kernel/drivers/sound".
2) Do the least amount of work to maintain functioning sound, and still be able to compile the kernel.
Unfortunately, each time you compile a new kernel, you also need to recompile the ALSA modules.
3) Get the modules that 'should' be in the /lib/modules/<version> tree into that tree at the proper place. This means the modules which are from my build, as well as the ones that do not come from the kernel, e.g., the ALSA modules.
4) Get /lib/modules/<version>/modules.* for my build configured properly so that these modules load when the system boots, or whenever they are 'supposed' to load.
5) Install the new pre-built kernel from my directory rather than from the FTP site.
In the past the only way I have installed the pre-built kernel has been by selecting yast-> System Administration -> kernel and boot configuration -> Select boot kernel. I have never installed an updated, pre-built kernel because I know how to build the kernel, but I don't knwo how to install an updated pre-built kernel. I'm sure that sounds backwards, but that's how things have been till now. IIRC if I merely install the RPM for the new pre-built, that doesn't do everything I need done. YaST does not let me choose where to look for the kernel it installs. At least I don't see the option.
6) Have some clue as to what I'm doing.
TIA,
Steve
Regards...
--
Jean-François Bocquet
On Sunday 04 March 2001 02:38, Jean-François Bocquet wrote:
On Sat, 3 Mar 2001 20:16:40 -0500
So what I want is: 1) My sound to work.
If I understand you correctly, ALSA is not working with your own compiled 2.4.x kernel? If you use to compile sources for both the kernel and ALSA then it should be a matter of telling ALSA where to put the modules in the compilation process. To do this, tells explicitly the modules path to the ALSA's configure script with "--with-moddir=/lib/modules/2.4.x/kernel/drivers/sound".
2) Do the least amount of work to maintain functioning sound, and still be able to compile the kernel.
Unfortunately, each time you compile a new kernel, you also need to recompile the ALSA modules.
Jean-François, Thank you for your advice. I *believe* all I need to do is keep the modules which SuSE provides in a place where depmod can find them. The fact of the matter is, the last time I compiled the kernel, just about the only module(s) that did work was the sound card support. I believe the problem is that my build of the kernel is putting things in /lib/modules/2.4.2 and SuSE puts them in /lib/modules/2.4.2-4GB. If I could figure out how to build the kernel and its modules in such a way as to put everyting in the 2.4.2-4GB, that may work. The other option may be to put the SuSE modules in 2.4.2. I trust that rebuilding ALSA is *an* option. It just doesn't seem like the correct option. I'm trying to research this topic right now. I really don't know where to start. The kernel README pointed me to Documents/modules.txt. I don't think that will hold all the answers either. I would very much like to know how to install the pre-built 2.4.2 so that I could at least see if that fixes my problem of the drm kernel support not working as a module. When I simply installed the RPM, my system would not boot past the loading of the kernel. It could not find any of its modules. I may be able to patch a working system together, but this answer is unacceptable if we are to consider Linux to be an industrial operating system. I truly wish I knew what documentation explains the new techniques used in the 2.4.2 kernel vis-a-vis modules. I also which I knew if this arrangement is specific to SuSE or if it is part of a new Linux design. Perhaps the answer lies in the LSB. I don't know. Please do not missunderstand my stubbornness as ingratitude. I *do* appreciate the advice. Unfortunately, I have been making things work without understanding for years. It takes too long to do things this way, and it is not reliable. The last time I tried to compile ALSA, that failed for reasons related to modules. I'm sure I *could* have found a way to make that work as well, but there is a fundamnetal problem with having to rebuild non-kernel modules everytime the same version of the kernel is built. Doing so means either we do not undestand who the process should be carried out, or the process is borken, and thus needs to be fixes. Steve
On Sunday 04 March 2001 00:45, Steven T. Hatton wrote: <The mother of all Snips> I admire that you are doing this to learn too. So much nicer when you think "ahhh I know exactly what is going on here". With ALSA I have not had to recompile it if its the same version. In fact I have recompiled 2.4.2 numerous times to get it fine tuned, and never once had to recompile ALSA. I will have to recompile when I upgrade to 2.4.3 though. Many of these non-Kernel modules have been built around standard Kernel loads that came with the distribution. I cannot remember the reason, I read it at gnu.org from the install file from the glibc source... The modules are the new Linux technique, not LSB, not SuSE. 2.4 is structurely different....I think the next release shall be much smoother. I'd like to make an install script that will install the kernel flawlessly....But my programming is limited to some C and C++.... Matt
On Sun, Mar 04, 2001 at 03:45:53AM -0500, Steven T. Hatton wrote:
Thank you for your advice. I *believe* all I need to do is keep the modules which SuSE provides in a place where depmod can find them. The fact of the matter is, the last time I compiled the kernel, just about the only module(s) that did work was the sound card support. I believe the problem is that my build of the kernel is putting things in /lib/modules/2.4.2 and SuSE puts them in /lib/modules/2.4.2-4GB. If I could figure out how to build the kernel and its modules in such a way as to put everyting in the 2.4.2-4GB, that may work. The other option may be to put the SuSE modules in 2.4.2. I trust that rebuilding ALSA is *an* option. It just doesn't seem like the correct option. I'm trying to research this topic right now. I really don't know where to start. The kernel README pointed me to Documents/modules.txt. I don't think that will hold all the answers either.
I believe that you can get it to work. There is an option in the modules section that will let you run modules that were not compiled with the kernel. I would just copy the needed *.o files from the default SuSE location, and then run "depmod -a" while in /lib/modules/linux-2.4.2. If this doesn't work, then you will have to recompile the said modules. - v -- Victor R. Cardona vcardona@home.com "Behold the keyboard of Kahless, the greatest Klingon code warrior that ever lived!"
On Sunday 04 March 2001 10:31, Victor R. Cardona wrote:
On Sun, Mar 04, 2001 at 03:45:53AM -0500, Steven T. Hatton wrote:
If I could figure out how to build the kernel and its modules in such a way as to put everyting in the 2.4.2-4GB, that may work. The other option may be to put the SuSE modules in 2.4.2. I trust that rebuilding ALSA is *an* option. It just doesn't seem like the correct option. I'm trying to research this topic right now. I really don't know where to start. The kernel README pointed me to Documents/modules.txt. I don't think that will hold all the answers either.
I believe that you can get it to work. There is an option in the modules section that will let you run modules that were not compiled with the kernel.
I would just copy the needed *.o files from the default SuSE location, and then run "depmod -a" while in /lib/modules/linux-2.4.2. If this doesn't work, then you will have to recompile the said modules.
- v
Victor, Thanks for the ideas. I've had similar frightening thoughts as these running through the back of my mind. Once I get more of a clue as to what is supposed to be happening in the new architecture, I may, as was suggested, shoot off an e-mail to Herr Mantel asking him what he recommends. I did come across some words of solus which help explain why this process is driving me mad. This from the /usr/src/linux/Documentation/Changes: "In addition, the layout of modules under /lib/modules/`uname -r`/ has been made more sane. This change also requires that you upgrade to a recent modutils." No further direct reference was given. However, it seems as if the man pages for the various modutils should prove helpful. Especially if I read them. {;-)> I have actually gotten a bit out of the various documents bundled with the kernel. If I arrive at any kind of module Nirvana I will share my path and truth with others. (in keeping with the whole IBM theme....OM...or is that Ohm?) Steve
On Sun, Mar 04, 2001 at 04:06:09PM -0500, Steven T. Hatton wrote:
I did come across some words of solus which help explain why this process is driving me mad. This from the /usr/src/linux/Documentation/Changes:
"In addition, the layout of modules under /lib/modules/`uname -r`/ has been made more sane. This change also requires that you upgrade to a recent modutils."
I tried installing the modutils and 2.4.2 kernel from SuSE. I failed miserably. I have had better luck upgrading from source, and will probably do that in a couple of versions. - v -- Victor R. Cardona vcardona@home.com "Behold the keyboard of Kahless, the greatest Klingon code warrior that ever lived!"
* Steven T. Hatton [Sun, 4 Mar 2001 03:45:53 -0500]:
Thank you for your advice. I *believe* all I need to do is keep the modules which SuSE provides in a place where depmod can find them.
Nope, you can't. Modules have the version of the kernel they're compiled for hardcoded into them. This will necessitate to load them with the -f flag for different kernels. The only clean way is to recompile the ALSA modules yourself so they match your kernel. -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
On Sunday 04 March 2001 22:29, Philipp Thomas wrote:
* Steven T. Hatton [Sun, 4 Mar 2001 03:45:53 -0500]:
Thank you for your advice. I *believe* all I need to do is keep the modules which SuSE provides in a place where depmod can find them.
Nope, you can't. Modules have the version of the kernel they're compiled for hardcoded into them. This will necessitate to load them with the -f flag for different kernels.
The only clean way is to recompile the ALSA modules yourself so they match your kernel.
Philipp, Is this true if I have the 2.4.2 source, and the 2.4.2 SuSE provided pre-compiled modules? I have notice that the majority of contents in the pre-built RPM are modules which end up in /usr/lib/<'uname -r'> . If I understand this correctly, the kernel version is the determining factor. So compiling my own kernel with the 2.4.2 source *should* not require recompiling ALSA. I also believe the ALSA modules are in bundled the pre-built RPM. It this correct? I don't wish to flog a dead horse here, but I do want to understand how all this works. I'll keep doing my homework so you folks can spend your time making SuSE better, rather than answering questions I should be able to answer myself. Thanks for your help. Steve
Nope, you can't. Modules have the version of the kernel they're compiled for hardcoded into them. This will necessitate to load them with the -f flag for different kernels. This is all rather confusing which leads me to my question. I have bought every version of SuSE since 6.2. Though just beginning I was able to easily compile the kernel with the instructions in
Philipp Thomas wrote: the SuSE manual. Now it seems that with the SuSE 7.1, simplicity is no longer the case. The SuSE 7.1 manual hasn't changed much in the kernel chapter area but compiling has changed a lot. I was hoping to find my answers in this group but I only see that there are other people who are confused too. I found under the /usr/src tree there are three sources for /linux-2.2.18, /linux-2.4.0-4GB and /linux-2.4.0.SuSE. The /linux symbolic link points to /linux-2.4.0.SuSE yet there isn't much of anything there. Under /lib/modules I find /2.2.18 and /2.4.0-4GB. What is really strange is that the only source branch that actually contains source is the /linux-2.4.0.SuSE while there is no corresponding /lib/modules. It seems that none of them are complete. Worse yet is that the graphical lilo presents 3 options that arent't obvious in their matching the 3 kernel sources. instead of linux, linux 2.4 and suse, why not present names that actually correspond with the kernels. IT seems that SuSE didn't accomodate the 3 kernels in the SuSE manual. Searching the SuSE support database didn't help me either. Would you or some other SuSE person please provide a simple addendum to the SuSE 7.1 manual that covers dealing with the 3 kernels with information such as: 1. files/packages needed for each kernel build 2. do I change the /usr/src/linux symbolic link to the kernel that I intend to build? 3. any other variations from the standard SuSE 7.1 manual procedure for building a kernel I have seen several threads on this subject including this one but none of them have really made the solution any more clear for me. If a beginner like me can learn to build kernels in previous versions, it can't be a difficult process and I would really appreciate SuSE's to make it simple once again. I am really impressed with 7.1 in spite of these small errors and I hope that SuSE won't mind making this more clear to its fans. Damon Register
To what Philipp wrote I would add: Include the what, when and how for System.map, and for that file /boot/map. I haven't found a description of lilo that shows how to designate a specific system map. When I first installed SuSE 7.1 I saw vmlinuz.suse System.map-2.2.18 I haven't removed them because I don't know if the boot floppy uses them or not, but I have taken references to vmlinuz.suse out of lilo. When I recompiled the kernel I copied 'System.map' and my new kernal as vmlinuz-jlk to the /boot dir. But, NO reference is made to 'System.map' in lilo.conf. so I don't know how SuSE referenced System.map-2.2.18 and I also don't know if my System.map is being used. And I have no clue as to what /boot/map does, although it is stampted with a date-time indentical to my last compiled kernel. Having a better explaination of the whys, whens and hows of the initrd file, and what to include in it when one uses mk_initrd. The explaination in the SuSE manual assumes the reader has a lot of background knowledge that it appears only a kernel coder would possess. JLK On Saturday 10 March 2001 09:23, you wrote:
Philipp Thomas wrote:
Nope, you can't. Modules have the version of the kernel they're compiled for hardcoded into them. This will necessitate to load them with the -f flag for different kernels.
This is all rather confusing which leads me to my question. I have bought every version of SuSE since 6.2. Though just beginning I was able to easily compile the kernel with the instructions in the SuSE manual. Now it seems that with the SuSE 7.1, simplicity is no longer the case. The SuSE 7.1 manual hasn't changed much in the kernel chapter area but compiling has changed a lot. I was hoping to find my answers in this group but I only see that there are other people who are confused too.
I found under the /usr/src tree there are three sources for /linux-2.2.18, /linux-2.4.0-4GB and /linux-2.4.0.SuSE. The /linux symbolic link points to /linux-2.4.0.SuSE yet there isn't much of anything there. Under /lib/modules I find /2.2.18 and /2.4.0-4GB. What is really strange is that the only source branch that actually contains source is the /linux-2.4.0.SuSE while there is no corresponding /lib/modules. It seems that none of them are complete.
Worse yet is that the graphical lilo presents 3 options that arent't obvious in their matching the 3 kernel sources. instead of linux, linux 2.4 and suse, why not present names that actually correspond with the kernels.
IT seems that SuSE didn't accomodate the 3 kernels in the SuSE manual. Searching the SuSE support database didn't help me either. Would you or some other SuSE person please provide a simple addendum to the SuSE 7.1 manual that covers dealing with the 3 kernels with information such as: 1. files/packages needed for each kernel build 2. do I change the /usr/src/linux symbolic link to the kernel that I intend to build? 3. any other variations from the standard SuSE 7.1 manual procedure for building a kernel
I have seen several threads on this subject including this one but none of them have really made the solution any more clear for me. If a beginner like me can learn to build kernels in previous versions, it can't be a difficult process and I would really appreciate SuSE's to make it simple once again. I am really impressed with 7.1 in spite of these small errors and I hope that SuSE won't mind making this more clear to its fans.
Damon Register
On March 3, 2001 08:16 pm, Steven T. Hatton wrote:
I have probably asked this question in 15 different ways in the last month, but I feel I have only made marginal progress in understanding. I downloaded the kernel source and compiled it. All went fairly well. I'm now working on getting everything into modules which I'm hoping will be supported by the new modutils-2.4.2. One thing I still don't understand is how ALSA relates to the kernel modules. It is my understanding that ALSA provides its own modules which are distinct from the kernel's. One such module appears to be named 'snd-card-sbawe.o' and is found in /lib/modules/2.4.0-4GB/misc/ /lib/modules/2.2.18/misc/. I can see by
I think 2.4.0 moves things around much more then modutils and alsa can handle right now. What we need is a new version of alsa but until then ./configure --with-cards=ens1370 --with-moddir=/lib/modules/sound Replace the card with yours of course. That will install the alsa drivers to /lib/modules/sound. That works just fine for me. You only need to reconfigure and install the drivers after creating a new kernel. Alsa looks at /usr/src/linux [I think you can use configure to point to someplace else if you must] and then builds itself off of that. I'm assuming you are compiling alsa yourself. I haven't found a way around that if you want to create new kernels on your on. Nick
Hi, On Sat, Mar 03 2001 at 20:16 -0500, Steven T. Hatton wrote:
So what I want is: 1) My sound to work.
I'll try to explain how to compile your own kernel with the kernel sound modules. - In the kernel configuration select the following options: Loadable module support ---> [*] Enable loadable module support [*] Kernel module loader Plug and Play configuration ---> <M> Plug and Play support <M> ISA Plug and Play support Sound ---> <M> Sound card support <M> OSS sound modules <M> 100% Sound Blaster compatibles (SB16/32/64, ESS, Jazz16) support <M> AWE32 synth - Compile your kernel: `make dep clean bzlilo modules modules_install'. - Get these two files: awesfx-0.4.3a.tgz, synthgm.sbk (http://ftpsearch.lycos.com/?form=medium sould be able to locate them). - Compile and install awesfx-0.4.3a.tgz. - Install synthgm.sbk to /usr/local/awe_synth. - Add these lines to /etc/modules.conf: alias sound-slot-0 sb alias sound-service-0-1 awe_wave alias synth0 awe_wave options sound dmabuf=1 post-install awe_wave /usr/local/bin/sfxload /usr/local/awe_synth/synthgm.sbk - Run `depmod -a'. - Reboot and try if it works. Ciao, Stefan -- Stefan Troeger o _ _ _ stefan@troeger.st __o __o /\_ _ \\o (_)\__/o (_) _`\<, _`\<, _>(_) (_)/<_ \_| \ _|/' \/ (_)/(_) (_)/(_) (_) (_) (_) (_)' _\o_
participants (9)
-
Damon Register -
Jean-Fran�ois Bocquet -
Jerry Kreps -
Matthew Johnson -
Nick Zentena -
Philipp Thomas -
Stefan Troeger -
Steven T. Hatton -
Victor R. Cardona