Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Stage 1/3 Installation Support - 2005.0 & GCC 3.4.3
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 16, 17, 18 ... 22, 23, 24  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Fri Apr 22, 2005 9:27 pm    Post subject: Reply with quote

FYI, I'm adding this to the Quick Reference Guide at the beginning of this thread:


:arrow: "emerge -e system" fails at python-fchksum

this problem appears to be caused by a problem in the python-fchksum ebuild. python-fchksum requires python as a dependency, even though the ebuild fails to list python as a dependency. as a result, when an "emerge -e system" is performed, portage has no way of knowing that python needs to be emerged prior to python-fchksum. portage mistakenly emerges python after python-fckhsum, instead of before it.

this causes a critical error in the event that a CHOST setting has been changed to something different than the CHOST setting with which python-fchksum had been originally compiled when the tarball was created. when the system is re-emerged using the --emptytree parameter, it appears that some static file headers and/or libraries within the python-fchksum ebuild are retained, and python-fchksum mistakenly looks for a the previous version of the GCC compiler with which it was originally compiled. this results in a critical stop and the issuance of an error message such as:


Code:
gcc-config error: Could not run/locate "i386-pc-linux-gnu-gcc"


the solution to this problem is actually quite simple. just emerge python, and then resume the installation at "emerge -e system". this effectively eliminates the circular dependency problem.

Code:
# emerge python && emerge -e system


unfortunately, this is a problem that is caused by shoddy programming in the ebuild. although this problem has been reported to Bugzilla, the bug was dismissed with a resolution of "won't fix."

unfortunately, it appears that the python devs have no intention of fixing this bug. :?

_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Fri Apr 22, 2005 9:42 pm    Post subject: Reply with quote

I forgot to mention this:

The python-fchksum error is likely to be encountered by two groups of people:

1. People who have correctly configured their systems, and are changing their CHOST setting from that which was originally specified in the tarball. This group of people includes anyone building for the Pentium and Pentium-MMX architectures using the x86 tarball and the 586 CHOST setting.

2. People who have incorrectly configured their systems, having blindly followed the Guide and chosen the x86 tarball and a 586 or 686 CHOST setting when building a system for a 686-class processor, instead of choosing the i686, Pentium3 or Pentium 4 tarballs and a 686 CHOST setting.

HTH! :wink:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks


Last edited by Bob P on Mon Apr 25, 2005 12:59 pm; edited 1 time in total
Back to top
View user's profile Send private message
Red Moose
n00b
n00b


Joined: 16 Apr 2005
Posts: 24

PostPosted: Sat Apr 23, 2005 2:03 am    Post subject: Reply with quote

Bob, just a word to say thanks for the guide. It worked great on my laptop and I didn't run into any problems (well except for my own cock up of paritioning only 40MB for /boot, forgetting that the resierfs journal takes 33!), but anyway it was all up in well under two days and miraculously, even after adding X and fluxbox and several other apps, there hasn't been a single problem. I think that the NPTL Stage 1/3 should probably be part of the official gentoo installation series having read through them and it.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5400
Location: Removed by Neddy

PostPosted: Sat Apr 23, 2005 4:40 am    Post subject: Reply with quote

Red Moose why have a jornally partion as boot?
/boot is not mounted doring normal operation (and is only manually mounted for a new kernel or edit grub.conf).
A journal file is there IF the system is not shutdown properly and files were still being accessed. The journel will aid in recovery - since /boot would not bee mounted (and if it was a very small chance any files were being accessed) a journal is a waste of space for a partition that will only use a few 10s of meg (and that is with lots-o-kernels and FBsplash files!!)


I use ext3 for my "/" partition at 60gig but a smaller 20meg ext2
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
kimchi_sg
Advocate
Advocate


Joined: 26 Nov 2004
Posts: 2915
Location: Singapore

PostPosted: Sat Apr 23, 2005 5:01 am    Post subject: Reply with quote

Naib wrote:
Red Moose why have a jornally partion as boot?

Because Bob P pontificates so?
_________________
Murphy's Law of Gentoo installation: If a compile can fail, it will.

