Kernel Sources

For all of those awaiting a more permenant fix to bug #85559, this has now been done. Hopefully you vanilla-sources users (specifically) will benefit from a big bandwidth saving.

Also on a similar note, there has been a lot of confusion recently about 2.4/2.6 kernel versions and headers. Let me clear this up.

Many moons ago portage didnt have support for cascading profiles, although the 2.5 kernel had just been made 2.6 and progress was being made on stabalising support for it in Gentoo. The issues we had meant that we had to rename the 2.6 versions into a new package. For example: linux-headers contained 2.4, and linux26-headers contained 2.6.
This meant that managing the dependancies within ebuilds was awkward and amongst other things, far from ideal.
It was also an illogical seperation of what is fundementally the same thing. You dont for example see vim5 vim6 etc, you just have vim.

Now then, what we did recently, with the help of cascading profiles was amalgamate these packages into their relevant counter-parts. Therefore, we now have vanilla-sources-2.{0,2,4,6}* and linux-headers-2.{4,6}* and it is up to the profiles you run to manage which versions should be unmasked for you.
As part of this move we also moved to 2.6 by default for many architectures. As a result, and in true gentoo philosophy, you will find underneath your profile either a 2.6 or most likely a 2.4 subdirectory. If you link your profile to that directory instead then you will no longer be forced to update to 2.6, however I do encourage you to upgrade if you have no valid technical reason to stay.

So with this concludes:
emerge yourfavourite-sources will emerge 2.4, OR 2.6 depending on your profile. Most likely 2.6
emerge linux-headers will merge the appropriate headers.

IF you are upgrading from 2.4 to the newer 2.6 as part of this move, PLEASE PLEASE ensure your new kernel is installed and running along side your new 2.6 headers, since there are several reports of random segfaults occuring with 2.6 headers on a 2.4 kernel.

If you find that its installing a version you dont want, then just relink your /etc/make.profile to ${PORTDIR}/profiles/default-linux/x86/2005.0/XX where XX is 2.4 (or 2.6 on different archs in some cases).

Hopefully this has now brought some clarity to the situation 🙂

9 thoughts on “Kernel Sources”

  2. I think the move was due and I don’t discuss that. What I deplore is the cowboy way that this update has been done. By simply adding a 2.6 version to the linux-header group, it provoked an update for those who had been using the 2.4 version without using spcific cascaded profile.

    I run a mix of 2.4 and 2.6. On the Openmosix cluster nodes, it did not hit me that the linux-headers would be upgraded from 2.4 to 2.6. I then had segfaults on subsequent emerges.

    All in all, I had to manage this to find what went wrong, learn how to fix it, and reverse the damages. Lost of time, lost of confidence toward the Gentoo sumities that take those kinds of decisions. Sometimes, introductions of changes are managed with what seems to be (in my view) amateurism. It’s my personal opinion.

  3. Hi TJ, thanks for the feedback.
    Just to run by a few of the above comments.

    Of course I understand your point of view, however for 2 issues in the GWN before the release, we stated how important it was to change to a cascading profile upon the release date to avoid this mass upgrade. We tried to advertise as loudly as possible about the migration documents and so on.

    keeping linux26-headers and linux-headers was fundementally wrong, as stated above since this becomes very problematic from a porage point of view.

    This was one of the most radical changes we (the Kernel Team) have had to make in quite some time. If you could donate some examples of how we might be able to improve this kind of announcement in future then they will be welcome.

  4. Overall, I’m glad Gentoo has made the 2.6 kernel the default, while providing a way to keep 2.4 kernels around. Gentoo continues to be my distro of choice for many reasons. I have to agree, however, that notification of the header conflict could have been better advertised beforehand.

    One way to provide advanced warning for upcoming changes such as with linux-headers is to write a message that is displayed before or after an emerge. This has been done with other packages. It is much more likely to be seen, and with direct relevance to the issue, than putting the information in the weekly newsletter. As good as it is, not everyone reads the GWN.

  5. interesting concept actually that you recommend using einfo’s as a way to put forward changes. However, would this not be too late? lets face it, the kernel headers really didnt change for most people, and by the time they did, it would have been too late to read since you just got upgraded to 2.6?

    Or perhaps I’m missing what you mean. Anyways, this move was due, and thankfully its all turned out remarkably well.

  6. I was stumped on migrating from 2.4 to 2.6 headers as i’ve read this site up and down..but then again i noticed johnm wrot:

    “If you find that its installing a version you dont want, then just relink your /etc/make.profile to ${PORTDIR}/profiles/default-linux/x86/2005.0/XX where XX is 2.4 (or 2.6 on different archs in some cases).”

    which that is mistaken due to no 2.6 being listed in that dir. I then spoke with johnm and its default for 2.6 headers is just symlinking /etc/make.profile to ${PORTDIR}/profiles/default-linux/x86/2005.0/

Comments are closed.