Salut, Let me get straight down to the scenario - I would like to begin a stage1 installation, and while at that, I'd rather have a 2.6 glibc nptl bootstrapped system, rather than recompiling glibc (monstrous, even on my AMD 3200+) after install. Though, quite possible, I think the newest livecd requires some minor modifications described in steps below (mainly due to the migration of 2.6 headers into a different dir): 0. Ah, of course we need the smp kernel (not really smp, but we need a 2.6 kernel from the livecd) 1. After extracting the stage1 tarball, just before running bootstrap-26.sh we shall need to remove the default 2.4 headers - otherwise glibc won't compile with nptl emerge unmerege linux-headers 2. Then we update virtuals file - /etc/make.profile/virtuals and actually change virtual/os-headers sys-kernel/linux-headers to virtual/os-headers sys-kernel/linux26-headers (I also changed virtual/kernel sys-kernel/linux-headers to virtual/kernel sys-kernel/linux26-headers) just in case (dunno if the build actually looks into it) this step is needed in order to tell bootstrap-26.sh to install the 2.6 headers 3. Now, we shall need to emerge the 2.6 headers (bootstrap will emerge them once more), but w/o them portage won't compile ;-) emerge linux26-headers 4. Now, already, we can safely run script/bootstrap-26.sh That should be all. Please note, I can overdo things, or perhaps I'm wrong at something, please do correct me, I'm just describing what I did to have a 2.6 glibc enabled system at install. Perhaps this entire description should be better though of in the next livecd and maybe included in the handbook - deal as appropriate - thanks for the attention.
bootstrap-26.sh was written to take care that 2.6-series kernel-headers get pulled into the system, so you should be running fine, by just running that script...or is here anything I am missing with your bugreport?
Yes, I thought so, because of the ... then # Check if the user have 'nptl' in USE, and if so, check if we # have proper linux headers ... if [ "${ORIGUSE}" != "${ORIGUSE/nptl}" -a \ "${ORIGUSE}" = "${ORIGUSE/-nptl}" ] && \ [ -z "`portageq best_visible / '>=sys-kernel/linux26-headers-2.6.0'`" ] then echo eerror "You need to have >=sys-kernel/linux26-headers-2.6.0 unmasked!" eerror "Please edit the latest >=sys-kernel/linux26-headers-2.6.0 package," eerror "and add your ARCH to KEYWORDS." echo cleanup 1 fi else ... part Yet, could you please double-check this portion of the script, since last time I installed (off the 2004.2 Universal CD) I had to resort to the above-described steps... (and yes, I did have nptl @ make.conf)...
There's no need for #2... Also, there was no mention of it in the handbook because we do not yet support bootstrapping with 2.6 headers.
This was a week ago, so perhaps the linux24 headers turned out as blockers, yet I guarantee you I had to resort to these steps described above. #2, OK, it is geeks mostly anyway :)
Same for me... I have to modify scripts/bootstrap-2.6.sh and sys-kernel/linux26-headers to get the bootstrap-2.6.sh working... modify the linux26-headers and mremove the block for the linux-headers (I think the patch 2.5.9 is there to patch over a 2.4, didn't he? it didn't work if I simply remove the linux-headers) and modify the script to use linux26-headers or modify /etc/make.profile/virtuals and modify linux-headers into linux26-header If I don't do this modifications, the glibc compile fail because I use the nptl flab without using 2.6 kernel (but this is why we use bootstrap-2.6, isn't it?)
Hehe, thanks for the secondment ;-) I was starting to question my sanity :)
bootstrap-cascade.sh also tries to install linux26-headers, but it fails, since linux26-headers are blocked by linux-headers. bootstrap-scripts should be preared for such cases. Workaround: - emerge --nodeps linux26-headers - emerge unmerge linux-headers execute both statement prior to executing bootstrap-cascade.sh. The final sollution should be, that bootstrap-cascade.sh (which will replace the boostrap.sh and bootstrap-26.sh in the future) uninstalls linux-headers prior to or after installing linux26-headers.
reading my notes from bootstrap-cascade.sh # We can't unmerge headers which may or may not exist yet. If your # trying to use nptl, it may be needed to flush out any old headers # before fully bootstrapping. #emerge ${STRAP_EMERGE_OPTS} -C virtual/os-headers || cleanup 1 emerge ${STRAP_EMERGE_OPTS} ${myOS_HEADERS} ${myTEXINFO} ${myGETTEXT} ${myBINUTILS} || cleanup The code is there to unmerge the headers but it needs work as I think it failed before and thus had to be commented out. Somebody that's using 2.6.x should do some real testing with this. You may need to blindly call an emerge -C linux-headers linux26-headers 2>&1 > /dev/null or even -C linux26-headers linux-headers virtual/os-headers virtual/kernel-headers After this is done and tested it should be time to move the script over from bootstrap-cascade.sh to bootstrap.sh
Can you emerge the headers without headers available?
You can execute the two statements - emerge --nodeps linux26-headers - emerge unmerge linux-headers in the order i wrote them! with --nodeps, linux26-headers won't complain about linux-headers blocking it. BTW: bootstrap-cascade.sh can do that too! bootstrap-cascade.sh has two choices: a) run "emerge --nodeps linux-headers" and unmerge linux26-headers if it is installed b) run "emerge --nodeps lunux26-headers" and unmerge linux-headers if they are installed If bootstrap-casecade.sh could do that, that would be fine.
Ohh, i'm wrong. bootstrap-cascade.sh usually wants to emerge "virtual/os-headers", so the two things bootstrap-cascade.sh can do are: a) run "emerge virtual/os-headers" b) run "emerge --nodeps lunux26-headers" and unmerge linux-headers if they are installed That should run fine.
Any update on this bug? I'm still encountering this with a 2004.3 stage1. It doesn't seem to unmerge the previous linux-headers so glibc thinks that it only has the 2.4 headers when both are actually installed. Could this be a provide issue?
Well, release@ doesn't really have anything to do with the bootstrap scripts. We build the release media and that's it. I honestly cannot tell you who is responsible for the bootstrap scripts, but it isn't release@ or livecd@ as we are reponsible for the release media, and the packages used to build the release media.
The problem is the stage1 tarball that is being used. If it has 2.4 headers in it, then it'll block the 2.6 headers. This is actually going to resolve itself, at least for 2005.0 and beyond, as the 2.4 and 2.6 headers are going to be merged back into a single package. At that point, it is a matter of which headers get used being determined by the profile being used, so there's no logic needed to change headers, portage will simply either merge a newer version, or downgrade the package to an older version depending on the profile used.
i often do i have to say, that bootstrap.sh could do emerge --nodeps lunux26-headers emerge unmerge linux-headers because of the "--nodeps", linux26-headers does not block the installed linux-headers. bootstrap.sh _can_ do it, there are also several other ways, but it seems that you're to lazy to program it, aren't you?
Amazing how a little bit of attitude can quickly get a bug ignored. How about this for an answer... NPTL is only supported on architectures where the 2.6 headers are default. Currently, this is amd64 only. If you have a problem bootstrapping with NPTL on an unsupported platform... well... it is unsupported, so you're on your own. Good day, sir.
Well, this is a quite interesting statement. "we do not support NPTL on x86" I can live with that, it's not that i'm unabled to do the two steps (emerging linux26-headers, unmerging linux-headers) manually. This is about improving Gentoo, and not about making my personal life easier. Either write a more clever bootstrap-routine, or don't - but be sure that many will not understand why you decided against adding a few lines to bootstrap.sh.
#1. Read comment #13 and you'll see that I don't maintain the script. #2. It will be supported with 2005.0 with no changes, so why bother? #3. We never have supported nptl on x86, like many other experimental parts of Gentoo, there are many times things in place specifically to STOP someone from easily installing something which they do not understand. What this does is it forces a manual process to get certain things, which are unsupported, installed. This raises the barrier of entry for using the experimental interface and keeps users from inadvertantly breaking their systems. Users who know what they are doing can easily bypass the process, and can install their system how they want. This is essentially the same as adding a package to package.mask or setting KEYWORDS="-*" to keep users from using something that might be quite broken or in heavy development. #4. Coming across with an attitude and calling others lazy because they don't see things the same way as you is a very narrow-minded approach to software development and is not the way that Gentoo functions.
his point was to drop the stupid attitude, it only serves to piss off devs and make us ignore you i'm probably going to be the one to fix this, but now i'm inclined to just ignore this bug and go help users who dont tell me i'm lazy
I don't call you guys lazy! :) And this bug affects infrastructure in some aspects so I'd say that the simple fix would be helpful. Else I'll just have to remember and unmerge linux-headers. Feel free to fix it if you'd like, but he's not the only person requesting this fix. Cheers!
Well, i know you aren't lazy, did i call you lazy? I just said - in pretty angry way - that i don't understand why you whine that much again. IMHO, a stage tarball that comes with linux26-headers is as bad as a tarball that comes with linux-headers tarball. Paranoid people may want to install kernel 2.4, other people want kernel 2.6 (with out without NPTL). If the 2005.0 tarball will come with linux26-headers installed, you may find users that ask you how to get rid of the linux26-headers etc. Well, bootstrap.sh should be abled to install prepare a system for kernel 2.4 and kernel 2.6 - well IMHO. That bootstrap.sh forces kernel 2.6 when USE=nptl is enabled is very correct, and should stay that way.
you did say exactly that actually in comment #15 '... but it seems that you're to lazy to program it, aren't you? ...'
Created attachment 45749 [details, diff] bootstrap.sh.patch someone test this
Created attachment 45750 [details, diff] bootstrap.sh.patch test this one actually
well i'm glad that everyone who complained so loudly found time to test out the proposed fix merged the patch as attached here into cvs after having a friend of mine test it for me