MacGillicuddy's Corollary: At the most inopportune time.

Please search and read the FAQs before posting.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sat Apr 23, 2005 10:56 am    Post subject: Reply with quote

kimchi_sg wrote:
Naib wrote:
Red Moose why have a jornally partion as boot?

Because Bob P pontificates so?

wisecracker. :wink: this topic has already been discussed in the 2004.3 Support Thread, so rather than retyping, I'll just direct interested readers there...
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
AnonimoVeneziano
n00b
n00b


Joined: 25 May 2003
Posts: 65

PostPosted: Sat Apr 23, 2005 2:13 pm    Post subject: Tip: Styles can be applied quickly to selected text. Reply with quote

I've just finished installing Gentoo using Stage 1 on 3 guide and I have to say "Great work bob!".

I can give you only one suggestion .

When you explain how to edit the file /etc/conf.d/net to enable DHCP on eth0 you also suggest to add the line : dhcpcd_eth0="-t 10" .

Some routers (for example the Zyxel 650R-31) has a DHCP server initialization time for the first
DHCP query after begin switched on that lasts approximately 10 seconds.

All the subsequent querys after the first one are processed im
ediatly, but very first one takes from 10 to 12 seconds to begin accomplished.

If a N00b follows blindly the guide (without knowing what "-t 10" means for DHCP) can experience DHCP timeouts at boottime the first time he boots gentoo after having switched on the router without having a clue of why.

So I suggest to add a note or modify the value to "-t 15"/"-t 20" or remove that line from the Howto.

Bye

Marcello
Back to top
View user's profile Send private message
afabco
Guru
Guru


Joined: 24 Feb 2004
Posts: 380

PostPosted: Sun Apr 24, 2005 4:56 am    Post subject: confused about which make.conf to use Reply with quote

Later edit:

OK, I took a break and had a bottle of liquid inspiration and I think I've got it figured out. Again.

It's not the 'make.conf' that is of primary concern. It's the CFLAGS that's in the make.conf.

So for the first toolchain build, use cflags that you want that will work with gcc-3.3.whatever.

For the second toolchain build, change the cflags to those you want to use with gcc-3.4, and continue to use those until completion.

Is this right?

/later edit

---------------------------

I've gone and confused myself. Again. :oops:

What sort of make.conf should be set up before the first toolchain build?

1. the make.conf we want to end up with after everything's finished?
2. The one in the untarr'ed stage3 tarball? (that was looks very minimal, and based on all the guides I think not, but I include the option for completeness)
3. The one from step 6.5 in the 2005.0 stage 1/3 guide, perhaps changing the -march?
4. Something else?

This is what comes from thinking about things too much.

I understand (I think) that before starting the second toolchain build, we do in fact want the make.conf to be in it's final version.

Right?

Thanks!
_________________
Anyone who puts a small gloss on a fundamental technology, calls it proprietary, and then tries to keep others from building on it, is a thief.
-Tim O'Reilly
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sun Apr 24, 2005 12:40 pm    Post subject: Reply with quote

