Stage 1/3 Installation Support - Gentoo 2004.3 & GCC 343

[Bob P]

This thread should be used to ask support questions about the Stage 1 NPTL on a 2004.3 Stage 3 Tarball installation method. Please post your support requests here and not in the Documentation, Tips & Tricks forum.

When following the Guide, please bear in mind that it is an advanced installation method, and it requires the user to make subtle, yet important changes in some of the steps that will significantly change the behavior of your GCC compiler. For this reason, it is imperative that you resist the temptation to "improve" your installation by making changes to the compiler settings in make.conf at any time other than when they are recommended.

Rebuilding the GCC compiler and your toolkit folowing a major GCC version upgrade can be tricky business. The perils of doing this improperly have been well documented in the GCC 3.4.3 is Upon Us thread.

The vast majority of support problems to date have been encountered by experienced linux users who are new to Gentoo. These users invariably choose to deviate from the guide in an effort to "improve" their installation by adding/changing compiler settings or removing some of the redundant compilation steps.

If you are not an advanced Gentoo user who is familiar with rebuilding the toolkit and you're not absolutely certain what you are doing, then try to resist the temptation to make changes to the Guide's installation method. Many people have fubar'd their installations by adding bits and pieces from other installation methods, or by streamlining the installation method by skipping steps. DON'T DO IT! You'll be much more successful if you choose one installation method and follow it dogmatically.

When posting, please remember that the Stage 1/3 guide is not officially supported, but if you need help, this is the best place to ask for support. Please bear in mind that if you have deviated from the installation guide in any way, support may not be available and your best option may be to start over.

As of the time that I open this thread, I will no longer repond to any Personal Messages requesting support for the Stage 1 on 3 Installation Guide. All Personal Messages sent to me will be deleted without a reply, so please post your support requests here. Thanks, and have fun!

Here are some of the more common problems that people have encountered, and hyperlinks to the solutions:

C Compiler Cannot Create Executables: http://forums.gentoo.org/viewtopic-t-294109.html

Glibc Will Not Compile: http://forums.gentoo.org/viewtopic-t-31 ... rt-42.html

Failure on First Boot: http://forums.gentoo.org/viewtopic-t-29 ... rt-31.html

Gensplash and Bootsplash Problems: http://forums.gentoo.org/viewtopic-t-29 ... rt-19.html

Genkernel - Unsupported: http://forums.gentoo.org/viewtopic-t-29 ... t-176.html

Reiser 4 - Unsupported: http://forums.gentoo.org/viewtopic-t-29 ... rt-51.html

[dedeaux]

binutils borks telling me compiler can't created executables....

gcc-config won't switch to gcc-3.4.3

here is where I am at:
gcc-config -l states that I am configured for gcc-3.3.4

gcc-cinfig 2 tells me I am switching to gcc-3.4.3 and to source /etc/profile

source /etc/profile

gcc-config -l states I am back at gcc-3.3.4

[kimchi_sg]

binutils borks telling me compiler can't created executables....

Please post the last 10 lines of the output here. But do not post the lines that begin with !!!!.

[dedeaux]

don't feel like retyping all that thought I had described it well enough:

host, target, build system type all i686-pc-linux-gnu
ln and ln -s work
gcc

