PDA

View Full Version : kernel-headers? - please help



pine
12-28-2001, 10:20 AM
I have been messing with this for about 2 weeks now. I can't even get gcc3 to install because it's looking for the glibc-devel

When I try to install the glibc-devel it says:

kernel-headers is needed by glibc-devel-2.2.4-13
kernel-headers >= 2.21 is needed by glibc-devel-2.2.4-13


This is a fresh install of RH7.2

I followed the instructions to the best of my linux ability - but no go...


please advise

Mr Guy
12-28-2001, 10:31 AM
Oh crud, I know this one. It's caused by not installing one of the -devel rpms. gah for the life of me I can't think of which one.


Well for starters, try installing: kernel-headers*.rpm

pine
12-28-2001, 10:53 AM
when I check the CD for kernel-headers*.rpm

it dosn't show any... only shows kernel-BOOT, kernel-doc
kernel-debug, and kernel-source

being the n00bie that I am I wouldn't know which ones to install

any help would be great - thanks

casey
12-29-2001, 04:46 AM
install kernel-source, the headers will be there.

and compile your own kernel, stock kernels usually suck :)

pine
12-29-2001, 02:56 PM
ok, so how do you do all of that?

Yendor
12-29-2001, 03:08 PM
Pine,

look for kernel-headers-2.4.7-10.i386.rpm on your RedHat 7.2 CD (should be on the first CD).

Despite what cassey might think sticking to the vendor supplied prepackaged kernels is almost always your best bet. In anycase you should be able to find the kernel-headers rpm. You were probably looking on the second CD when they are in fact on the first.

Good luck.

casey
12-30-2001, 04:06 AM
Despite what cassey might think sticking to the vendor supplied prepackaged kernels is almost always your best bet.

i find that oddly amusing.

i prefer to cut the bloat, even the most drivers will be compiled as modules in a stock kernel, there are still a lot of things that must be compiled in, non-modularly. Each of my boxes runs a kernel specifically tailored to the hardware in that box. My gateway doesnt even have support for a video card :) and actualy, very little more than NIC, aha2920 SCSI and iptables support.

But, i'd like to hear why you thing vendor supplied stock kernels are "almost always" best, and i would prefer not to hear "its to much work to compile a kernel" :)

Yendor
12-30-2001, 10:11 AM
I used to be like you Cassey. I configured each kernel on each machine by hand. I built all software from source using the latest version at all times. I just don't have the time any more, and you know the difference isn't worth the time, especially if you manage a lot of machines.

Anyway my point is that for the average consumer you should stick with what the distro gives you. You will have fewer problems and any problems you do have will be more easily solved if you have a standard distribution. Unless you have an overwhelming reason not to.

You are the type of person who likes to be on the bleeding edge. Have the latest version of everything, because you think somehow that because it is newer it must be better. Sometimes compatibility and reliability outweigh new features, and more often than not new version (especially major version changes) just means more bugs.

I am still incredibly opposed to the move to gcc3 for instance. All it has done is vastly increase the amount of support required on the message boards. Which is contrary to the stated goal of the change to reduce support hassles. Now you will have people with bizzare installs, mixed installs, broken installs building seq and wind up with hard to diagnose problems.

Anyway to each there own. I am a convert to rpms, I love them most of the time. Its when you fight the system that you get into trouble (which happens to me a lot, because underneath I still want to build everything from scratch, lol).

Just my opinion of course. Been doing this too long I think.

casey
12-31-2001, 07:11 AM
I used to be like you Cassey. I configured each kernel on each machine by hand. I built all software from source using the latest version at all times. I just don't have the time any more, and you know the difference isn't worth the time, especially if you manage a lot of machines.

i'll clarify my above statement, you seem to think i'm doing a lot more work than i really am. Here is my build process when a new kernel comes out

cd /usr/src
wget zeus.kernel.org/pub/linux/kernel/v2.4/linux-2.4.17.tar.gz
rm linux
tar zxvf linux-2.4.17.tar.gz
mv linux linux-2.4.17
ln -s linux-2.4.17 linux
cd linux

for config in config-2.4.16.brainy config-2.4.16.azriel etc etc do
BOX = `echo $config | cut -d. -f4`
scp box:/boot/$config .config
make oldconfig
make-kpkg clean
make-kpkg binary-arch
scp ../kernel*.deb box:
rm ../kernel*.dev
done

the only part of that that requires user interaction is the make oldconfig, and usually i can get away piping "N" into that process to just answer no to everything. i dont have it automated to this point, but you can see how easy it would be to just pop this in a script, modify it to accept kernel version as an argument, and have a completely automated build process. Thats how i save time.

