DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
That post was written in 2000 and talks about 2.2 and 2.4 kernels. I guess perhaps things have changed.
Edit: Actually older Debian documentation also says don't build kernel headers, but new documentation and the current tools do build/download headers. As I said, I don't know what to say.
Edit again: For whatever it's worth, I'm not really arguing with any confidence. I'm just reporting what I see in Debian. Also, in my own experience, I've done it the "wrong" way for a couple of years now without any incidents.
Last edited by Telemachos; 03-01-2009 at 07:09 PM.
That post was written in 2000 and talks about 2.2 and 2.4 kernels. I guess perhaps things have changed.
Edit: Actually older Debian documentation also says don't build kernel headers, but new documentation and the current tools do build/download headers. As I said, I don't know what to say.
Edit again: For whatever it's worth, I'm not really arguing with any confidence. I'm just reporting what I see in Debian. Also, in my own experience, I've done it the "wrong" way for a couple of years now without any incidents.
Well I haven't read anything that supercedes that advice from the Head Cheese. I'd be grateful if someone could post something (other than anecdotal evidence) which does.
2.6.28.7 kernel Slackware It was a must for me to build it out side the /usr/src. I had to do the make 0=/home/user name/build/kernel this created all the symlinks for compiling later. and you must use the newest nvidia out. for some reason compiling in the /usr/src/linux it built and installed but a lot of problems with the library links. that's it plus it uses the 4vl2 but it does have the squashfs modules I like it is very smooth.
so read the compiles text cd /usr/src/linux-kernel then do the build make 0=/home/user name/build kernel oldconfig
Well I haven't read anything that supercedes that advice from the Head Cheese. I'd be grateful if someone could post something (other than anecdotal evidence) which does.
My experience is anecdotal evidence, but the Debian Kernel Handbook and the default behavior of Debian's module-assistant tool is not.
I've been Googling off and on since earlier today, and I can't find anything conclusive one way or the other. That said, I'm reasonably confident that if module-assistant's method was completely insane, lots of users would have seen the effects by now.
That said, I'm reasonably confident that if module-assistant's method was completely insane, lots of users would have seen the effects by now.
Unless it does more than just download & install kernel headers...
Another thought: Debian isn't really a "DIY" distro. You don't need to compile many things under Debian because of the huge software repository which is available in binary package form, installable with apt-get. This is probably why you've not experienced any problems.
Unless it does more than just download & install kernel headers...
Another thought: Debian isn't really a "DIY" distro. You don't need to compile many things under Debian because of the huge software repository which is available in binary package form, installable with apt-get. This is probably why you've not experienced any problems.
Yes and no. Debian defaults to using precompiled binaries with an APT tool (apt-get, aptitude, synaptic, etc.), and most users do that. However, I compile second versions of some programs rather than using the vanilla, system-wide version - eg, Perl & Ruby - and I have a few small things that Debian doesn't have so I compile those locally as well - eg, tint.
My guess is that you're right and behind the scenes, Debian somehow manages the proper connections between libc6 (Debian's glibc) and other kernel headers.
Edit: I posted a question about this on Debian Forums, so we will see if anyone there can clear this up for us.
Last edited by Telemachos; 03-02-2009 at 07:21 AM.
Reason: Added link to Debian Forums
Good idea and thanks. Please post any repsonses back here, ok?
In a nutshell, the first answer made me even more confident that building and installing new headers is fine in Debian. The old advice applied when people used to link /usr/include/linux to /usr/src/linux/include/linux and in that case, you can get problems related to glibc. However, Debian no longer (for some time, I think) creates such links and thus it simply isn't a problem.
Originally Posted by bugsbunny on the Debian forums
The /usr/include/linux tree isn't updated by any current methodology. And that tree is, in fact, part of the linux-libc-dev package and therefore linked with glibc.
There's the answer. Thanks for clearing this up Telemachos.
Apparently, under Debian, the kernel-headers package only contains the "in-tree" headers from the kernel source and not the libc headers (which are the ones which shouldn't be updated).
Slackware installs the entire kernel source tree as a single package, which I guess isn't really necessary unless you want to re-compile the kernel after installation (which many Slackers do... ).
$ aptitude search linux-image
v linux-image -
v linux-image-2.6 -
i A linux-image-2.6-486 - Linux 2.6 image on x86
p linux-image-2.6-686 - Linux 2.6 image on PPro/Celeron/PII/PIII/P
i A linux-image-2.6.26-1-486 - Linux 2.6.26 image on x86
i linux-image-2.6.26-1-686 - Linux 2.6.26 image on PPro/Celeron/PII/PII
p linux-image-2.6.26-1-686-bigmem - Linux 2.6.26 image on PPro/Celeron/PII/PII
p linux-image-2.6.26-1-amd64 - Linux 2.6.26 image on AMD64
p linux-image-2.6.26-1-openvz-686 - Linux 2.6.26 image on PPro/Celeron/PII/PII
p linux-image-2.6.26-1-vserver-68 - Linux 2.6.26 image on PPro/Celeron/PII/PII
p linux-image-2.6.26-1-vserver-68 - Linux 2.6.26 image on PPro/Celeron/PII/PII
p linux-image-2.6.26-1-xen-686 - Linux 2.6.26 image on i686, oldstyle Xen s
p linux-image-2.6.28-1-486 - Linux 2.6.28 image on x86
p linux-image-2.6.28-1-686 - Linux 2.6.28 image on PPro/Celeron/PII/PII
p linux-image-2.6.28-1-686-bigmem - Linux 2.6.28 image on PPro/Celeron/PII/PII
p linux-image-2.6.28-1-amd64 - Linux 2.6.28 image on AMD64
I should mention that I do a modest amount of apt-pinning so there are sid repos in my sources list.
cheers,
jdk
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