for the first toolchain build (while you're using GCC 3.3.5), you should use absolutely minimal CFLAG settings and the -O2 optimization level, and only -march=<processor-specification>. do not use -mtune, as it is incompatible with GCC 3.3.5. flags and optimization level should be minimal at this point. there's no point in using extreme settings at this stage, as the compiler's output ultimately gets thrown away anyway.

for the first compile, you should use a make.conf that looks just like the example make.conf in the Guide.

for the subsequent builds, you will be using GCC 3.4.3. at that point you can use those CFLAGS that are recognized by GCC 3.4.3 that weren't recognized by the previous version.

i thought i had made that pretty clear in the Guide... hmm... maybe its the liquid inspiration that caused the problem?
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
starrbuck
Tux's lil' helper
Tux's lil' helper


Joined: 04 Apr 2005
Posts: 138
Location: North Texas

PostPosted: Sun Apr 24, 2005 3:02 pm    Post subject: Reply with quote

Hi, Bob, and thanks for a great guide. I'm looking forward to the speed increase once the system is built in a few days!

I started with the P3 tarball and I am currently on the "emerge -e system" in section 7.2.5 on my dual Pentium III 600 box. In the previous 7.2.1 step, I opted for a rather conservative (but not fully conservative) CFLAGS setting, and now I am having second thoughts.

Here is what I currently have in my CFLAGS and CXXFLAGS:

Code:
CFLAGS="-O3 -march=pentium3 -fforce-addr -fomit-frame-pointer -pipe"
CXXFLAGS="${CFLAGS}"

The reason I went more conservative was because I was unsure the flags would be as beneficial on a P3 as they were on your example P1. However, I just had time to read this whole thread today, and in this quote you say explicitly that they are good for all Pentium platforms:

Bob P wrote:
The Stage 1/3 Guide covers how to build a specific optimized toolkit on ALL x86 platforms. The exact same flags are to be used -- without any changes -- regardless of wheter you're building on a P1, P2, P3 or P4.

Therefore, if I were going to back up and start the important processes over, please tell me if I would be correct to do this:

1. Update make.conf with fully-optimized flags:

Code:
CFLAGS="-O3 -march=pentium3 -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

2. Re-rebuild the toolkit:

Code:
emerge glibc binutils gcc portage

3. Re-recompile the system:

Code:
emerge -e system

Thanks!
Back to top
View user's profile Send private message
Sith_Happens
Veteran
Veteran


Joined: 15 Dec 2004
Posts: 1807
Location: The University of Maryland at College Park

PostPosted: Sun Apr 24, 2005 3:37 pm    Post subject: Reply with quote

That should work fine starrbuck. :)
_________________
"That question was less stupid; though you asked it in a profoundly stupid way."
I'm the brains behind Jackass! | Tutorials: Shorewall
Back to top
View user's profile Send private message
Moriah
Advocate
Advocate


Joined: 27 Mar 2004
Posts: 2053
Location: Kentucky

PostPosted: Sun Apr 24, 2005 6:20 pm    Post subject: What should the CFLAGS be for an Athlon? Reply with quote

I am running the following cpu:
Code:
processor      : 0
vendor_id      : AuthenticAMD
cpu family     : 6
model   : 10
model name     : AMD Athlon(tm) XP 2000+
stepping       : 0
cpu MHz        : 1675.033
cache size     : 256 KB
fdiv_bug       : no
hlt_bug        : no
f00f_bug       : no
coma_bug       : no
fpu   : yes
fpu_exception  : yes
cpuid level    : 1
wp    : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse pni syscall mmxext 3dnowext 3dnow
bogomips       : 3317.76
I am currently running the following CFLAGS:
Code:
CFLAGS="-O3 -march=athlon-xp -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe"
I would like to know which of the -mtune=CPU-TYPE choices I should be using:_athlon, athlon-tbird_, _athlon-4, athlon-xp, or athlon-mp_. It is my assumption that it should be athlon-xp, but I wanted to make sure before I went and changed it and rebuilt everything. :)

BTW I now have a bootable and running 1 on 3 system. :D
Back to top
View user's profile Send private message
moocha
Watchman
Watchman


Joined: 21 Oct 2003
Posts: 5722

PostPosted: Sun Apr 24, 2005 6:22 pm    Post subject: Reply with quote

athlon-xp, but:
Don't bother rebuilding just because you added -mtune. -mtune is always implied by -march. It's duplicated there just for the benefit of the (very few) packages that still haven't gotten their act together and filter out -march. Very few indeed.
So you can safely omit -mtune without losing much.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin
Back to top
View user's profile Send private message
Sith_Happens
Veteran
Veteran


Joined: 15 Dec 2004
Posts: 1807
Location: The University of Maryland at College Park

PostPosted: Sun Apr 24, 2005 7:02 pm    Post subject: Reply with quote