then:
checking whether C compiler (gcc -march=pentium4 -mtune=pentium4 -pipe -O2 ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.

[kimchi_sg]

Quick fix: Take -mtune out of your CFLAGS.

I do not understand why gcc-config is refusing to change the compiler profile though.

[dedeaux]

that defeats the whole purpose here... why rebuild the binutils with gcc-3.3.4...

[Bob P]

don't feel like retyping all that

its too bad that you don't feel like typing the screen output of the critical error. there's no way that anyone can help you if you don't do that. i really find it amazing that you could expect someone to be able to help you when you're too lazy to accurately define the nature of the problem.

in addition to kimchi's suggestion that you include the last 10 lines of screen output from your critical error, when asking for help on a topic related to compiler failure, its always necessary to post the output of "emerge info".

in general, when posting "emerge info", it would also be very helpful if you could tell us the exact section of the guide where you're having problems. for example, if you're having problems at Section 7.1, it would be tremendously helpful to tell us what Section of the Guide you're working in, which section of the guide your "emerge info" represents, and what type of critical error you've encountered.

In your case, mtune does NOT belong in your cflags in section 7.1, but its okat to use it in section 7.2, after you have swtiched compilers.

[kimchi_sg]

-mtune is actually redundant when you have -march.

-march will optimise code without considering backward compatibility with older processors, while -mtune will try to be backwards compatible. From your error output, it seems that gcc is still being passed the -march option, so your compiled code will still be optimised. In short, you will lose nothing by removing -mtune here.

[dedeaux]

I am lost.

My point here is that I should be using the new GCC 3.4.3. The output from gcc-config -l and gcc --version tell me that it is still using gcc-3.3.4 which was already used to compile binutils. I am saying that step 7.2.4 is rebuilding the toolchain with 3.4.3 -- since I can't do this, then why go on... obviously there is a problem somewhere.....

[kimchi_sg]

Did you do env-update after running gcc-config 2?

[dedeaux]

for starters:

Bob P:
I made a post before seeing the support thread:
http://forums.gentoo.org/viewtopic-t-299706.html

All the details were given in that post. As for indicating the critical errors -- I did this... instead of helping me you began to flame me... I was not being critical of you in any way. I appreciate your work in the guide or I wouldn't even be here.

kimchi_sg:
thanks for the help... yes, I was following the guide step by step and had accomplished 7.2.3 which indicates an env-update.

I think I will rewind and start all over... I do have a question tho:

I am using the 2004.3 boot cd. In step 6.5 when I go to make my changes to /etc/make.conf I should change the CHOST or not? It comes up with i386-pc-linux-gnu. I am on a P4 M laptop.

Thanks.

[qbad]

Hi everyone!
Here's what I got after trying to emerge glibc-2.3.4 (using 3.3.4 toolkit):

Code: Select all

..../csu/crtn.o
collect2: ld terminated with signal 11 [Segmentation Fault]
make[2]: *** [/var/tmp/portage/glibc-2.3.4.20050125/work/build-default-1686-pc-linux-gnu-linuxthreads/elf/sln] Error 1
...
!!! ERROR: sys-libs/glibc-2.3.4.20050125 failed
!!! Function toolchain-glibc_src_compile, Line 187, Exitcode 2
!!! (no error message)

I'm currently trying to do stage 1 NPTL on a 2004.3 stage 3 tarball install, but got the same error while doing just a simple stage 1 bootstrap.

No freaky USE flags, everything as it is in the tutorial.
Athlon XP, Reiser4

Any hints?
Thanks for every helpful reply!

[Bob P]

I am lost.

My point here is that I should be using the new GCC 3.4.3. The output from gcc-config -l and gcc --version tell me that it is still using gcc-3.3.4 which was already used to compile binutils. I am saying that step 7.2.4 is rebuilding the toolchain with 3.4.3 -- since I can't do this, then why go on... obviously there is a problem somewhere.....

you're right -- do not proceed beyond Section 7.1 until the problem is solved.

i understand the frustration that you feel when you are lost. unfortunately, i feel just as lost when trying to help you, as you have not defined the probem well enough for me do anything more than guess about your problem. without having an accurate snapshot of what your system looks like, my only recourse it to take shots in the dark. as a courtesy to the people who are trying to help you, please take the time to post the information that we need so that we can make intelligent recommendations instead of making random shots in the dark.

i'm assuming that you have not used the Gentoo Forums' search feature, and that you have missed a thread that from today that is just a few lines down that discusses an identical problem: http://forums.gentoo.org/viewtopic-t-298309.html

in this case, the user inappropriately put the "-mtune" command option in make.conf while working with GCC 3.3.4 in Section 7.1 of the Guide, in spite of the fact that the user is NOT instructed to do, and in spite of the fact that GCC 3.3.4 does not support it. "-mtune" is a compiler command that was introduced in GCC 3.4.3, and should not be used prior to Section 7.2.1 of the Guide.

to verify this, look for "-mtune in the GCC 3.3.4 Manual for X86 and you'll see that it is conspicously absent. In contrast, it is present in the GCC 3.4.3 Manual for x86.

in spite of the fact that the guide does not recommend using the "-mtune" compiler flag during Step 7.1, a surprisingly large number of users have been deviated from the guide by adding this command to make.conf while they are operating under the GCC 3.3.4 compiler. because you have not posted the output of "emerge info", it is not possible for me to know whether you are effected by this problem or not. taking a shot in the dark, i'd guess that you may be effected.

NOTE to ALL READERS: do not use "-mtune" prior to switching to the GCC 3.4.3 compiler in Section 7.2.1 of the Guide.

I apologize if I came off as flaming you. I began my reply to your post immediately after your post in which you refused to provide the requested information. In the time that I was writing my post, you decided to provide the information in a subsequent post. In that context, I have to agree, it looks like I was a jerk.

BTW, I'm still waiting to see the contents of your "emerge info".

[Enlight]

GPM is on the live-cd, no??? So he can copy-paste in links using the middle clic...

[Bob P]

Here's what I got after trying to emerge glibc-2.3.4 (using 3.3.4 toolkit):

Code: Select all

..../csu/crtn.o
collect2: ld terminated with signal 11 [Segmentation Fault]
make[2]: *** [/var/tmp/portage/glibc-2.3.4.20050125/work/build-default-1686-pc-linux-gnu-linuxthreads/elf/sln] Error 1
...
!!! ERROR: sys-libs/glibc-2.3.4.20050125 failed
!!! Function toolchain-glibc_src_compile, Line 187, Exitcode 2
!!! (no error message)

I'm currently trying to do stage 1 NPTL on a 2004.3 stage 3 tarball install, but got the same error while doing just a simple stage 1 bootstrap.

No freaky USE flags, everything as it is in the tutorial.
Athlon XP, Reiser4

Any hints?

Yes. Don't use Reiser4 with this installation method. Although it is possible to perform a Stage 1/3 installation with Reiser4, quite a few deviations from the guide are necessary and the installation is subject to many potential pitfalls. My recommendation would be to drop Reiser 4. You can't do it with this Guide as it is written, and this Guide doesn't support it.

If you can't live without Reiser 4, you might want to send a PM to DrWoland. IIRC he developed a method of using Reiser 4 with this Guide and ran into many, many problems. He was thinking about writing a new guide to support Stage 1/3 with Reiser 4. That would be a good topic for another thread.

Good Luck.

Another common cause of compiler segfaults is overlocking. Don't do it.

[Enlight]

Another common cause of compiler segfaults is overlocking. Don't do it.

I'would just say not to do it but test with memtest AND mprime (15H each at least)

[Bob P]

GPM is on the live-cd, no??? So he can copy-paste in links using the middle clic...

yes, that is a good idea. its a common problem that most new users don't know how to move text output from a machine that's running the LiveCD to the machine that they're using to post to the web. i typically recommend porting the data to a floppy, and then moving the floppy to the other machine.

[Bob P]

HOW-TO Post the Contents of Emerge Info:

In order to assist in troubleshooting, its almost always necessary to review the output from your machine's "emerge info". This command produces enough output that it is too cumbersome to retype it, and in most circumstances people that are working from the Live CD don't know how to move data from one PC to another.

This can be done very easily by redirecting your screen output to a text file on a floppy disc, and then moving the floppy to the PC that you use to surf the web:

Code: Select all

# mount -t msdos /dev/fd0 /mnt/floppy
# emerge info >> /mnt/floppy/emerge.nfo
# cat /etc/portage/package.keywords >> /mnt/floppy/package.key 
# umount /mnt/floppy

the first line in this example shows you how to mount a dos floppy disc.
the second line demonstrates how to redirect the screen output of a command, piping it to a file on the floppy disc.
the third line demonstrates how to redirect the screen output of a file to the floppy. you could have just as easily used a command like:

Code: Select all

# cp /etc/portage/package.keywords /mnt/floppy/package.key

the fourth line in the example demonstrates how to unmount the floppy. don't forget to do that before you remove the disc!

[96140]

I hate to say this, Bob, as I've been a very vocal supporter of your method, but....well, by the time I finished (3-4 days of work), I did not have a working Gentoo installation. This may or may not be related to the fact that on the first emerge -e system I quit 1/3 of the way through to add more USE flags to make.conf, as I mentioned awhile ago in the official thread. Though I rebuilt my toolchain just fine after that, when I restarted my computer, I got the nice Grub splash screen, but no bootsplash.

That was the least of my worries...shortly after this, after watching the normal mesages flash past, I hit the big error: hda3 (where everything but /boot is, as per the Guide) wasn't found. I found this ironic, because the previous boot lines talked about mounting it, reading files from it, etc. Heck, I'm pretty sure the system has to pull files from it. I think this might be a ReiserFS problem; I've noticed that with any Linux distribution I put on my computer, I have much more grief when using ReiserFS. That's why, for my first installation, I ended up using the slower ext3 FS; I will be retrying in the next couple of days using ext3--I only hope that I don't lose much of the speed that this method is supposed to bring.

I'm not sure exactly why bootsplash didn't work; I was very careful to follow the guide verbatum after the first slight mistake I made; I triple-checked everything after that. I only used the 1024x768 splash image, since that's my native resolution, and I saw no errors during the boot process. And yes, I had everything enabled in my kernel that should be there, and I was using vesa-tng, etc. I can't troubleshoot any of this right offhand as, I'm sorry to say, I had to put Window$ XP on the first partition of the drive in order to get a working OS for the short term.

What really bothers me is that ReiserFS couldn't find the very partitions it was booting from; I got a bash prompt asking for a Ctrl-D restart or admin password for maintenance, neither of which worked. A whole day monkeying around in Knoppix, examining each critical config file didn't solve anything, either. THe only thing I can think of that's slightly odd are the directions for Grub to find the kernel; most Grub config tutorials for a 2.6 kernel specify /boot/kernel-2.6.10-gentoo-r6 (or whatever) instead of /vmlinuz (or whatever). But then, my kernel had to be working since it loaded my system to that one point...and it's not like I didn't have FS support compiled into the kernel, which I did.

I'll be trying again tonight or tomorrow night using ext3. Maybe ReiserFS offers better performance, but I can never get it to work for me. I wish I remembered more details about the exact error message, but it's been a few days, so I'd have to have a little prompting, and it's all moot anyways; I have to wipe the rest of the disk and start over.

But, Bob, your method does speed things up by the time the last emerge -e system rolls around; I can feel the increased speed once the toolchain builds itself a couple of times, even before rebooting.

[Bob P]

Gensplash vs. Bootsplash

I'm not sure exactly why bootsplash didn't work; I was very careful to follow the guide verbatum after the first slight mistake I made; I triple-checked everything after that. I only used the 1024x768 splash image, since that's my native resolution, and I saw no errors during the boot process. And yes, I had everything enabled in my kernel that should be there, and I was using vesa-tng, etc.

the bootsplash program is not an application that you are supposed to emerge as a part of the the Stage 1/3 installation method. the Guide references the program named gensplash, which is a completely different program. in case you weren't aware of it, these two programs are not at all compatible -- they block each other if you try to emerge them, and if you emerge the wrong one you will run into problems.

without any submission on your part regarding errors, i am at a total loss to guess why you would have problems with gensplash. once again, i'm left to taking shots in the dark. are you familiar with the difference between bootsplash and gensplash? if you have a problem with gensplash, my recommendation would be to look at the output of dmesg and to look into the Gensplash How-To, or if your're using bootsplash, to take a look at The Gentoo Framebuffer, Bottsplash & Grubsplash How-To or its support thread.

fwiw, the vesafb-tng driver does not work with all varieties of hardware and some video cards just bork with it. troubleshooting the framebuffer devices is really beyond the scope of this thread. they're just a cosmetic add-on to the Stage 1/3 Guide, and they have their own associated problems and their own support threads. with that said, here's another shot in the dark -- remove any other video drivers from your kernel -- they will cause a conflict with vesafb and if they are present the framebuffer will never work.

[Bob P]

That was the least of my worries...shortly after this, after watching the normal mesages flash past, I hit the big error: hda3 (where everything but /boot is, as per the Guide) wasn't found. I found this ironic, because the previous boot lines talked about mounting it, reading files from it, etc. Heck, I'm pretty sure the system has to pull files from it. I think this might be a ReiserFS problem; I've noticed that with any Linux distribution I put on my computer, I have much more grief when using ReiserFS. [emphasis added] That's why, for my first installation, I ended up using the slower ext3 FS; I will be retrying in the next couple of days using ext3--I only hope that I don't lose much of the speed that this method is supposed to bring.

you have the same problems with any Linux distro that you put on your computer? well if that is the case, it seems that the problem is not attributable to the Stage 1/3 Guide. it sounds like you have a hardware compatability problem.

[96140]

Gensplash vs. Bootsplash
the bootsplash program is not an application that you are supposed to emerge as a part of the the Stage 1/3 installation method. the Guide references the program named gensplash, which is a completely different program. in case you weren't aware of it, these two programs are not at all compatible -- they block each other if you try to emerge them, and if you emerge the wrong one you will run into problems.

fwiw, the vesafb-tng driver does not work with all varieties of hardware and some video cards just bork with it. troubleshooting the framebuffer devices is really beyond the scope of this thread. they're just a cosmetic add-on to the Stage 1/3 Guide, and they have their own associated problems and their own support threads. with that said, here's another shot in the dark -- remove any other video drivers from your kernel -- they will cause a conflict with vesafb and if they are present the framebuffer will never work.

I'm sorry; you're right. I carelessly used them as synonyms. I meant the nice image that's supposed to wrap around the scrolling text at system boot; I thought that was the bootsplash; I guess that's gensplash. I didn't emerge anything extra; I followed the procedures described in the guide, but I only used the 1024x768 image, so I left out the irrelevant bits of splash_geninitramfs and grub.conf (wrong resolutions). So while I had a nice image for the initial kernel selection screen, nothing appeared after that, although my screen did at least default to 1024x768, as I'd specified at some point. I was just mistaken about the labels for which image. ^_^

I've never had any trouble with vesa-tng in the past; I used it for my first install to get the default background for the grub boot screen (to select the kernel), so I don't think the problem is there.

[96140]

you have the same problems with any Linux distro that you put on your computer? well if that is the case, it seems that the problem is not attributable to the Stage 1/3 Guide. it sounds like you have a hardware compatability problem.

Yeah; I believe it was why I could never get a working desktop in Ubuntu; there were several messages about various files/devices not being found (beyond the usual errors that can be expected from X.org). I dunno what it is about this hard drive; I've never had any problems with it; it's sound and decently speedy (for a laptop drive), and has no problem with any of the hdparm settings I throw at it (I looked up its detailed specs at the manufacturer's site). But at some point information got lost, I expect--and I know it wasn't in grub.conf or fstab. I remember firing up links2 and storing my last dmesg somewhere online; I just can't quite remember where, otherwise I could be more specific. Apologies!. Give me another day to get started on a reinstall. I know the LiveCD is good, and all the md5 checks are good, so the problem is not in the files, I don't think. My hard drive works perfectly with any filesystem other than ReiserFS (and that might work out well too, if only I can convince Gentoo that the partition it just mounted the system from actually does exist). Hey, troubleshooting...that's a learning experience, no?

[dedeaux]

Bob_P and Kimchi_sq:

I scrapped the guide from the point I was at and started over. Instead of using the stage3 listed in the guide I went ahead and downloaded the stage3 for i686 instead of x86 and all is fine. When I got to the steps where I was having the issue with gcc-config, the issue no longer existed. The install is moving along fine now. If I have any other problems I will post here. I just started the system rebuild ( 2nd part of step 7.2.4 ) about 40 minutes ago and its about 1/3 of the way through re-emerging the packages.

[Bob P]

Bob_P and Kimchi_sq:

I scrapped the guide from the point I was at and started over. Instead of using the stage3 listed in the guide I went ahead and downloaded the stage3 for i686 instead of x86 and all is fine. When I got to the steps where I was having the issue with gcc-config, the issue no longer existed. The install is moving along fine now. If I have any other problems I will post here. I just started the system rebuild ( 2nd part of step 7.2.4 ) about 40 minutes ago and its about 1/3 of the way through re-emerging the packages.

this is important, so it gets colorized type:

well, getting the right tarball is important, but you should be able to get by using the specified tarball in the guide, regardless of whether or not you had a later x86 processor. they key is that you have to use the flags mentioned in the sample make.conf and not change them until you are told to do so.

the guide was actually designed with a generic pentium-class tarball and a generic set of pentium-class compiler options and cflags intentionally -- it was done as a failsafe method to prevent people from borking their systems.

to get caught by the problem that you encountered, i think that you would have to make two errors at the same time -- you would have to download the wrong tarball for your architecture, and you would have to prematurely issue architecture-specific cflags for a later processor that were not recognizable by the x86 tarball's compiler. THAT is exactly why the x86 tarball is used in the example, along with generic x86 cflags for intel pentium -- no matter what class of Pentium machine you are using, the tarball and the flags are compatible with your CPU and the Guide will work if you follow it. OTOH, if you start to issue flags and commands that require a later processor, you must supply the correct processor-specific tarball or you will bork your system. (just for reference: i haven't actually tried to make that mistake (!), but i think that is how it would work!)

i think that the guide makes it pretty clear that you should NOT edit cflags or compiler settings in section 7.1. if you had followed the guide (and not made those architecture specific changes before being told to do so in section 7.2.1) then you should not have had this problem. maybe the guide isn't sufficiently clear on that point.

the next time that you have a problem like that, be sure to post the contents of emerge info - it will tell us thing we need to know about your system - like your processor and your flag settings. by supplying that information it would have been easier to diagnose your problem a long time ago.