Stage 1/3 Installation with GCC 343 on 2005.0-rc5 = [CLOSED]
Message
Stage 1/3 Installation with GCC 343 on 2005.0-rc5 = [CLOSED]
I'm starting this tread as a place to move the discussions about problems performing Stage 1/3 installations with the 2005.0-rc5 Live CD. i'm hoping that we can get the 2005.0 related information out of the 2004.3 Stage 1/3 thread.
Last edited by Bob P on Mon Mar 28, 2005 3:00 am, edited 1 time in total.
I have tried the Stage 1/3 Installation method using the 2005.0-rc5 LiveCD with 20050110 Stage 3 tarballs, and I've encountered problems. Among them:
1. B0rken Screen Blanking. The framebuffer isn't completely blanked, and the graphic image remains onscreen while the text is changed from white to black. Okay, this isn't really a Stage 1/3 problem, its just an annoying problem with the 2005.0 Live CD. It seems to be a problem with the kernel, the framebuffer, vesafb, and some video cards.
2. I have tried performing the Stage 1/3 install using an approach similar to that used in the 2004.3 guide, but I keep running into the infamous problem where libstdc++.so.6 no longer exists. The problem pops-up during "emerge -e system" when compiling programs such as python, sys-apps/util-linux, etc. Instead of trying to troubleshoot the problem, I just wimped-out and reverted to a 2004.3 Live CD and tarball. If anyone else runs into this problem, I'd love to hear the solution.
If you're adventurous and you're eager to try the STage 1/3 Guide with a 2005.0 tarball, you should be able to skip the commands to unmerge linux headers and subsequently re-emerge linux26-headers. the new headers on the Live CD are reportedly 2.6 kernel-compatible.
1. B0rken Screen Blanking. The framebuffer isn't completely blanked, and the graphic image remains onscreen while the text is changed from white to black. Okay, this isn't really a Stage 1/3 problem, its just an annoying problem with the 2005.0 Live CD. It seems to be a problem with the kernel, the framebuffer, vesafb, and some video cards.
2. I have tried performing the Stage 1/3 install using an approach similar to that used in the 2004.3 guide, but I keep running into the infamous problem where libstdc++.so.6 no longer exists. The problem pops-up during "emerge -e system" when compiling programs such as python, sys-apps/util-linux, etc. Instead of trying to troubleshoot the problem, I just wimped-out and reverted to a 2004.3 Live CD and tarball. If anyone else runs into this problem, I'd love to hear the solution.
If you're adventurous and you're eager to try the STage 1/3 Guide with a 2005.0 tarball, you should be able to skip the commands to unmerge linux headers and subsequently re-emerge linux26-headers. the new headers on the Live CD are reportedly 2.6 kernel-compatible.
- dizanjizay
- n00b
- Posts: 7
- Joined: Mon Feb 21, 2005 6:38 pm
- Location: Cleveland, Ohio
In response...
1. I have the same problem with the video blanking (text white to black) doing the install from the 2004.3 LiveCD, so I don't think it is the 2005.0-r5 cd per se. Both machines that this occurs on for me (both Stage1/3 from 2004.3) have RIVA TNT video cards installed. Hope that helps.
2. I'll let you know, I am currently using the the 2005.0-r5 LiveCD to do a Stage 1/3 on an old laptop. I am currently in step 7.1 of the Stage 1/3 guide... and have been for awhile.
1. I have the same problem with the video blanking (text white to black) doing the install from the 2004.3 LiveCD, so I don't think it is the 2005.0-r5 cd per se. Both machines that this occurs on for me (both Stage1/3 from 2004.3) have RIVA TNT video cards installed. Hope that helps.
2. I'll let you know, I am currently using the the 2005.0-r5 LiveCD to do a Stage 1/3 on an old laptop. I am currently in step 7.1 of the Stage 1/3 guide... and have been for awhile.
"Nothing in this world is difficult. Some tasks just take more time than others"
the video blanking problem exists on the 2005.0 live cd and AFAIK not on the 2004.3 live cd. if you are having problems like that AFTER you have rebooted, the problem has been caused by your choice of kernels. the newer GDS kernels all have this error. if you read the links i've posted, you'll find more than enough information. if you want to eliminate hte problem, load an older kernel such as 2.6.9-gentoo-r9.
the problem exists in the kernel on the 2005.0 live cd because it uses the newer kernels that are subject to the bug that has never been fixed. AFAIK is not present in the 2004.3 live CD kernel because the kernel used on that live cd predates the origin of the bug. anyone can make the bug occur on their system, regardless of which cd you install from, by rebooting with an effected kernel. that behavior has nothing to do with the live cd.
if you have this blanking problem after booting from the 2004.3 live cd, then you have an interesting problem. AFAIK none of the bug reports to date have documented this with the older kernel, so you should follow the links and post your observations to bugzilla, with specific references to your drivers and hardware.
the problem exists in the kernel on the 2005.0 live cd because it uses the newer kernels that are subject to the bug that has never been fixed. AFAIK is not present in the 2004.3 live CD kernel because the kernel used on that live cd predates the origin of the bug. anyone can make the bug occur on their system, regardless of which cd you install from, by rebooting with an effected kernel. that behavior has nothing to do with the live cd.
if you have this blanking problem after booting from the 2004.3 live cd, then you have an interesting problem. AFAIK none of the bug reports to date have documented this with the older kernel, so you should follow the links and post your observations to bugzilla, with specific references to your drivers and hardware.
- dizanjizay
- n00b
- Posts: 7
- Joined: Mon Feb 21, 2005 6:38 pm
- Location: Cleveland, Ohio
Thanks for the info, good to know. I guess I'll have to use a different kernel if I want to get rid of it. I am currently using 2.6.11-r4 gentoo-dev-sources.Bob P wrote:the video blanking problem exists on the 2005.0 live cd and AFAIK not on the 2004.3 live cd. if you are having problems like that AFTER you have rebooted, the problem has been caused by your choice of kernels. the newer GDS kernels all have this error. if you read the links i've posted, you'll find more than enough information. if you want to eliminate hte problem, load an older kernel such as 2.6.9-gentoo-r9.
On anther note, I took some advice from the original Stage1/3 forum regarding adding "boundschecking" to the package.use flags before compiling gcc. gcc would not compile using the setting. Unfortunately i didn't write down the exact error, but it had something to do with a 'no such file or directory' error. This was on the first emerge of gcc. I am going to try to re-enable the setting for the second emerge of gcc... I'll let you know what happpens...
This install is on a Dell Inspiron 3000 (2333MMX 4.3GB HD 144MB RAM) so it may be a while till i have results.
"Nothing in this world is difficult. Some tasks just take more time than others"
I was able to build up through X and xfce4 except for gtklib-pixbuf or something close. I used half assed method. Bootstap a stage2 then used tcupdate.sh ,which was moved to the new forum "unsupported software that may bork your system" 
. I had to manualy emerge each docbook then restart each "emerge X blah"6 times to reinstall each docbook again. I just had to mention docbook as one of those recureing pain in the asss 
. If things slow down Im going to try to check out whether the portage pkg descrepency is fixed or not. Oh I thought that video blanking bug was a feature, heack I liked it 
. I had to manualy emerge each docbook then restart each "emerge X blah"6 times to reinstall each docbook again. I just had to mention docbook as one of those recureing pain in the asss . If things slow down Im going to try to check out whether the portage pkg descrepency is fixed or not. Oh I thought that video blanking bug was a feature, heack I liked it hiel, i know that this is off topic, but i figure what's the harm in hijacking my own thread?
i guess i've been stuck in the Stage 1/3 rut, as i've just kept following the guide. i can see that it would be a good option to just do a plain Stage 3 install, enable a testing branch toolkit in the configuration files, and then tun tcupdate.sh. i have a question for you about it though -- in your experience does performing the tc update through the script add much processing overhead?
when i was experimenting with distcc i tried running the tcupdate script to perform a tc update, and i was amazed that the entire process took about 4x longer than normal. i have to admit, i haven't examined the script to determine exactly how you're rebuilding the toolkit, so i'm not sure if that could explain some of the time factor. i just assumed that i had set the value of makeopts="-jn" to too high a value, and that the problem came from overhead with distcc running multiple instances of the compiler on the host box. (none of the compiling assistants were turned on for the toolkit rebuild, so there could have been alot of wasted effort by the compiler).
back to the original subject of the thread, i haven't had an opportunity to spend much time working on the Stage 1/3 install with 2005.0-rc5. i've run into some fatal errors/segfaults with 2005.0 when attempting to build GCC 3.4.3 on my first AMD box, and to remove one factor from the troubleshooting equation, i've reverted back to 2004.3 for that install. interestingly, i've avoided all of the problems that i had with 2005.0 by going back to 2004.3. i think its a bit premature to blame it all on 2005.0 -- after all, this is only one box that we're talking about. but it doesn't look like i'll have the free time to experiment with 2005.0 the way i blazed the trail on 2004.3, so if anyone else can help in trying out Stage 1/3 installs, i'd appreciate it.
i guess i've been stuck in the Stage 1/3 rut, as i've just kept following the guide. i can see that it would be a good option to just do a plain Stage 3 install, enable a testing branch toolkit in the configuration files, and then tun tcupdate.sh. i have a question for you about it though -- in your experience does performing the tc update through the script add much processing overhead?
when i was experimenting with distcc i tried running the tcupdate script to perform a tc update, and i was amazed that the entire process took about 4x longer than normal. i have to admit, i haven't examined the script to determine exactly how you're rebuilding the toolkit, so i'm not sure if that could explain some of the time factor. i just assumed that i had set the value of makeopts="-jn" to too high a value, and that the problem came from overhead with distcc running multiple instances of the compiler on the host box. (none of the compiling assistants were turned on for the toolkit rebuild, so there could have been alot of wasted effort by the compiler).
back to the original subject of the thread, i haven't had an opportunity to spend much time working on the Stage 1/3 install with 2005.0-rc5. i've run into some fatal errors/segfaults with 2005.0 when attempting to build GCC 3.4.3 on my first AMD box, and to remove one factor from the troubleshooting equation, i've reverted back to 2004.3 for that install. interestingly, i've avoided all of the problems that i had with 2005.0 by going back to 2004.3. i think its a bit premature to blame it all on 2005.0 -- after all, this is only one box that we're talking about. but it doesn't look like i'll have the free time to experiment with 2005.0 the way i blazed the trail on 2004.3, so if anyone else can help in trying out Stage 1/3 installs, i'd appreciate it.
Hi Bob P.
I have an amd64 system which was installed using your 1-3 guide and 2004.3. The only problem I had was installing grub which is a known problem. I then upgraded to the 2005 profile using the longhand method as described in the amd64 forum. The script method for some reason would not update as written but that may have been the cut and paste method i used.
The whole system is very stable. Thanks for the time and effort you put into this method especially the time and patience you take to sort out any problems.
I have an amd64 system which was installed using your 1-3 guide and 2004.3. The only problem I had was installing grub which is a known problem. I then upgraded to the 2005 profile using the longhand method as described in the amd64 forum. The script method for some reason would not update as written but that may have been the cut and paste method i used.
The whole system is very stable. Thanks for the time and effort you put into this method especially the time and patience you take to sort out any problems.
Bob there should be very little difference in the emerge TC. Basicly tcupdate.sh runs emerge sys/world -e or -uD and puts it in a file. It then scans the file, grep or sed, and removes the toolchain items and flags that yes or no, the TC has an update. In mine and in MindErasers we feed emerge with a for loop that is the eqvilent of
emerge glibc
emerge glibc
emerge binutils
emerge gcc
emerge binutils
emerge gcc
The above order is what I perfer since we are starting with a good TC and there are cases of haveing to install glibc twice to have a clean install. So I do do it first and then rebuild binutils and gcc against a clean install of glibc. Anyway I cant really prove either as being better or worse, refering to tcupdate and dirtyepic arguments. Also tcupdate.sh emerges portage, gcc-config and binutils-config if there is an update to them.
Back to your question as you can see it really shouldnt make a big time differnece and I havent noticed any. To understand it check out my script as its simpler than tcupdate.sh and closer to what you would run at the command line. I do know that its faster than "emerge system -e && emerge system -e && emerge world -e && emerge world -e"
I use MAKEOPTS="-j5 " on a single proccessor athlon XP2000. Its not for the mulituple threads as much as keeping the cpu fed and not waiting for stuff to load from memory.
LIke my new tag
emerge glibc
emerge glibc
emerge binutils
emerge gcc
emerge binutils
emerge gcc
The above order is what I perfer since we are starting with a good TC and there are cases of haveing to install glibc twice to have a clean install. So I do do it first and then rebuild binutils and gcc against a clean install of glibc. Anyway I cant really prove either as being better or worse, refering to tcupdate and dirtyepic arguments. Also tcupdate.sh emerges portage, gcc-config and binutils-config if there is an update to them.
Back to your question as you can see it really shouldnt make a big time differnece and I havent noticed any. To understand it check out my script as its simpler than tcupdate.sh and closer to what you would run at the command line. I do know that its faster than "emerge system -e && emerge system -e && emerge world -e && emerge world -e"
I use MAKEOPTS="-j5 " on a single proccessor athlon XP2000. Its not for the mulituple threads as much as keeping the cpu fed and not waiting for stuff to load from memory.
LIke my new tag
hiel, this is interesting. i rebuilt a box last night to pick up the latest versions of gcc and glibc. (i've been using the ones that are so famous for breaking people's systems.) i used tcupdate, and it seemed to take an awful long time to compile glibc, but now i understand that the reason for this is that under the tcupdate script, glibc gets built twice before building binutils and gcc.
even though glibc-2.3.4.20050125 and -r1 are supposed to have serious problems, i'm happy to say that i've never run into them. the toolkit rebuild went well, and that my system is now rebuilding world files with the newuse parameter without any problems. i would have sworn that the order of the build should have followed dirtyepic's suggestions, but i can't argue with the script's results.
so i'm still inclined to think that proper cflags and proper maintenance of the toolkit could be something that the majority of the people who are having problems may be missing.
on those other occasions where the tc rebuilds seemed to be taking much longer than expected, my observations were based on total time required to complete the script, not the total time for any step in the process, such as glibc being recompiled twice in a row. the observations were made on a slower box feeding code to a faster compiling assistant via distcc. the delays were probably attributable to processing overhead on the slower box with too many instances of gcc multitasking because of a high value of j. i think that the older pc just became overwhelmed with preprocessing, and the other boxes on the farm were in a wait state. in short, i've learned that even if you have a big distcc assistant farm, a slow box is still a slow box, and your performance under distcc is not determined by the bandwidth of your compiling assitstants.
thanks.
even though glibc-2.3.4.20050125 and -r1 are supposed to have serious problems, i'm happy to say that i've never run into them. the toolkit rebuild went well, and that my system is now rebuilding world files with the newuse parameter without any problems. i would have sworn that the order of the build should have followed dirtyepic's suggestions, but i can't argue with the script's results.
so i'm still inclined to think that proper cflags and proper maintenance of the toolkit could be something that the majority of the people who are having problems may be missing.on those other occasions where the tc rebuilds seemed to be taking much longer than expected, my observations were based on total time required to complete the script, not the total time for any step in the process, such as glibc being recompiled twice in a row. the observations were made on a slower box feeding code to a faster compiling assistant via distcc. the delays were probably attributable to processing overhead on the slower box with too many instances of gcc multitasking because of a high value of j. i think that the older pc just became overwhelmed with preprocessing, and the other boxes on the farm were in a wait state. in short, i've learned that even if you have a big distcc assistant farm, a slow box is still a slow box, and your performance under distcc is not determined by the bandwidth of your compiling assitstants.
thanks.
Bob tcupdate.sh uses the order " glibc binutils gcc && glibc binutils gcc". Both work, hell going by the forums 98 to 99% of the time "emerge -uD/or -e " work well other wise there would be tons of post complaining about " me broke after emerge -uD .. " and traceing it back to a broken TC. It happens, but a hugh majority of post are about newbei errors, this package is blocked or broken, I optimized the shit out my CFLAGS so that when I jump out the window with it we go faster but then it breaks 
, and portage circular dependenceies that crop up and go away, and how to use emerge. If you go by the number of registered users 80747 and figure just a quater of them use gentoo full time and update once or twice a year, then a very small percentage of people have problems. Its mainly us nutters jumping out the window
, and portage circular dependenceies that crop up and go away, and how to use emerge. If you go by the number of registered users 80747 and figure just a quater of them use gentoo full time and update once or twice a year, then a very small percentage of people have problems. Its mainly us nutters jumping out the window thanks. it appears that my observations about time spent emerging glibc last night could have been attributable to having my locales.build overwritten, so that i inadvertently compiled all of the default locales. 
i think you're right -- most of the problems come from keyboard/chair issues. on average, i have one or two systems going through a clean install on any given day, and i always have one or two systems in an update on any given day. i've blazed the trail with some serious cflag optimizations, and i've been out the window more times than i care to think of ... but i still haven't had the overwhelming toolkit problems that so many users have been reporting.
i still think that gentoo is far more stable than some of these threads in the forums would lead people to believe. i think that experience has to play a large role -- especially when considering that those of us that are constantly at the windowsill aren't running into all of the reported problems.
thanks for the note on the order of operations in tcupdate -- i was going to look it over later today and change the order of operations, but now it seems that i won't need to do that.
i think you're right -- most of the problems come from keyboard/chair issues. on average, i have one or two systems going through a clean install on any given day, and i always have one or two systems in an update on any given day. i've blazed the trail with some serious cflag optimizations, and i've been out the window more times than i care to think of ... but i still haven't had the overwhelming toolkit problems that so many users have been reporting.
i still think that gentoo is far more stable than some of these threads in the forums would lead people to believe. i think that experience has to play a large role -- especially when considering that those of us that are constantly at the windowsill aren't running into all of the reported problems.
thanks for the note on the order of operations in tcupdate -- i was going to look it over later today and change the order of operations, but now it seems that i won't need to do that.
Hi,
I'm reinstalling my box, and decided to use the stage 1 on 3 method on the 2005.0
I'm currently at the step of configuring my kernel (phase 8 ) and everything went fine up to that point. I just had to unmask linux-headers>2.6 and the normal sources > 2.6 which are hardmasked to avoid global update of everybody. The emerge of udev is also no more necessary as it is now in system. devfs has also to be deactivated. Gcc 3.4 is still not the default compiler version, you still have to unmask it.
For information I'm on a pentium-m, I installed from an existing linux installation using the i686-stage3 (the final one ) It should have been the same with the livecd but I could not allow not using my computer during 2 days so ...
I should not encounter any problem now since everything is emerged. Thank you for you How to, Bob P
I'm reinstalling my box, and decided to use the stage 1 on 3 method on the 2005.0
I'm currently at the step of configuring my kernel (phase 8 ) and everything went fine up to that point. I just had to unmask linux-headers>2.6 and the normal sources > 2.6 which are hardmasked to avoid global update of everybody. The emerge of udev is also no more necessary as it is now in system. devfs has also to be deactivated. Gcc 3.4 is still not the default compiler version, you still have to unmask it.
For information I'm on a pentium-m, I installed from an existing linux installation using the i686-stage3 (the final one
) It should have been the same with the livecd but I could not allow not using my computer during 2 days so ...I should not encounter any problem now since everything is emerged. Thank you for you How to, Bob P
I've tried again -- and I've run into a fatal error when attempting to rebuild the toolkit. The emerge of glibc-2.3.4.20050125-r1 croaks. I've filed a report with bugzilla:
http://bugs.gentoo.org/show_bug.cgi?id=86717
Much to my surprise, within minutes the bug was closed, and labelled as a duplicate of the bug that's effecting glibc-2.3.4-20041102-r1:
http://bugs.gentoo.org/show_bug.cgi?id=86465
am i the only one who's noticed that 1) the ebuilds are different, and 2) my bug report refers to 2005.0 while the others all refer to 2004.3 installs?
http://bugs.gentoo.org/show_bug.cgi?id=86717
Much to my surprise, within minutes the bug was closed, and labelled as a duplicate of the bug that's effecting glibc-2.3.4-20041102-r1:
http://bugs.gentoo.org/show_bug.cgi?id=86465
am i the only one who's noticed that 1) the ebuilds are different, and 2) my bug report refers to 2005.0 while the others all refer to 2004.3 installs?
the problems appear to be [SOLVED], so i'm closing this thread and starting a new one for the 2005.0 Stage 1/3 installation method:
http://forums.gentoo.org/viewtopic-t-314985.html
Locked --Maedhros.
http://forums.gentoo.org/viewtopic-t-314985.html
Locked --Maedhros.