moocha wrote:
athlon-xp, but:
Don't bother rebuilding just because you added -mtune. -mtune is always implied by -march. It's duplicated there just for the benefit of the (very few) packages that still haven't gotten their act together and filter out -march. Very few indeed.
So you can safely omit -mtune without losing much.
Then again you lose nothing by adding it. :wink:
_________________
"That question was less stupid; though you asked it in a profoundly stupid way."
I'm the brains behind Jackass! | Tutorials: Shorewall
Back to top
View user's profile Send private message
moocha
Watchman
Watchman


Joined: 21 Oct 2003
Posts: 5722

PostPosted: Sun Apr 24, 2005 8:05 pm    Post subject: Reply with quote

Sure - I had just gotten the impression that Moriah wanted to re-emerge system just because he added that, and it'd have been a shame to burn all those CPU cycles pointlessly :).
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin
Back to top
View user's profile Send private message
Sith_Happens
Veteran
Veteran


Joined: 15 Dec 2004
Posts: 1807
Location: The University of Maryland at College Park

PostPosted: Sun Apr 24, 2005 8:08 pm    Post subject: Reply with quote

moocha wrote:
Sure - I had just gotten the impression that Moriah wanted to re-emerge system just because he added that, and it'd have been a shame to burn all those CPU cycles pointlessly :).
Oh, your right. My apologies, I didn't read carefully. :oops:
_________________
"That question was less stupid; though you asked it in a profoundly stupid way."
I'm the brains behind Jackass! | Tutorials: Shorewall
Back to top
View user's profile Send private message
afabco
Guru
Guru


Joined: 24 Feb 2004
Posts: 380

PostPosted: Sun Apr 24, 2005 8:30 pm    Post subject: Reply with quote

>>i thought i had made that pretty clear in the Guide... hmm... maybe its the liquid inspiration that caused the problem?

You did, and it does now. I had just gotten to thinking about it too much.

Thanks!
_________________
Anyone who puts a small gloss on a fundamental technology, calls it proprietary, and then tries to keep others from building on it, is a thief.
-Tim O'Reilly
Back to top
View user's profile Send private message
Nairou
n00b
n00b


Joined: 05 Jun 2004
Posts: 25

PostPosted: Mon Apr 25, 2005 3:38 am    Post subject: Reply with quote

Bob P wrote:
I forgot to mention this:

The python-fchksum error is likely to be encountered by two groups of people:

1. People who have correctly configured their systems, and are changing their CHOST setting from that which was originally specified in the tarball. This group of people includes anyone building for the Pentium and Pentium-MMX architectures using the x86 tarball and the 586 CHOST setting.

2. People who have incorrectly configured their systems, having blindly followed the Guide and chosen the x86 tarball and a 586 CHOST setting when building a system for a 686-class processor, instead of choosing the i686, Pentium3 or Pentium 4 tarballs and a 686 CHOST setting.

HTH! :wink:


:oops:

Okay, I seem to have fallen prey to #2, though not wholly due to blindly following the guide. I'm compiling on a pentium2, and do have my CHOST correctly set to i686, but I did start with the x86 tarball. I remember reading in the Jackass threads the idea of doing the initial toolset build using the basic x86 tarball, and then optimizing the compilation yourself. I guess I read wrong. :oops:

Am I correct in assuming the fix to this error is a complete fix? Meaning, after emerging python, the end result of "emerge -e system" will still turn out the same as if I had started the entire process with a proper i686 tarball? I don't want to have to worry about possible future issues and have to restart the whole installation.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Apr 25, 2005 12:22 pm    Post subject: Reply with quote

Nairou wrote:
I'm compiling on a pentium2, and do have my CHOST correctly set to i686, but I did start with the x86 tarball. I remember reading in the Jackass threads the idea of doing the initial toolset build using the basic x86 tarball, and then optimizing the compilation yourself. I guess I read wrong. :oops:


whatever you read in the Jackass! thread you misunderstood. x86 in that context refers to the Intel family of x86 processors, not to the Gentoo x86 tarball. :roll:

i wouldn't recommend trying to take information from a different project and applying it here. you're going to get yourself into trouble by finding "novel" approaches that are not part of the Guide. if you want the Guide to work, then you have to do what it tells you to do and not go changing it after you read something somewhere else.

