Installing Gentoo 2004.3: Stage 1 NPTL on a Stage 3 Tarball

[thecookie]

that sequence of commands isn't part of the tutorial, so i really don't understand why you would choose to intersperse it with the commands that are in the tutorial. if you make changes to the tutorial, you should expect that the ultimate outcome may be different than if you had not.

I am sorry for the confusion. I copy/pasted the wrong line, I was watching some other guide at the same time.

The question was if I was getting the right linux26-headers. portage was emergeing linux26-headers-2.6.8.1-r2 - are those the right ones?

I have another question/problem now. The first time I tried installing from this guide I used the aggresive CFLAGS. It resulted in gcc not being able to create executables after finishing compiling glibc - when trying to compile binutils. I re-did everything, following each step from the guide and using the same make.conf, but with the conservative CFLAGS. After a few hours compiling I get the same result

Code: Select all

creating cache ./config.cache
checking host system type... i586-pc-linux-gnu
checking target system type... i586-pc-linux-gnu
checking build system type... i586-pc-linux-gnu
checking for a BSD compatible install... /bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler (gcc -O2 -march=pentium -mtune=pentium -pipe ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.

!!! ERROR: sys-devel/binutils-2.15.92.0.2-r2 failed.
!!! Function toolchain-binutils_src_compile, Line 106, Exitcode 1
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

Any idea what the problem might be?

[kimchi_sg]

Code: Select all

creating cache ./config.cache
checking host system type... i586-pc-linux-gnu
checking target system type... i586-pc-linux-gnu
checking build system type... i586-pc-linux-gnu
checking for a BSD compatible install... /bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler (gcc -O2 -march=pentium -mtune=pentium -pipe ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.

I believe that you are not using a real classic pentium system to do your emerge, no?

If you are using anything newer than a classic pentium (the one right after the 80486 in the processor lineage), then change your CHOST to i686-pc-linux-gnu and the -march and -mcpu options in your CFLAGS to match the true values for your processor. A wrong processor type in CFLAGS will cause emerge to b0rk like this.

FYI, read the comments about the CFLAGS in /etc/make.conf.example carefully to see what the acceptable processor type values are.

[Bob P]

Documentation, Tips & Tricks
Unofficial documentation for various parts of Gentoo Linux. Note: This is not a support forum.
Moderator: Global Moderators

I'm going to step up onto the soapbox for a moment:

The Documentation, Tips & Tricks Forum really is not a support forum, so I'd prefer if we could limit the context of this thread to posts that discuss problems with the tutorial that need to be corrected, or ideas about how to improve the Stage 1 on 3 installation procedure iteself.

At this time the tutorial has evolved to a fairly mature state, such that most problems that are likely to be encountered during an install are likely to be related to individual factors not attributable to the tutorial. It would seem fair if those who encountered problems with architecture specification, CFLAGS, etc. could post their requests for help in the appropriate support forums. (That way, once your personal support request is resolved, your problem will scroll off into oblivion instead of being preserved here forever, interspersed with this documentation.)

I hope that I'm not over-stepping my bounds by trying to moderate this thread, but I am trying to keep it from bloating into another 21-page encyclopedia of randomosity by interspersing support requests with posts that are related to improving the tutorial.

Please post all support requests in the appropriate support forums. It will make life alot easier on everyone.

Thanks!

[Bob P]

Bob I ran in to a portage upgrade prob yesterday. I went up to linx26-headers-2.6.8.1-r2. In and of its self this is not necessarily a reason to rebuild your tool chain or do

Code: Select all

emerge linux26-headers glibc && emerge glibc binutils gcc && emerge binutils gcc && emerge world -e 

i was looking at the difference between the -r1 and -r2 versions of the current linux26-headers. it seems that there is no significant difference between them, and an upgrade without rebuilding the toolchain in this case would seem safe.

[certocivitas]

Well I just finished an install using Bob P's method and everything is working great. I'm using an old athlon-xp 2200, here are the compile flags I used:

Code: Select all

CFLAGS="-O2 -march=athlon-xp -mfpmath=sse -msse -mmmx -m3dnow -pipe"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1"

These are not the most optimized possible I'm sure but after lots of trial and error they are stable (at least for me, YMMV).

I did an install from a working Gentoo system. Using mm-sources, reiser4 worked well (read: it has not crashed and burned yet ).

One note for nvidia-driver users, You can not compile the driver with mm-sources greater than 2.6.10-r2. You will just get this error if you try:
* EDIT 2.6.10-r2 does not work either use 2.6.10-r1

* Your current kernel uses EXPORT_SYMBOL_GPL() on some methods required by nvidia-kernel.
* This probably means you are using 2.6.10_rc1-mm*. Please change away from mm-sources until this is
* revised and a solution released into the mm branch, development-sources will work.

Also the /etc/conf.d/rc configuration has changed a little. For a UDEV only system set things like this:

Code: Select all

RC_DEVICE_TARBALL="no"
RC_DEVFSD_STARTUP="no"

Happy hacking.

[Nairou]

Out of curiosity... This tutorial claims to be "bulletproof", and indeed is a very enticing choice for my next fresh install. But from what I can tell reading over the pages of posts - and I may very well be wrong - this is essentially a "~x86" setup, leaving "x86" behind for the most part. Is this correct? If so, wouldn't that potentially create stability problems, making it less than "bulletproof"? I've always stuck with "x86" thus far, but my need for GCC 3.4.3 is making me look into alternatives such as this, and I'm wondering if it's going to bite back at some point.

[Bob P]

Out of curiosity... This tutorial claims to be "bulletproof", and indeed is a very enticing choice for my next fresh install. But from what I can tell reading over the pages of posts - and I may very well be wrong - this is essentially a "~x86" setup, leaving "x86" behind for the most part. Is this correct? If so, wouldn't that potentially create stability problems, making it less than "bulletproof"? I've always stuck with "x86" thus far, but my need for GCC 3.4.3 is making me look into alternatives such as this, and I'm wondering if it's going to bite back at some point.

i thought that the post on Page 1 where i quoted robmoss, and the quote at the top of Page 2 about nptlonly spelled this out pretty clearly, but i'll give it another shot just in case i wasn't clear.

in the context of this tutorial, bulletproof has nothing at all to do with your selection of whether or not to participate in testing branch. rather, it is about how you build your system toolkit so that it will work properly, effectively, efficiently and reliably in building your world files.

"arch" vs. "~arch" really doesn't have anything to do with the stability of your toolkit. the ebuilds that we use to build this system toolkit are proven, stable, and reliable. they provide the absolute bleeding edge in performance while keeping stability the primary concern. once you have your system built, you have the choice of whether or not to use stable "arch" packages or experimental "~arch" ebuilds to populate your world.

ultimately, if you should decide to stay in the testing branch then the results that you will encounter with ebuilds will have nothing to do with your decision to follow this tutorial -- it will depend entirely upon the ebuilds themselves. "~arch" is for testing experimental ebuilds. if you're not inclined to do that, and you want packages that we know are stable, use "arch". but your decision of which branch to follow after you've installed your system is a decision that should be made independently of your decision to follow this tutorial.

if the prospect of using "~arch" when building your base system scares you, then this installation method is not for you.

[certocivitas]

Using ~x86 is not really needed in make.conf to do this install. Adding the packages in the toolchain that require a keyword masked version to /etc/portage/package.keywords will do just fine. After Installing this is all that was in package.kewords:

=sys-libs/libstdc++-v3.3.3-r1 ~x86
=sys-devel/gcc-3.4.3-r1 ~x86

And everything else was installed with package versions of the more stable x86 type. Well except mm-sources, madwifi and nvidia packages but that was because I deviated from the standard install abit.

[Guinpen]

Hello,

I've been following your guide, and on the 258th minute of emerge -e system I get (reproducing by memory):

ERROR: media-libs/svga-lib-1.9.19-r1 failed
Function kernel-mod_configoption_builtin, Line 114, Exitcode 1
Kernel has not been configured yet
If you need support, post the topmost.... (btw tthere is nothing useful, on top of that, it's the download stuff for svga-lib)

So, emerge --resume displays that again and stops, and an emerge -s system, from what I understand, would start ALL OVER AGAIN. If I emerge a kernel source package and configure my kernel, then I suppose emerge --resume will no longer know what I mean, and I'd gave to start again.... in any case, what should I do?

I use the opportunity to thank you for the wonderful guide, and to point out a possible bug - for the very first toolchain compile, which is still with, say, GCC 3.3.4, you're using the -mtune=pentium option which I understand is new to GCC 3.4.3! It did break the binutils configuration on my Centrino (pentium-m) laptop, and removing that fixed the problem.

EDIT: I found out that the way to fix this is to install (and properly point) to the kernel sources. I could do that with emerge whatever-sources, and then I'd create the proper symlink in /usr/src. However, I am afraid that this last emerge would destroy the previous resume information and I would not be able to resume. How can I preserve the resume information?

[Bob P]

There are CPU specific problems with older versions of GCC and Pentium-M processor-specifc CFLAGS that are a matter of record if your search the forums. You might have been caught by that bug. I'm not sure, but I think that with GCC 3.3.4, the preferred architecture for a Pentium-M is pentium3, but you'd better verify that instead of taking my word on it. IIRC Pentium-M is a 3.4.3 CFLAG. maybe somebody else can correct me in on this.

-mtune is indeed a GCC 3.4.3 CFLAG that has been deprecated by the GCC 3.3.4 -mcpu CFLAG. insofar as we are using the GCC 3.3.4 that came with the Stage 3 tarball to perform our first set of compiles in section 7.1, you should eliminate the -mtune flag from your make.conf or replace it with -mcpu. then, when you get to section 7.2.1, you should get rid of -mcpu. you can add-back the -mtune CFLAG if you want to use it, but its not really necessary unless you are compiling on one architecture and optimizing to run on another, as -mtune is implied when you set -march. Sorry if this was not clear.

EDIT: second paragraph

[ronin69hof]

binutils failed with it complaining that the c compiler couldnt create executables so i removed the -mtune=pentium from the CFLAGS line in make.conf and re-emerged binutils and it worked like a charm.

[Fanatic]

Worked fine here aswell, it's stable but it doesn't feel much more 'optimised' than it did with gcc 3.3 But apps do seem to compile faster than in gcc 3.3.

Code: Select all

CFLAGS="-O2 -mtune=athlon-xp -march=athlon-xp -fomit-frame-pointer -fforce-addr -momit-leaf-frame-pointer -frename-registers -fweb -ftracer -pipe"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

[kimchi_sg]

If you have a question about how to recover from an installation error, please pursue help in the support forums.

I think the onus is solely on you to make a topic in the Installation Gentoo forums (or another forum you would deem appropriate for this), expressly for testers of your installation method to voice their requests for help.

The reason for this is that there are people who install their systems using tutorials from Documentation, Tips and Tricks (like this one) to install their systems, and then run into trouble with their install, then do as you have suggested here - post their questions to Installing Gentoo.

But the people who frequently answer posts in Installing Gentoo may have no idea which exact D, T & C tutorial the person in trouble followed, especially since the relevant link is often the last thing they bother to include in their help request.

Therefore, creating a topic in a relevant support forum just for support questions related to the installation method you're proposing, complete with a link to this installation tutorial, would be a great help.

[Bob P]

You've made a good point about the support thread. People who run into problems following this guide will need some form of support. I've been spending alot of time in the Installing Gentoo forum looking for people who've needed help, and I've found every thread that's related to this guide. I'm not sure that its necessary to lump everybody's problems into the same category, though, as this will just create a rather chaotic thread. What is essential is to be available to help out, and I've been bending over backwards trying to do that. I'd appreciate it if those people who are credited for helping with the basis for thiis tutorial and are familiar with its techniques could also lend a hand.

One potential problem has cropped up, being reported by a handful of forum n00bs in the last 24 hours: a fair number of them have had trouble with emerge linux26-headers-2.6.8.1-r2 stopping with a critical error. Unfortunately, this problem has not been at all reproducible -- every user seems to have gotten through the emerge on a subsequent attempt, which makes me wonder if a configuration error may have been involved. FWIW, i have repeated the installation method on my two testbed PCs and i have not been able to reproduce unsatisfactory results.

[kimchi_sg]

One potential problem has cropped up, being reported by a handful of forum n00bs in the last 24 hours: a fair number of them have had trouble with emerge linux26-headers-2.6.8.1-r2 stopping with a critical error. Unfortunately, this problem has not been at all reproducible -- every user seems to have gotten through the emerge on a subsequent attempt, which makes me wonder if a configuration error may have been involved. FWIW, i have repeated the installation method on my two testbed PCs and i have not been able to reproduce unsatisfactory results.[/b]

I have gotten this very same error. It seems to have been introduced by the changes in linux26-headers about yesterday. Cloudburst on #gentoo had the same error as me and we happened to bump into each other last night (GMT +8hrs), so I know this is not a problem specific to your method. He got the same error emerging linux26-headers in a stage 1 install, with ACCEPT_KEYWORDS="x86". And I got him to file a bug report.

From what he reported, linux26-headers was changed in the last 24 hours or so, and the changelog lists the change as "improved cross-compiling support". Unfortunately, the new version (which still has the same version number) generates a lot of "please upgrade to your package to use linux-info.eclass" errors, during the applying patches stage. Then when the first HOSTCC script is run (<somedir>/fixdep.c), the script will immediately abort, complaining that some include file is not found.

Sorry i can't be more specific about the symptoms, as i have "solved" this by masking the latest version of linux26-headers. But i can reassure you that it is not a configuration problem. Who knows, it may even be bugfixed by now.

[Bob P]

AARGH!

i hate it when this happens. look here:
http://www.gentoo.org/cgi-bin/viewcvs.c ... -r2.ebuild

it seems that linux26-headers-2.6.8.1-r1 v1.1 was 5 days old and b0rked. about 22 hours ago, vapier published 2.6.8.1-r2 v 1.2 (a different version of the software with the same ebuild number) which appears to have fixed the problem. that's why i couldn't reproduce the problem this morning.

the good news is that the problem was in the ebuild, not in the tut.

[ronin69hof]

great, after an "emerge --sync" the 2.6.8.1-r2 headers finally worked. thanks for the great tutorial, its much appreciated.

[tonich]

problem with linux26-headers-2.6.8.1-r2 fixed here

http://www.gentoo.org/cgi-bin/viewcvs.c ... ncs.eclass

[mtamizi]

Bob P: Thanks for this tutorial. It was very useful.

About the CFLAGS. Most people are using those extra flags without realizing it, ie, some of the flags you listed are redundent. According to GCC optimization website, -O3 already includes a lot of those options -- like -fomit-frame-pointer.

[Bob P]

Bob P: Thanks for this tutorial. It was very useful.

About the CFLAGS. Most people are using those extra flags without realizing it, ie, some of the flags you listed are redundent. According to GCC optimization website, -O3 already includes a lot of those options -- like -fomit-frame-pointer.

indeed, you are right. whenever you turn on any level of optimization using -Ox, -fomit-frame-pointer is enabled. you will get -fomit-frame-pointer at -O1, for example.

similarly, when you turn on level -O3, -frename-registers and -fweb are enabled. i'll fix that. thanks.

[Hobbit_HK]

IIRC, -fomit-frame-pointers is enabled automatically in -Ox if it doesn't interfere with debugging, not the case in x86

[Bob P]

IIRC, -fomit-frame-pointers is enabled automatically in -Ox if it doesn't interfere with debugging, not the case in x86

Hobbit! I narrowly beat you to the punch! Because this tut uses the Intel Pentium example, I've left that flag in.

UPDATE NOTE: As a result of the recent troubles with defective linux26-headers appearing in the testing branch, I've decided to change the default branch for this installation method to the stable branch. Hopefully, staying out of the testing branch will improve reliability for those who are less experienced in troubleshooting ebuilds. More experienced users are free to change this option to suit their needs.

[Hobbit_HK]

LOL...
Good idea on changing to the stable branch btw.. although I'm staying at ~x86
I just hope I won't hose my install wuth all those guides-merging

[Bob P]

Well, I am sticking to ~x86 on my desktop, but I've decided to use the stable branch for my router. I don't think that merging and revising the guide is going to hurt us. To test the latest revisions to the guide, I started a new install on the old boatanchor last night. It should be done in a few days...

[hielvc]

Ever heard of distcc there Bob