I dont build software from scratch as much as i used to, but i still do use bleeding edge software as you put it. Its called debian unstable, check it out sometime. apt-get keeps me "bleeding" and should i decide to build something i can get source via apt-get and build packages into debs to maintain my systems packaging integrity (or install to /usr/local/*, but i like the management debs give me).

i manage 9 machines. which brings up another good point about debian, 4 of these machines run showeq, and i dont want to build it everywhere, so i build and package qt (compiled via gcc3) and showeq into debs, build it on one box, put it into my pacakge archive (no the showeq debs are not public) and then apt-get install showeq on the 4 boxes that run it. Time saver.



Anyway my point is that for the average consumer you should stick with what the distro gives you. You will have fewer problems and any problems you do have will be more easily solved if you have a standard distribution. Unless you have an overwhelming reason not to.

then lets define average consumer not to include showeq users, and for the most part, linux users in general are not average consumers. And my advice was for whats best in my opinion, i never heard someone asking it be qualified to average consumers, but as the manual included in redhat (think average!) contains instructions on rebuilding the kernel, i stick with my original statement.



You are the type of person who likes to be on the bleeding edge. Have the latest version of everything, because you think somehow that because it is newer it must be better. Sometimes compatibility and reliability outweigh new features, and more often than not new version (especially major version changes) just means more bugs.

thanks for this insight into my soul, i hadnt realized i met you before .... I do like having new software, thats one of the reasons debian unstable suits me very well. Your assumtion of why i like newer software is off though. As for compatibiliy and reliability, if its good enough for debian unstable, its good enough for me, and i realize thats on of the risks, but should that arise, its easy enough to remedy. The rest of your statement suggests to me that since my opinions differ from yours you think i am ignorant of the general aspects of software.


I am still incredibly opposed to the move to gcc3 for instance. All it has done is vastly increase the amount of support required on the message boards. Which is contrary to the stated goal of the change to reduce support hassles. Now you will have people with bizzare installs, mixed installs, broken installs building seq and wind up with hard to diagnose problems.

good for you. It has increased support, but using the newer compiler also gives us better performance, esp since we are in effect forcing people to compile qt, which will also yeild enhanced performace. You may also notice people like Zaphod posting helpful guides for the redhat noobs, and i myself have posted some debian packages that contain qt compiled with g++-3.0.
People who dont really know what they are doing are the ones who will end up with odd installs, and it may be tough for them, but hands on is the best way to learn :) And if its really too tough, they can just wait for the inevitable Adenine! guide to installing showeq 4, that my cat will probably be able to use.



Anyway to each there own. I am a convert to rpms, I love them most of the time. Its when you fight the system that you get into trouble (which happens to me a lot, because underneath I still want to build everything from scratch, lol).

You should try out debian. If you wish to remain within the bounds of the pacakge manager (dpkg), debian is much more accomidating, not to mention that apt+dpkg provide you with a far superior package manager than rpm. apt-get -b source package <-- download package source, compile it and make a deb out of it, is the most simplistic form of building things from scratch.

Yendor
12-31-2001, 08:35 AM
Sorry if I offended you. I seriously should just keep my mouth shut. I didn't mean it to be personal and I am sorry you took it that way. I deal with sysadmins and programmers for a living and I see all types, perhaps I let that cloud my thinking. I still don't buy the gcc3 move, but I guess it's a done deal. I guess I just think it should have been left up to the user, which means either multiple libEQ's distributed or better yet the core libEQ remain C code with a C++ source wrapper around it to do whatever class thing you wanted to do with it. But perhaps increasing the complexity of libEQ (which I don't believe is much more than before) it was hoped to cut back on anyone using the decompilers to reconstruct the decryption. Just my opinion.

When a linux distribution is made completely built with gcc3 then I'd say that compiler is ready for primetime :).

casey
12-31-2001, 11:53 AM
did building a distro based on gcc 2.96 make it ready for primtime?

and offense is not the proper word, i took no offense in anything you said to me, its your image you are altering, not my feelings you are hurting.

Yendor
12-31-2001, 12:08 PM
yeah well 2.96 pissed me off to the point i ran RH6.2 on the machines I ran at work until it just became more trouble than it was worth.

But yes 2.96 was probably ready for primetime, it was just scheduled for more ABI changes that was going to render it obsolete in short order (though in retrospect it took gcc3 a long time to get to release, and going to take an even longer time to become common, so it may not have been such a bad thing... but was it really necessary for them to be on the bleeding edge and create the extra hassle... I tend to doubt it, but who knows).

I guess I am a minimalist at heart.

casey
12-31-2001, 12:21 PM
I guess I am a minimalist at heart.


another reason to run debian :) a base install will only eat about 50 megs, really nothing installed but bare bones, then you apt-get what you need as you find youself needing it.

you can get full dev, X, etc in under 200 megs total. much better than the other end of the spectrum (mandrake and its 2 gig installs)

Yendor
12-31-2001, 01:01 PM
Debian does sound interesting, would have been good to try before I upgraded to a bigger hard drive on my showeq machine (was struggling with 512Meg and RH 7.2). But in the end am just happier to have the extra space and I can now play with a bunch of other stuff. Not to mention the new drive came out of another machine which then got a spiffy new drive that makes me even happier.

casey
12-31-2001, 01:07 PM
i might have made debian sound to restricted package wise, besides a small install, you can install quite a bit of software, a compressed full package archive of debian when i was maintaining one was around 4 gigs, enough packages to fill 6 cd's if it were to be packaged that way (these were all binary-all and binary-i386 pacakges).

if you find yourself reinstalling you rlinux box at any time, i recommend trying debian out.

Yendor
12-31-2001, 01:14 PM
I might do that. Been using redhat because I had to use it where I worked last because of driver support issues for custom hardware we developed. (ie the component manufacturer supplied a RH driver and refused to budge on providing source or producing versions compatible with new kernel releases over time). So I always tried to stay compatible with my work environment as I was always down fighting stuff at the driver and kernel level and didn't want to have to tell my boss "ummm... well, it worked at home!". Heh. Well I am not doing that anymore so I guess I've just stuck with it out of habit.

So next home computer that gets surplused to showeq duty I will try another distro. :)