realistically speaking, the answer to your question should be that if you didn't follow the Guide, no troubleshooting is availble for botched installations, and you must go back and reinstall, following the Guide.

when in doubt about any system that you've built improperly, the correct answer is to reinstall. it will usually take less time than a complete system rebuild anyway.

based on your post, i get the impression that you think that emerging python followed by one emerge -e system will be sufficient to fix your system. that's not the case. the Guide tells you that to build a system properly you must emerge -e system twice. you still have to do that. the reference to emerge python and then emerge -e system is only designed to put you back where you were when the compile broke -- one emerge -e system had failed, and one emerge -e system gets resumed after emerging python. that doesn't mean that you can omit subsequent steps like performing the second emerge -e system. it also doesn't mean that the steps that are necessary to properly build a system are sufficient to fix a broken one.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Apr 25, 2005 1:14 pm    Post subject: Reply with quote

Nairou wrote:
Am I correct in assuming the fix to this error is a complete fix? Meaning, after emerging python, the end result of "emerge -e system" will still turn out the same as if I had started the entire process with a proper i686 tarball? I don't want to have to worry about possible future issues and have to restart the whole installation.


the steps in the Guide are what is required to build a system properly on the first pass, assuming that you have done everything right. if you have done something wrong, all bets are off. if you have doubts about the stability of your system and you want to be absolutely certain that it works properly, then start over. in making recommendations about how to recover from a botched installation, we cannot assume responsibility for fixing a system or make any guarantees that it will work properly in the future.

IMO the best way to recover from a botched installation is to start over and perform the installation properly. it will probably take less time that performing two emerge -e systems and two emerge -e worlds, and there will be no unpredictability in the results.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Sith_Happens
Veteran
Veteran


Joined: 15 Dec 2004
Posts: 1807
Location: The University of Maryland at College Park

PostPosted: Mon Apr 25, 2005 2:22 pm    Post subject: Reply with quote

Not to completely disagree with you Bob, but I think you are being a little hard on the guy. :? It is true that he didn't correctly follow the guide, but I don't think the answer to his question is a complete reinstall. Whether you start with a generic x86 tarball (with an i386 chost), or an i686 tarball, in the end you'll have a system on which all the packages have been recompiled and will be optimized the same way, granted that you follow the final rebuild sequence of emerge glibc binutils gcc portage && emerge -e system && emerge -e system.

