Re: [gentoo-user] use of /usr/src/linux symlink
Peter Ruskin wrote: ebegin Checking that /usr/src/linux is linked to booted kernel... if [ /usr/src/linux-$(uname -r) != $(ls -l /usr/src/linux|cut -f2 -d\|cut -f2,3,4 -d' ') ] This looks more complicated than it really should be. Just run ln on reboot (stolen from your post): rm -f /usr/src/linux ln -s /usr/src/linux-$(uname -r) /usr/src/linux Best regards, -- Norberto wants an AMD64 system right now! Bensa 4544-9692 Ciudad de Buenos Aires, Argentina -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
Norberto Bensa schreef: Peter Ruskin wrote: ebegin Checking that /usr/src/linux is linked to booted kernel... if [ /usr/src/linux-$(uname -r) != $(ls -l /usr/src/linux|cut -f2 -d\|cut -f2,3,4 -d' ') ] This looks more complicated than it really should be. Just run ln on reboot (stolen from your post): rm -f /usr/src/linux ln -s /usr/src/linux-$(uname -r) /usr/src/linux Thanks for the tip-- but (no offense meant) who cares? Can someone tell me on what basis this *needs* to be done as a standard operation? -- If you have some external module that compiles against the kernel source, you most likely need it against *all* kernel sources, not just the running one (so redirecting the link is only of limited usefulness); -- If you need some external module compiled against the kernel source and you don't have it (thus needing to compile it against the currently running kernel), then there's likely to be something seriously wrong with that boot anyway (you don't have 3D hardware acceleration, you don't have wireless networking, you don't have sound-- whatever the external module in question is), so you're much less likely to boot it as a matter of course... Not that you wouldn't want to try to fix it, and if you did try, you would naturally want to compile the external modules against that kernel source, but that doesn't by a long shot add up to redirecting the /linux symlink every time you boot; --makes no provision for newly-installed/upgraded kernel sources, which imo need the symlink more than old, already compiled kernels. Or rather, if you redirect the symlink to the currently running kernel at boot, you have to redirect it again to your about-to-be-installed kernel in order to compile the external modules against it anyway, so why do extra work-- either you wait till you compile and boot the new kernel to redirect the symlink (at which point you've got a half-broke system because the needed external modules have not yet been compiled because the symlink was not redirected unless you use the symlink USE flag when emerging, which rather negates the point of having redirected the symlink to the currently-running kernel), then compile the external modules, then reboot to load the external modules (depending on the module), or you redirect the symlink manually before compiling the newly-installed source, which (again) negates the purpose of redirecting the symlink automatically at boot (rather than via the USE flag during emerge) in the first place? Not getting it at all. How many kernels does one keep in a bootable state, anyway-- and use commonly, without needed external modules, no less-- that this would be necessary? Really, truly, not getting the point. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
051109 Holly Bostick wrote: Can someone tell me on what basis this *needs* to be done as a standard operation? Not getting it at all. How many kernels does one keep in a bootable state, anyway -- and use commonly, without needed external modules, no less -- that this would be necessary? Really, truly, not getting the point. Switching kernels is not like using a different browser or editor. I now have 2.6.14 working ok (still ~x86), but am keeping 2.6.12 (may be soon to go) 2.6.9 around in case something unexpected happens with 2.6.14 . However, if I want to use 2.6.12 , I will have to recompile Nvidia reset the display for Gkrellm might even find something else needs doing. Some apps do depend on the version of the kernel you are using. Maybe I'm not getting what you're not getting ... (smile) -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
On Wed, Nov 09, 2005 at 10:28:04AM -0500, Philip Webb wrote: 051109 Holly Bostick wrote: Can someone tell me on what basis this *needs* to be done as a standard operation? Not getting it at all. How many kernels does one keep in a bootable state, anyway -- and use commonly, without needed external modules, no less -- that this would be necessary? Really, truly, not getting the point. Switching kernels is not like using a different browser or editor. I now have 2.6.14 working ok (still ~x86), but am keeping 2.6.12 (may be soon to go) 2.6.9 around in case something unexpected happens with 2.6.14 . However, if I want to use 2.6.12 , I will have to recompile Nvidia reset the display for Gkrellm might even find something else needs doing. Some apps do depend on the version of the kernel you are using. Maybe I'm not getting what you're not getting ... (smile) Why do you have to recompile NVidia? Every time I do a kernel upgrade, I compile NVidia against the kernel. But so long as you don't remove the old kernel module or do a new compile of the old kernel, you should be able to book back into the old kernel just fine. On my laptop for example, /lib/modules/2.6.7-(something) and /lib/modules/2.6.10-(something) both exist and each contains its version of bcm5700, ipw2200. With the exception that I use the Xorg drivers for radeon on .10 and fglrx on .7, the setup is identical. The small difference can be easily overcome by commenting out some lines in modules.autoload /usr/src/linux is not used AT ALL in the boot process. There's no need to change that symlink if you just need to boot into another kernel to troubleshoot your machine. It is purely compile-time, and aside from kernel-hackers, most of us usually only compile one kernel one time followed by ext. modules. So I agree with Holly that changing the symlink on every boot is silly and a waste of effort SO LONG AS you (the user) remember to update the symlink before you compile stuff against the kernel. W -- Yan Can Cook and George Lucas have a new joint-venture web site, titled eWok. Sortir en Pantoufles: up 6 days, 17:15 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
On Thu, 10 Nov 2005 04:54, Holly Bostick wrote: Secondly, you're *using* 2.6.14, and you're keeping 2.6.12 around as a fallback. It's very unlikely you're going to actually boot into 2.6.9, and while you may boot into 2.6.12, you are not in fact doing so (because 2.6.14 is working OK). So what is the need for this symlink redirection? For my part I'm playing round with the kernel source in several custom versions and rebooting often when testing for some things. Doing that several times in an hour, re-making the simlink manually can be tedious. So it just takes some of the drudgery out of manually performing this every time. And you know that when you boot the kernel source is in a sane state even if you forgot that you had booted back into your stable kernel and for example there is a new nvidia version available. -- Isn't it ironic that many men spend a great part of their lives avoiding marriage while single-mindedly pursuing those things that would make them better prospects? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
On Wed, Nov 09, 2005 at 03:35:42PM +0100, Holly Bostick wrote: Norberto Bensa schreef: Peter Ruskin wrote: ebegin Checking that /usr/src/linux is linked to booted kernel... if [ /usr/src/linux-$(uname -r) != $(ls -l /usr/src/linux|cut -f2 -d\|cut -f2,3,4 -d' ') ] This looks more complicated than it really should be. Just run ln on reboot (stolen from your post): rm -f /usr/src/linux ln -s /usr/src/linux-$(uname -r) /usr/src/linux Thanks for the tip-- but (no offense meant) who cares? Norbertos suggestion and Peters refinement were useful to me as examples of one plausible interpretation of what /usr/src/linux symlink should be - a shorthand way of finding the source for the running kernel. I was glad to see that I was not the only one who was not clear on its intended use, and hence how it should be maintained. Can someone tell me on what basis this *needs* to be done as a standard operation? If it were done as standard, then it would make the commonly held assumption that it points to the currently running kernel correct unless an explicit action had been taken by a super user since the last reboot... But that is a justification or argument for doing so - it appears from what you say that there is no *need* for it to be so (although the same could be said about an awful lot of the Unix/Linux filesystem organization - it is arbitrary until some application or process that you use is written to depend on it).. -- If you have some external module that compiles against the kernel source, you most likely need it against *all* kernel sources, not just the running one (so redirecting the link is only of limited usefulness); Ok - this seems to be the bit that I am a little unclear on. If there are, as indicated in your earlier response (which I was still mulling over) applications, libraries and external kernel modules that need to be compiled against a kernel, and we want to be able to use grubs ability to select from a choice of kernels, what is the mechanism by these we ensure the correct applications, libraries and external kernel modules (lets call them 'objects' to avoid having to list the possibilities each time - not to be confused with the current trendy programming paradigm) are used for the currently running kernel? If the binaries are to be stored in a kernel dependent location, like the kernel modules build within the kernel source tree that are built to /lib/modules/kernel-version, then /usr/src/linux cannot really be being used as a symlink (ie a way of accessing the kernel files without needing to know which version it is) because the build process will need to know the target kernel version in order to make the directory names or tag. In effect, it could equally well be a file called '/usr/src/build-kernel' which contains the version number of the kernel being compiled for...? Anyway, if I understand you correctly, if you are not building anything, then it doesn't matter. And there is certainly no justification is assuming you are building for the kernel that is currently running. Right? Presumably these kernel dependent objects only need emerge to download the source once, but then must be rebuilt once for each kernel you want to install - right? And somehow the binaries will be kept separate and the correct ones chosen at boot time based on the active kernels knowledge of its own version identity. Is this what 'sys-kernel/module-rebuild' is intended to take care or for us? So we just /usr/src/linux to the newly installed kernel and run module-rebuild and the kernel dependent modules will all be made for the new (or modified) kernel. It seems that the desirablility of having the boot process automatically update the symlink depends on how much you want to be able to use /usr/src/linux as a shorthand for manually typing /usr/src/linux-`uname -r`, which is probably a bit arcane for a nieve user... Not getting it at all. How many kernels does one keep in a bootable state, anyway-- and use commonly, without needed external modules, no less-- that this would be necessary? I typically have 3-4. The current which I think is fully working, the previous kernel just in case I discover I was wrong and had forgotten to test something vital, and the new kernel which I am in the process of installing but havn't finished testing enough to use when doing something important or letting others on the system.. I also have several kernels which boot to different filesystems (eg the old SuSE system because its crypto filesystem is not compatible with the gentoo one) and alternate operating systems such as BSD/Plan9/Inferno/OS-9000 - can't think of any others worth running just now ;) But being different filesystems, they arn't relevent to the /usr/src/linux link question. Regards, DigbyT -- Digby R. S. Tarvin [EMAIL PROTECTED] http://www.digbyt.com -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
Rumen Yotov wrote: On Tue, 2005-11-08 at 17:18 +, Digby Tarvin wrote: Something which I havn't found any explicit elaboration of in the documentation... The convention in the Linux/gentoo filesystem seems to be to have a unique directory for each installed kernel in /usr/src, with a symbolic link to the 'current' kernel directory named /usr/src/linux.. The question is - is this just a user convenience, or will parts of the system break if it is not maintained correctly? The reason I ask is that if I have several kernels which I have configured grub to allow me to select from at boot time, where should this symlink point? The newest kernel? An experimental one being worked on? The one most recently booted from. If the latter case then it is likely to be wrong for a finite period following boot until the system has come up far enough to allow me to update it. Anyone know what is likely to break (if anything) if I boot from a kernel other than the one which corresponds to the directory /usr/src/linux points to, and neglect to update the link? Does it direct (for instance) the target directory for an emerge of new kernel components? Or does it perhaps have to point to the kernel being built during any recompile? Regards, DigbyT -- Digby R. S. Tarvin [EMAIL PROTECTED] http://www.digbyt.com Hi, There seems to exist at least two current kernels - one is the kernel to which /usr/src/linux points, this one is used by most (all ?) kernel-module programs (i have 3 of them: nvidia, arpstar, loop-aes; had also alsa-driver). When you compile/recompile any one of them they use the kernel sources pointed by /usr/src/linux. Patch kernel sources too (e.g. l7-filter). The second kernel is your running kernel (available by uname -r) this one is the one actually running at any givenn time. Don't have any examples of something using this one. Anybody here? HTH.Rumen Changed my symlink to point to 2.6.12-gentoo-r10, compiling ndiswrapper 1.5 is using running kernel 2.6.13 #ls -al lrwxrwxrwx 1 root root 24 Nov 8 12:57 linux - linux-2.6.12-gentoo-r10/ #make make -C driver make[1]: Entering directory `/root/ndiswrapper-1.5/driver' make -C /lib/modules/2.6.13-gentoo-r3/build SUBDIRS=/root/ndiswrapper-1.5/driver \ DRIVER_VERSION=1.5 make[2]: Entering directory `/usr/src/linux-2.6.13-gentoo-r3' Building modules, stage 2. MODPOST Chris -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
On Wed, 9 Nov 2005 16:34:03 +, Digby Tarvin wrote: Norbertos suggestion and Peters refinement were useful to me as examples of one plausible interpretation of what /usr/src/linux symlink should be - a shorthand way of finding the source for the running kernel. But it is not. As soon as you install a new kernel source, even before you configure and compile it, the symlink no longer indicates the current kernel. uname -r shows the current kernel, with it's source at /usr/src/linux-$(uname -r) -- Neil Bothwick If you think the problem is bad now, just wait until we've solved it. signature.asc Description: PGP signature
Re: [gentoo-user] use of /usr/src/linux symlink
Digby Tarvin schreef: On Wed, Nov 09, 2005 at 03:35:42PM +0100, Holly Bostick wrote: -- If you have some external module that compiles against the kernel source, you most likely need it against *all* kernel sources, not just the running one (so redirecting the link is only of limited usefulness); Ok - this seems to be the bit that I am a little unclear on. If there are, as indicated in your earlier response (which I was still mulling over) applications, libraries and external kernel modules that need to be compiled against a kernel, Not against a kernel. Against a kernel *source*. These are not the same thing. The kernel you actually boot is a binary file, compiled from the source in /usr/src/whatever. When it is compiled, you copy the binary to /boot, and that is what you boot. That is the meaning of 'make install'. Like any binary, once compiled it is 'detatched', let us say, from the source, and is no longer related to it in that any changes to the source do not affect the compiled binary-- if you make a change to the source, you have to recompile the binary to reflect the changes in the new binary. and we want to be able to use grubs ability to select from a choice of kernels, what is the mechanism by these we ensure the correct applications, libraries and external kernel modules (lets call them 'objects' to avoid having to list the possibilities each time - not to be confused with the current trendy programming paradigm) are used for the currently running kernel? If you compiled the objects against the source of the kernel under consideration -- and this is the purpose of the /usr/src/linux symlink, to tell the emerge which kernel source the objects should be compiled against, then they are compiled against the source of the kernel Let me put it this way. ati-drivers (the proprietary drivers for ATI video cards) are an external kernel module. External, because they are not contained in the kernel source (being proprietary), but a kernel module because they 'hook' into the kernel as a normal module. When I compile them, here is the beginning of the output: Determining the location of the kernel source code Found kernel source directory: /usr/src/linux Found sources for kernel version: 2.6.13-gentoo-r4 Checking for MTRR support enabled ... Checking for AGP support enabled ... Checking for DRM support disabled ... X11 implementation is xorg-x11. | Unpacking source... Unpacking Ati drivers ... The drivers, like all other drivers, need certain kernel functions to be available (or not available) in order to operate correctly; so because this driver must compile against the kernel source, the script checks to confirm that the necessary kernel functions are enabled/disabled prior to compiling.This is why you must compile against a *configured* kernel source (it need not be compiled, but it must be configured, so that the script can determine what functions will be available in the kernel binary). As you see, this emerge of the ATI drivers compiled against the source of 2.6.13-gentoo-r4, because that was where the /usr/src/symlink was pointing when I performed the emerge. This was in fact an upgrade to the driver, and 2.6.13-r4 was my currently-running kernel. However, later, I downloaded and configured 2.6.14, and re-emerged the ATI drivers (I use the symlink USE flag, so the symlink was automatically redirected): Determining the location of the kernel source code Found kernel source directory: /usr/src/linux Found sources for kernel version: 2.6.14-gentoo Checking for MTRR support enabled ... Checking for AGP support enabled ... Checking for DRM support disabled ... X11 implementation is xorg-x11. | Unpacking source... This emerge compiled against the source of 2.6.14-gentoo, because the /usr/src/linux symlink was redirected to the source of that kernel. Both kernels now have the ATI drivers compiled for them, because when compiled (either during a kernel compile, or an external module compile), modules are placed in a kernel-specific directory: la /lib/modules totaal 9 drwxr-xr-x 12 root root 384 nov 7 15:43 . drwxr-xr-x 12 root root 5688 nov 7 16:34 .. drwxr-xr-x 5 root root 472 mei 25 17:29 2.6.11-ck8-r1 drwxr-xr-x 4 root root 448 jul 24 00:04 2.6.11-gentoo-r11 drwxr-xr-x 5 root root 472 jun 15 03:06 2.6.11-gentoo-r6 drwxr-xr-x 5 root root 472 jul 7 02:17 2.6.11-gentoo-r8 drwxr-xr-x 6 root root 496 okt 13 14:53 2.6.12-gentoo-r10 drwxr-xr-x 4 root root 448 aug 19 06:36 2.6.12-gentoo-r6 drwxr-xr-x 4 root root 448 sep 2 05:39 2.6.12-gentoo-r9 drwxr-xr-x 6 root root 496 nov 7 18:30 2.6.13-gentoo-r4 drwxr-xr-x 6 root root 496 nov 7 19:03 2.6.14-gentoo and within it: la /lib/modules/2.6.13-gentoo-r4/video totaal 317 drwxr-xr-x 2 root root 72 nov 7 18:00 . drwxr-xr-x 6 root root496 nov 7 18:30 .. -rw-r--r-- 1 root root 321951 nov 7 18:00 fglrx.ko la /lib/modules/2.6.14-gentoo/video totaal 317
Re: [gentoo-user] use of /usr/src/linux symlink
- Original Message - From: Philip Webb [EMAIL PROTECTED] To: gentoo-user@lists.gentoo.org Sent: Wednesday, November 09, 2005 10:28 AM Subject: Re: [gentoo-user] use of /usr/src/linux symlink 051109 Holly Bostick wrote: Can someone tell me on what basis this *needs* to be done as a standard operation? Not getting it at all. How many kernels does one keep in a bootable state, anyway -- and use commonly, without needed external modules, no less -- that this would be necessary? Really, truly, not getting the point. Switching kernels is not like using a different browser or editor. I now have 2.6.14 working ok (still ~x86), but am keeping 2.6.12 (may be soon to go) 2.6.9 around in case something unexpected happens with 2.6.14 . However, if I want to use 2.6.12 , I will have to recompile Nvidia reset the display for Gkrellm might even find something else needs doing. Some apps do depend on the version of the kernel you are using. Maybe I'm not getting what you're not getting ... (smile) I've compiled many hundreds of kernels over the years on lots of linux distros, including Gentoo ~x86 systems, and it's perfectly acceptable to compile as user in /home/user/kernels, and then su to root for modules install and copying/renaming over bzImage to /boot. I generally have anywhere from 4-8 experimental kernels listed in grub.conf. I use to not worry about making the linux symlink in /usr/src point to my currently running kernel every time, but lately I've taken to redoing it each time I compile a new kernel, as I've found more and more that emerging programs look for a kernel symlink in /usr/src, and if it isn't there, emerge fails. I guess it depends on how much updating and compiling you do as too how aggrevating this would become, but since it's no big deal to change it, I'd recommend doing it as a matter of course, so you don't have to stop and do it during an emerge session. Robert Crawford -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.8/163 - Release Date: 11/8/2005 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
On Wed, Nov 09, 2005 at 11:59:43AM -0500, Chris Fairles wrote: Changed my symlink to point to 2.6.12-gentoo-r10, compiling ndiswrapper 1.5 is using running kernel 2.6.13 .. make[2]: Entering directory `/usr/src/linux-2.6.13-gentoo-r3' Building modules, stage 2. MODPOST Oops - seems like even kernel code developers are not all of one mind when it comes to what the convention is regarding the /usr/src/linux sym link. I think my preference would be to make the intention more explicit - it a symlink is for use by scripts and makefile then it can be verbose, such as /usr/src/current_buid_kernel which can be accompanied with a separate link to be used a shorthand for the current kernel by human users, such as /usr/src/sys which could be set correctly during boot. (linux would really need to be left as a confusing link for compatability) Regards, DigbyT -- Digby R. S. Tarvin [EMAIL PROTECTED] http://www.digbyt.com -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
On 11/9/05, Robert Crawford [EMAIL PROTECTED] wrote: I use to not worry about making the linux symlink in /usr/src point to my currently running kernel every time, but lately I've taken to redoing it each time I compile a new kernel, as I've found more and more that emerging programs look for a kernel symlink in /usr/src, and if it isn't there, emerge fails. No _program_ should be looking at kernel sources. If there is a userspace program that fails to compile without a link to the current kernel sources, you should file a bug report against it. Only external kernel modules should require a link to the kernel sources, and then only for the sources you want to build the module against, not the currently running version. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
051109 Holly Bostick wrote: Philip Webb schreef: I have 2.6.14 working ok (still ~x86), but am keeping 2.6.12 2.6.9 around in case something unexpected happens with 2.6.14 . However, if I want to use 2.6.12 , I will have to recompile Nvidia. Why? Yes (pink face): as I now realise after reading eg Willie Wong's comment, external modules are stored in /lib/modules/kernel-version/ remain there for the appropriate kernel to use (unless you delete them). I could not get Nvidia to work with 2.6.9 (problem with Nvidia version), so 12 - 14 is the 1st time I've updated Nvidia for a new kernel version. reset the display for Gkrellm There is a bug in Gkrellm (Gentoo # 104805): the temperature + fan display disappears whenever you change the kernel you have to R-click configure it to display again. Maybe I'm not getting what you're not getting ... (smile) Now I am ... (smile) -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
On Tue, 08 Nov 2005 19:40:59 +0200 Rumen Yotov wrote: Hi, There seems to exist at least two current kernels - one is the kernel to which /usr/src/linux points, this one is used by most (all ?) kernel-module programs (i have 3 of them: nvidia, arpstar, loop-aes; had also alsa-driver). When you compile/recompile any one of them they use the kernel sources pointed by /usr/src/linux. Patch kernel sources too (e.g. l7-filter). The second kernel is your running kernel (available by uname -r) this one is the one actually running at any givenn time. Don't have any examples of something using this one. Anybody here? HTH.Rumen What i think you mean is that there are two ways of referencing what may be the correct kernel to compile against :-). However In addition to: /usr/src/linux ; (method 1) and /usr/src/linux-`uname -r` (method 2) There are many packages out there that find the linux sources by looking for: /lib/modules/`uname -r`/build - (method 3) which is a symlink to the sources those modules were built from. Not all ebuilds use method 1 to find the kernel version. cd /usr/portage grep uname -r * -r reveals any number of ebuilds that refer to uname -r as a way of determining the kernel version. Also many packages use either method 2 or method 3 in their internal config script or makefile. -- Nick Rout [EMAIL PROTECTED] -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
On Thu, 10 Nov 2005 06:37, Robert Crawford wrote: I guess it depends on how much updating and compiling you do as too how aggrevating this would become, but since it's no big deal to change it, I'd recommend doing it as a matter of course, so you don't have to stop and do it during an emerge session. Robert Crawford Exactly. Well said. On that note I don't think it needs to be something for the gentoo init scripts to implement, its more a handy thing for users to implement if they wish to, making their day easier :) -- ...all the good computer designs are bootlegged; the formally planned products, if they are built at all, are dogs! bo-- David E. Lundstrom, A Few Good Men From Univac, MIT Press, 1987 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] use of /usr/src/linux symlink
Digby Tarvin schreef: Something which I havn't found any explicit elaboration of in the documentation... The convention in the Linux/gentoo filesystem seems to be to have a unique directory for each installed kernel in /usr/src, with a symbolic link to the 'current' kernel directory named /usr/src/linux.. The question is - is this just a user convenience, or will parts of the system break if it is not maintained correctly? The reason I ask is that if I have several kernels which I have configured grub to allow me to select from at boot time, where should this symlink point? The newest kernel? An experimental one being worked on? The one most recently booted from. If the latter case then it is likely to be wrong for a finite period following boot until the system has come up far enough to allow me to update it. The symlink has nothing to do with the compiled kernels in /boot at all. What it has to do with are applications, libraries and external kernel modules that are compiled against the kernel source. For example, ati-drivers is a kernel module which compiles against the kernel source. In order for it to do so, it needs to know what kernel source to compile against. The easiest way for it to know that is for it to seek the target of the /usr/src/linux symlink, which generally points to either 1) the source of the currently running kernel, or 2) the source of the kernel that *will* be the currently-running kernel, after you compile/install/reboot to it. Anyone know what is likely to break (if anything) if I boot from a kernel other than the one which corresponds to the directory /usr/src/linux points to, and neglect to update the link? Does it direct (for instance) the target directory for an emerge of new kernel components? Or does it perhaps have to point to the kernel being built during any recompile? Nothing, no (all internal kernel components are in the kernel source, and if you are emerging external kernel modules, they'll just be compiled against some other kernel than the one you're booting to, so they won't be available for that kernel-- but that is not, strictly speaking, broken), and no, whatever recompile you might be doing is unrelated to the symlink, unless it involves external kernel modules or one of the relatively rare applications or libraries that compile directly against the kernel source. You might consider, however, activating the symlink USE flag, which will update the symlink when you install a new kernel source. Hope this helps. Holly Regards, DigbyT -- gentoo-user@gentoo.org mailing list