The only problem that your going to run into using the generic x86 tarball is that python-fchksum is going to crap out on your first emerge -e system after your first toolkit upgrade from gcc 3.3.5 to 3.4.3. The reason being is an error (I'm starting to agree with Naib on this one) in the python-fchksum and/or python ebuild that occurs when you change your CHOST. The way around this problem is to emerge python before running emerge -e system. It's that simple, if you do that then all will be well, and you can follow the install normally. However, this is only a troubleshooting measure, the best fix is for everybody doing the install to use the correct tarball from the beginning and save themselves and us the trouble. :wink:
_________________
"That question was less stupid; though you asked it in a profoundly stupid way."
I'm the brains behind Jackass! | Tutorials: Shorewall
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Apr 25, 2005 11:34 pm    Post subject: Reply with quote

i'm not trying to be hard on anyone. but i think its important to distinguish between what constitutes the best advice for somebody who's midway in an install that isn't working properly and somebody who's finished an install, and has already populated his world files, and has found that there are problems with his system that need to be eradicated -- especially if he's making long term reliability a paramount concern.

if somebody's in the middle of an install, its simple enough to adapt to the install by changing a setting before all of the redundant emerges are performed. in a case like that, it makes alot of sense to just switch a CHOST or a -march setting and perform a couple of emerge -e systems.

on the ohter hand, when somebody's already populated their world, and they're concerned that they've got a stability problem, a couple of emerge -e systems aren't going to solve their problems. in a situation like that, as an absolute minimum, they have to do this:

Code:
emerge -e system
emerge -e system
emerge -e world
emerge -e world


THAT process takes an awful long time. in fairness to the user, they're probably better off reinstalling and getting it right from the beginning, as it will certainly take less time for them to reinstall than to completely rebuild their system properly to eradicate all of the gremlins.

the moral of the story, at least as i see it, is that its more economical for the user from a time perspective to perform an installation properly the first time. the next rung down on the economy of time scale is to adapt a system that has a recognized problem early in the install. much farther down is the rung where the user finds that they have a corrupted system after its been in use for a while. they have to make multiple, multiple passes over the entire system, redundantly emerging packages in an effort to eradicate statically retained libraries and/or headers.

its not that i'm telling the user that i won't support them when the make mistakes. much to the contrary, i am giving them a recommendation for the most expedient method of resolving their problem -- a recommendation that takes into account the fact that their time is valuable and should not be wasted in trying to salvage an installation that isn't worth salvaging. sometimes you're just better off if you cut your losses, and i would argue that these people are better off reinstalling rather than rebuilding. in addition to being much quicker in terms of the total user time outlay, reinstalling is the only method that's guaranteed to eradicate the problems that exist. statically retained files are harder to eradicate than any of us would like to admit, and it makes more sense to avoid the problems that they cause than it does to try to squash them using a brute force redundant emerge method.

how salient this advice seems to anyone will largely depend upon the speed of their CPU. the guys who are lucky enough to have high frequency boxes can afford to squander CPU cycles, while the guys with lower frequency boxes have to conserve them. you guys that are fortunate enough to have fast PCs can do it any way that you want to, as you probably won't perceive the difference. but don't let disposable CPU cycles bias your outlook -- the guys with slow PCs should ALWAYS reinstall and NEVER try to recover a botched installation. that's just a waste of their time.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Nairou
n00b
n00b


Joined: 05 Jun 2004
Posts: 25

PostPosted: Mon Apr 25, 2005 11:44 pm    Post subject: Reply with quote

After feeling like an idiot for overlooking the i686 tarball (not to mention the temporary memory lapse on whether a pentium2 was even a i686 - I've been using AMD too long), I've gone ahead and restarted the guide and install from scratch. Lost two days in the process, but I'll get the hang of this one day! Thanks Bob P for both the guide and the response, restarting the install is definitely preferable to fighting problems later on. :)
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5400
Location: Removed by Neddy

PostPosted: Tue Apr 26, 2005 7:16 am    Post subject: Reply with quote

I think the problem with the stage3 tarball that results in the python-fscksum is you look in the d/l dir and their is an x86 tarball a x64, a PPC tarball and also pentium3,4...
NOw my processor is a x86 so naturally I grab that, although in closer inspection there is a pentium4 tarball.


It is not ppl are stupid or cannot follow the guide, quite a few ppl have fallen into the trap (and I am sure others have tried it, failed and not posted and gone to a standard install). It's not a problem with the guide it is just human nature to see something that matches and get blinded to anything else UNLESS you are told to look.

Would it be worth in the guide around that section a nice bold, big typeface mention that there is a x86 tarball as well as more CPU specific ones. IF you pick the x86tarball there will be problems later on so pease pick the one associated with your processor.
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Tue Apr 26, 2005 2:35 pm    Post subject: Reply with quote

Naib wrote:
I think the problem with the stage3 tarball that results in the python-fscksum is you look in the d/l dir and their is an x86 tarball a x64, a PPC tarball and also pentium3,4...
NOw my processor is a x86 so naturally I grab that, although in closer inspection there is a pentium4 tarball.

.

i don't think that its a problem with the organization of the download mirrors. on every mirror that i've been to, the file heirarchy looks like this:

Code:
http://<your-mirror-here>/releases/x86/2005.0/stages/

athlon-xp/
hardened/
i686/
pentium3/
pentium4/
x86/


there are no PPC or AMD64 tarballs in the x86 file tree to confuse anyone. the entire family of x86 processors, and only the family of x86 processors, lie beneath the x86 subdirectory on the mirrors. so its not as if the file hierarchy is at all ambiguous, or as if user is being deceived, or that these tarballs have all been sequestered away in independent or obfuscated locations. they're all listed right on the same page. when a person with a pentium 4 reads that page, they have to make a conscious decision NOT to choose the tarball that's right for their architecture.

i have to admit, i am at a loss as to why anyone would choose an x86 tarball over a pentium 4 tarball if they have a pentium 4 processor and both tarballs are listed right there on the same page. the only way that i can imagine that they're making that mistake is because they're just using wget to fetch the file from their command line, and they're not even bothering to use a browser to walk through the gentoo mirror. in a case like that, the problem lies with the user's laziness, not with anyone or anything else.

i guess the same would have to be said for choosing x86 instead of i686 if you have a pentium 2 processor, but i guess there's more room for error in that instance if we consider that people may not know that their pentium 2 processor is in the i686 family. in that case, the error could be made because of user ignorance about the syntax that Gentoo uses. i'll freely admit that i was as ignorant as everyone else about this until i took the time to educate myself. but i think that anyone with a little skill at deductive reasoning is likely to say something like i did when i was confronted by this issue: "Hey, I see a Pentium 3 and a Pentium 4 tarball, but where is the Pentium 2 tarball and what is that i686 tarball?" At that point, I would hope that a light bulb should turn on.



Quote:
It is not ppl are stupid or cannot follow the guide, quite a few ppl have fallen into the trap (and I am sure others have tried it, failed and not posted and gone to a standard install). It's not a problem with the guide it is just human nature to see something that matches and get blinded to anything else UNLESS you are told to look.


its not human nature for everyone. there are some people (like Sith) who are vigilant about learning everything that needs to be learned before they begin a linux installation. these people exercise due diligence and learn everything that needs to be learned before they get started. human nature being what it is, there are people at the other end of the spectrum like those who you describe who make no effort to learn on their own and expect to be spoon feed so that they don't have to make any decisions. most people fall between these two extremes.

although you may or may not not know it, the Guide does already have a warning in it that warns people about making the correct architecture choice. some people probably read it, and some people probably don't. personally, i don't think that the answer is to add more boldfaced type. the answer is for readers to read, think, and learn. choosing the correct tarball for your PC is the NUMBER ONE thing that a new Gentoo user has to learn. if a new user doesn't bother to learn this by following the Gentoo Installation Handbook, then who is to blame?

i have always maintained that the Stage 1/3 Guide was never intended for neophyte users. even so, its written well enough that new users seem to prefer it over the Gentoo Installation Handbook and tend to gravitate toward it. in fairness to the Guide, the Stage 1/3 Guide has always been intended as an installation method for ADVANCED/EXPERT users. rebuilding a toolkit is not an endeavor that should be underdaken by a n00b. even so, there seem to be a vast number of new users who are employing the Stage 1/3 Guide to build their systems.

looking at objective data, my webserver is getting over 70 visits per day from new, unique users who download the Stage 1/3 PDF. that's 70+ new Stage 1/3 users every single day. literally, thousands of people have been using the Guide, and a very, very small number are having problems and posting to this thread. from my perspective, the high rate of utilization coupled low rate of failure suggests that the Guide actually does its job fairly well -- the number of support requests that we find here are very few in relation to the total number of people using the Guide.

from a practical standpoint, there's no way to ensure that the Guide will be 100% fault-tolerant for all users, as its not possible to completely remove the user from the decision making process. (i have antoher project designed to fill that niche). as i see it, the only way to avoid the choice of the wrong tarball problem would be to post a matrix of CPUs and the correct tarballs that should be associated with them, and to expect that people will actually read it -- which they may or may not do. although something like that would seem a fine addition to the Gentoo Installation Handbook, my criteria for writing the Stage 1/3 Guide require this knowledge as a prerequisite for its use.

ultimately it comes down to deciding what the lowest common denominator is going to be that i'm willing to write for. the lower i set the bar, the more i have to write, and the more likely people people will be to start skipping sections of the Guide. i am willing to accept the fact that i cannot teach everything to everyone.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3 ... 16, 17, 18 ... 22, 23, 24  Next
Page 17 of 24

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum