Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
march=pentium-m
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
teancum
n00b
n00b


Joined: 06 Dec 2005
Posts: 17

PostPosted: Fri Dec 16, 2005 10:01 pm    Post subject: march=pentium-m Reply with quote

i have a centrino notebook and wanted to use pentium-m what are my options on the install?
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 Dec 16, 2005 10:04 pm    Post subject: Reply with quote

install a p3 tarball, upgrade to GCC 3.4.4, change march setting to pentium-m, completely rebuild your system files twice. then after you 've done that, you can emerge world files.

imho, there are not sufficient advantages to pentium-m to warrant the trouble.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
teancum
n00b
n00b


Joined: 06 Dec 2005
Posts: 17

PostPosted: Fri Dec 16, 2005 10:28 pm    Post subject: Reply with quote

Bob, you maintain the 1/3 stage install right? I will give it another try, do you (or anyone else) know if the next release of Gentoo will have stage 3 tarballs for pentium-m?
Back to top
View user's profile Send private message
teancum
n00b
n00b


Joined: 06 Dec 2005
Posts: 17

PostPosted: Fri Dec 16, 2005 11:18 pm    Post subject: Reply with quote

just wondering, if I use a Jackass stage 3 tarball I can change the march to penium-m without having to go through migration, right?
Back to top
View user's profile Send private message
-BarneY-
Tux's lil' helper
Tux's lil' helper


Joined: 03 Oct 2005
Posts: 91

PostPosted: Sat Dec 17, 2005 12:43 am    Post subject: Reply with quote

I suggest a stage1-installation for that, until there is no pentium-m-tarball out there. Its faster that rebuilding your system twice.

Or, as Bob said, take a pentium-3-tarball (pentium-4 will also be fine). Then you can emerge your new packages with march=pentium-m and migrate your system slowly to a pentium-m-system. ;)

teancum wrote:
just wondering, if I use a Jackass stage 3 tarball I can change the march to penium-m without having to go through migration, right?


Yes, if they have a pentium-m-tarball.
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 Dec 17, 2005 1:05 am    Post subject: Reply with quote

teancum wrote:
Bob, you maintain the 1/3 stage install right? I will give it another try, do you (or anyone else) know if the next release of Gentoo will have stage 3 tarballs for pentium-m?


yes, i wrote the Stage 1/3 Guides, and though i spent a year providing support for them I am now spending less of my time providing support for them as i have found more interesting things to do.

Now that the Stage 3 install plus two emerge -e systems is now the "official" Stage 1 installation method for Gentoo, and now that GCC 3.4.4 is now officially in the stable branch, the whole process of performing a Stage 1/3 install to get processor-specific GCC 3.4.4 installations has become rather blase' and it is no longer my pet project. its now the de-facto standard for Gentoo installation and upgrading, so i think that the Gentoo crowd should provide wider support for the installation method. that would free me up to spend my time doing more novel things.

i have no idea whether Gentoo plans Stage 3 tarballs for Pentium-M. the Rel-Eng people would be the ones to talk to about that. personally, i don't think that its a logical use of their resources to provide a unique tarball for every CPU in existence, so i doubt that they'll do it. after all, Pentium-M is essentially a P3, and since Gentoo expects people to be doing alot of emerge -e systems now that they've deprecated the Stage 1 install, there's no reason for them to make and support a wide batch of tarballs when you can just do the build yoruself.

You can migrate to GCC 3.4.4 and Pentium-M using any number of methods. I think that there are 3 good options:

1. If you want to do the work yourself, just follow the Stage 1/3 Guide and you can do it all for free. It will take a long time.

2. If you want to take a shortcut, start off using a Jackass! P3 tarball, change the march specification, and do two emerge -e systems. that approach is still free, but it will still take a long time.

3. If you want to take the ultimate shortcut, support Jackass! and buy the Pentium-M CD. Then all that you have to do is untar the stage tarball. :wink:

As you can see, there are many ways to achieve the same end result. It all boils down to whether you'd rather do all of the work on your own, or whether or not you think that your time is valuable enough to support somebody else doing the work for you.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
teancum
n00b
n00b


Joined: 06 Dec 2005
Posts: 17

PostPosted: Sat Dec 17, 2005 1:26 am    Post subject: Reply with quote

Thanks Bob, I didn't know about the Jackass project, that should help a lot!
Back to top
View user's profile Send private message
Yuusou
Apprentice
Apprentice


Joined: 18 May 2005
Posts: 178
Location: Canada

PostPosted: Sat Dec 17, 2005 7:46 am    Post subject: Reply with quote

so, for Pentium M would you select the x86 stage tarball then? That's what I usually use, just wondering if it's an acceptable stage use
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 Dec 17, 2005 11:02 am    Post subject: Reply with quote

Yuusou wrote:
so, for Pentium M would you select the x86 stage tarball then? That's what I usually use, just wondering if it's an acceptable stage use


well yes, but no, you really need to choose the appropriate CHOST and tarball for your processor, and you should really avoid changing the CHOST specification unless you really know what you are doing. so although you might be able to get by with changing the CHOST if you're going to rebuild everything, you're really better off avoiding the problems that can be caused by changing CHOST settings by choosing the right CHOST in the first place.

this is a common mistake that alot of new users to gentoo make -- they choose the wrong combination of CHOST, tarball, and march setting. the whole idea of the processor specific Jackass! tarballs was to remove the user from making these three choices so that the kind of mistake you're describing could not be made.

if you have a pentium-m, this is what you need to do:

Bob P wrote:
install a p3 tarball, upgrade to GCC 3.4.4, change march setting to pentium-m, completely rebuild your system files twice. then after you 've done that, you can emerge world files.

imho, there are not sufficient advantages to pentium-m to warrant the trouble.


your best bet is to start with a P3 tarball and rebuild for Pentium-M, though you could safely do it with the i686 tarball. i would not recommend using the x86 tarball.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bad Penguin
Guru
Guru


Joined: 18 Aug 2004
Posts: 507

PostPosted: Sat Dec 17, 2005 4:27 pm    Post subject: Reply with quote

Bob P wrote:
your best bet is to start with a P3 tarball and rebuild for Pentium-M, though you could safely do it with the i686 tarball. i would not recommend using the x86 tarball.

The current P3 tarballs contain gcc 3.3.5, which does not support pentium-m. To use the "official" stage3 method, you would have to use the gcc 3.4.4 migration guide to upgrade gcc, edit your make.conf and change your CFLAGS, then emerge -e system && emerge -e system && emerge -e world && emerge -e world. This takes a considerable amount of time, particularly if you already have X/KDE installed etc...

I have written a bootstrapping script that will let you start with a stage1 in a chroot and go from there. You would have to complete the bootstrap (which will upgrade gcc), edit CFLAGS in make.conf, re-run the bootstrap, emerge -e system, then add whatever packages you need. This way takes considerable time also, but considerably less time than the rebuild system twice/world twice method.
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 Dec 17, 2005 5:37 pm    Post subject: Reply with quote

sure, the current *Gentoo* tarballs contain GCC 3.3.5, and require a convoluted series of steps to upgrade to Pentium-M because they come with an outdated toolkit. nobody in his right mind would use them as a starting point when there are better tools available. i think that the original poster has already figured that out.

some of the comparisons that have been suggested in this thread amount to comparing apples and oranges. if somebody is installing a new system, there is absolutely no need to perform two emerge -e systems and two emerge -e worlds. when you unpack a Stage 3 tarball, there are not yet any world files that exist as a superset of the system files! with a Stage 3 tarball the emerge -e system command and the emerge -e world command perform the *exact* same function. since the world package superset has not been populated yet, its utterly pointless to perform two emerge -e worlds after performing two emerge -e systems, as its the functional equivalent of performing four emerge -e systems and accomplishes nothing more than a waste of time. nobody in his right mind would do that either. referencing a 2+2 complete toolkit and world approach overestimates the time required for a clean system install by well over 100%! :roll:

i'm not sure that bootstrapping twice and performing an emerge -e system will take any less time than two emerge -e systems. i would bet that it would probably take more. ;) going through the motions of running a script or editing this that and the other thing will ultimately take more seat time than just changing a march specification, throwing a couple of emerge -e systems on the command line and going out Christmas shopping. so it all boils down to whether you're trying to minimize CPU time or seat time. personally, i think that my time is more valuable than my computer's, so i prefer to do things the easy way and minimize my seat time. if somebody gets off on sitting at a keyboard... to each his own. some of this ultimately invovles lily-gilding or personal preference, depending upon how you look at it.

so tell me, have you finished debugging the bootstrapping script yet? i am personally reluctant to recommend experimental methods that are either still in development or fresh out of development to new users when tried and true bullet-proof options are available. in that respect, there are established migration paths that have been around for quite a bit longer than the "official" methods and don't suffer from the errors in the "official" methods, which are still being debugged.

of course you always have a choice...
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bad Penguin
Guru
Guru


Joined: 18 Aug 2004
Posts: 507

PostPosted: Sat Dec 17, 2005 7:03 pm    Post subject: Reply with quote

Bob P wrote:
some of the comparisons that have been suggested in this thread amount to comparing apples and oranges. if somebody is installing a new system, there is absolutely no need to perform two emerge -e systems and two emerge -e worlds.

There are a few packages in the stage3 world file - gzip, glibc, gettext, linux-headers, and nano. Why they are there I have no idea. But if you don't do at least the first emerge -e world on a pristine stage3 tarball, your gzip, gettext, and nano might have problems. So to be completely safe you should at minimum rebuild those three packages after the first two emerge -e systems. Either way, it is an insane way to build any system. If anyone wants to install a gentoo box from the current x86 stage3 right now (by the handbook), they might or might not end up with a stable system and have no idea why or why it is not stable...

Bob P wrote:
when you unpack a Stage 3 tarball, there are not yet any world files that exist as a superset of the system files! with a Stage 3 tarball the emerge -e system command and the emerge -e world command perform the *exact* same function.

That depends on if you alter your USE flags or not. Gettext, for example, might not show up in the system list of you add -nls to your USE flags, then attempts to use it later might cause headaches. I don't know this for sure, the point it there is no way to know for sure as long as your world file is polluted already. As long as they don't start installing system utils like the filesystem tools, bootloaders, first then you are probably safe with emerge -e system x 2.

Bop P wrote:
'm not sure that bootstrapping twice and performing an emerge -e system will take any less time than two emerge -e systems.

Correct, but you can stop the bootstrap process after gcc completes, alter your CFLAGS, and carry on with the same bootstrap process and then a single emerge -e system. Which is why I just updated my bootstrap script and added a --gccpause option to allow you to do just that :)

Bob P wrote:
i would bet that it would probably take more. ;) going through the motions of running a script or editing this that and the other thing will ultimately take more seat time than just changing a march specification, throwing a couple of emerge -e systems on the command line and going out Christmas shopping.

Creating a clean, functioning stage3 from a stage1 tarball takes about 1/3rd of the time with my bootstrap script. It handles changes to CHOST inline, allows userlocales to speed up the process considerably, and correctly handles toolchain upgrades. Doing a bootstrap this way and then building all remaining world packages once takes about 2/3rds of the time as following the instructions in the gcc migration guide, takes about 1/5th of the time of a emerge -e system x2 and emerge -e world x2.

But here is the real kicker, it takes about 1/10th of the time supporting and debugging afterwords when compared to the hacked up inconsistent methods like revdep-rebuild or not at least doing the incredibly time wasting emerge -e system x2 emerge -e world x2 (is there a short name for that?).

Bob P wrote:
so tell me, have you finished debugging the bootstrapping script yet? i am personally reluctant to recommend experimental methods that are either still in development or fresh out of development to new users when tried and true bullet-proof options are available. in that respect, there are established migration paths that have been around for quite a bit longer than the "official" methods and don't suffer from the errors in the "official" methods, which are still being debugged.

I am debugging it as I go, it is far from completed, but the version that is out there does work in the environments I have tested it in (x86 and ppc). Right now it is evolving very rapidly as I need to fix breakage or add features, so I wouldn't wish it on anyone who wants to use it in a production environment. It will, however, be used in a production environment come hell or high water by Monday.

The "official" method right at this moment is extremely broken. The handbook fails to mention what will happen the first time you do an emerge -Du world after installing from a fresh stage3. It will break your toolchain, badly. The handbook fails to mention that at this point in time anyone who installs from the "official" stage3 needs to do the gcc migration. That is unless someone fixed that undocumented automatic switch to gcc 3.4.4 behavior.
Back to top
View user's profile Send private message
Zorminster
n00b
n00b


Joined: 17 Dec 2005
Posts: 15

PostPosted: Sat Dec 17, 2005 9:27 pm    Post subject: Reply with quote

Hi, first let me preface this post by saying the following

I have never used any form of linux- the reason I will be installing gentoo is entirely due to my buddy who swears by it and being the geek I am I wanted to give it at least a try. I'm not new to computer systems but I also probably don't display the same knowledge as many of the board members here-

I've given the Stage1/3 install guide a read over and I feel that I understand most of it. However, Im not sure WHY I will need to rebuild my system files twice. I'm sure theres a great reason that makes perfect sense, I just don't know it yet :P

I plan on using the Stage 1/3 guide and doing everything with the help of my buddy and I was wondering if you have any advice I should heed while doing this.

Pentium M 1600 mhz is the processor in this laptop I will be running gentoo on.

thanks!
Back to top
View user's profile Send private message
grx
Apprentice
Apprentice


Joined: 19 Jan 2005
Posts: 173
Location: Maryland

PostPosted: Sat Dec 17, 2005 11:30 pm    Post subject: Reply with quote

I've been playing with installing (and re-re-re-re-installing) gentoo on my dell i8600 with the same processor since this summer. (You should note that the only reason I've redone the installation a few times is because I'm mostly just playing with it and learning how everything works. Everything on the laptop more or less worked from the start.)

If you follow Bob's guide, you'll be just fine. It's worked every time for me, and I think I'm finally starting to grasp everything he's saying to do in it. You can find reasons for having to rebuild twice if you search the forums, but in a nutshell it makes sure that everything on the computer was compiled by the computer using the compiler and specifications you choose. It may take a while, but it's benefits are very noticeable. I use Matlab a lot, and I recently compared the speed at which some code I wrote ran between my gentoo and windows systems on the same laptop. (Yes, I'm dual-booting, which isn't too difficult to do if you're thinking about it.) Anyway, the code took 44 seconds to run in Windows, and only 20 seconds to run in gentoo (when I ran it in xfce. In gnome it took 26 seconds.)

Point is, yes it takes some time to do, but be patient. If you read through Bob's guide a few times (I'd read the Installation section of the gentoo handbook too) you'll find that the most time consuming part can be done without you there--just get everything up to the emerge -e system commands, then use && to do both re-compiles without stopping, and go to sleep. Another option is to just get to where you're done editing conf files and what not and using a whole string of commands with the && in between. (I believe Bob lists exactly how you'd have to type it when you get there.) When you wake up in the morning, you'll be ready to compile the kernel and everything else.

-------------
btw, teancum: Nice screen name. =)
Back to top
View user's profile Send private message
Zorminster
n00b
n00b


Joined: 17 Dec 2005
Posts: 15

PostPosted: Sun Dec 18, 2005 2:37 am    Post subject: Reply with quote

ah, okay thanks man. I do plan on dual booting gentoo and Windows XP Pro

btw, thats great to know about matlab- im taking quite a few courses next semester that are likely going to expect me using this quite a bit.

Guess Ill start searching forums and reading every thread i can find about dual booting
Back to top
View user's profile Send private message
teancum
n00b
n00b


Joined: 06 Dec 2005
Posts: 17

PostPosted: Sun Dec 18, 2005 4:13 am    Post subject: Reply with quote

That script looks preety keen, I will have to give it a try, I just look forward to the tarballs with gcc 3.4.4
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 Dec 18, 2005 5:02 am    Post subject: Reply with quote

Bad Penguin wrote:
But here is the real kicker, it takes about 1/10th of the time supporting and debugging afterwords when compared to the hacked up inconsistent methods like revdep-rebuild or

funny. i've never had problems with revdep-rebuild. i must be lucky. :)

Bad Penguin wrote:
.. the incredibly time wasting emerge -e system x2 emerge -e world x2 (is there a short name for that?).


I attribute it to developer @robmoss, so I call it the Rob Moss Rebuild. :lol:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bad Penguin
Guru
Guru


Joined: 18 Aug 2004
Posts: 507

PostPosted: Sun Dec 18, 2005 5:18 am    Post subject: Reply with quote

Bob P wrote:
Bad Penguin wrote:
.. the incredibly time wasting emerge -e system x2 emerge -e world x2 (is there a short name for that?).


I attribute it to developer @robmoss, so I call it the Rob Moss Rebuild. :lol:

How 'bout, robobuild? Heh heh.
Back to top
View user's profile Send private message
Yuusou
Apprentice
Apprentice


Joined: 18 May 2005
Posts: 178
Location: Canada

PostPosted: Sun Dec 18, 2005 6:05 am    Post subject: Reply with quote

I fear I may have misunderstood, when I asked what tarball to use, I meant while doing a stage1 installation, not stage3
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 Dec 18, 2005 10:15 pm    Post subject: The Cult of the Stage 1 Reply with quote

that's a funny question. with a Stage 1 installation, you don't have any choice. :roll:

i hate to say it, but i just feel like i have to -- if you don't know which tarball to use to perform a stage 1 install, then you don't know what the difference is between a Stage 1 and a Stage 3 tarball. maybe a Stage 1 install isn't the best approach for you. just a thought.

there's a reason that the Release Engineering team has decided to stop supporting Stage 1 installs, and it has to do with problems like these. Alot of people misintrepret their actions as amounting to a statement such as "N00bs have no business doing Stage 1 installs." I think that statements like that mischaracterize the state of the Stage 1 install right now, so I'll digress a little about that subject. If you're one of the people who are tired of reading this kind of stuff, do yourself a favor and skip over my post).



the reason that the Rel Eng team has decided to stop supporting the Stage 1 install is because they were wasting an awful lot of time answering questions from inexperienced users who had run into problems during stage 1 installs that they could not work through because of their inexperience. in contrast, there are far fewer problems with Stage 3 installs, so its rational for them to want to support a more error free installation method. so we have a few reasons in favor of their decision to guide users into Stage 3: its less error ridden, its easier for n00b users to successfully complete, and its easier for Gentoo to support.

but there's another reason that's even more important -- for the vast majority of users, a Stage 1 install provides them with NOTHING that they can't get from Stage 3; The Stage 1 installation process leaves them with the exact system that they would have had if they had just taken less time to extract a Stage 3 tarball. It is a rare circumstance where there is not a suitable Stage 3 tarball and the situation requires that a user perofrm a Stage 1 install. * [before flaming see footnote]

in their opinion (and I have to agree with them on this) the vast majority of Stage 1 users have been performing Stage 1 installs because the previous versions of the Gentoo Installation Handbook mischaracterized the purpose of the Stage 1 install. The way the old documentation was worded, users were left with the mistaken assumption that a Stage 1 install provided them with some sort of personalized customization for their computer that provided performance increase that a Stage 3 install would not. That's not the case. When you finish a STage 1 install, you end up with the same result as you would have if you had untarred a Stage 3 tarball for that processor. In reality, the machine-specific performance increases come from kernel customization, not from Stage 1 installs when equivalent Stage 3 tarballs already exist.

yet, because the documentation failed to clearly outline the rarity of the circumstances in which a Stage 1 install was actually necessary, alot of Gentoo users were mistakenly led down the path of performing Stage 1 installs. as a result, performing a Stage 1 install has become somewhat of a cultural phenomenon among Gentoo users. because the installation method was plagued by problems like circular dependencies, the user who performed a Stage 1 install was indoctrinated by fire into the ranks of the Gentoo elite. by performing a Stage 1 install they had earned their Red Badge of Courage and wore it proudly. this, in turn, only fostered the cult status of the Stage 1 install. as a result we now have old time Gentoo'ers who still believe that Stage 1 provides them with something special, when the majority of the time it does not.

an interesting phenomenon observed among members of The Cult of the Stage 1 (note: new term coined by Bob P!) is the fact that n00b users are drawn into the obsession of performing a Stage 1 install based upon the mistaken belief that they will actually gain something from it. for the vast majority of them, they gain nothing but a waste of time. in most cases they would be better off just extracting the appropriate Stage 3 tarball.

so we're left with an interesting phenomenon: people who should have chosen an easier option (stage 3) refused it. their refusal was not based upon informed contemplation of the facts, but instead it was based upon a misguided false belief that Stage 1 gave them something better than a Stage 3, when in the vast majority of cases it does not. Members of the Cult of the Stage 1 install are blinded by illogical faith. for those people, a stage 3 is a much better approach; its simpler, its error free, and its alot more n00b tolerant. it also doesn't subject the user to circular dependency problems the way Stage 1 does.

as an interesting paradox, the newest members in The Cult of the Stage 1 -- those who don't realize when it is totally unnecessary, are the same ones who can't work their way through troubleshooting a Stage 1 install without someone's help. Yet the same people who don't have any reall need to perform a Stage 1 install are the same people who perceive the most need to perform a Stage 1 install. If that is not evidence of cult behavior, i don't know what is. in this context, i like to think of the Rel Eng team's decision to stop supporting the Stage 1 install as an Official installation method as a long term effort in deprogramming young Gentoo users of their occult beliefs.

in contrast, the vast majority of the well-informed users will simply perform a Stage 3 install instead. go figure.




if there's confusion about which tarball you should be using for a stage 1 install, my recommendation would be to stick with a stage 3 tarball and a stage 3 install.



* Footnote: Since this is a Pentium-M thread, this is arguably a situation where you need to perform a processor-specific Stage 1 install in order to take advantage of all of the wornderful features of your processor that a Stage 3 tarball doesn't provide. Notice that I said "arguably." There are an awful lot of people who insist that processor optimization makes a huge difference in Gentoo. in reality, it does not. the incremental gain to be made by rebuilding a P3 tarball to enable the additional features of the Pentium-M processor is an exercise in diminishing returns -- you spend an awful lot of time rebuilding the system in the name of SSE2, which provides virtually no tangible results. but since Gentoo is about choice, we don't laugh out loud when people insist on doing this. we just mention that its not really worth the effort, but tell them the options available to them and let them go on their way.
_________________
.
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: Sun Dec 18, 2005 11:22 pm    Post subject: Reply with quote

Bad Penguin wrote:
Bob P wrote:
Bad Penguin wrote:
.. the incredibly time wasting emerge -e system x2 emerge -e world x2 (is there a short name for that?).


I attribute it to developer @robmoss, so I call it the Rob Moss Rebuild. :lol:

How 'bout, robobuild? Heh heh.


alot of people already call it the Rob Moss Method. when you say that, everyone knows what you're talking about. granted, its very robotic in its own way, which is a good thing. but i like to give credit where credit is due, and Rob Moss has made lots of very helpful posts about how to upgrade the system. by keeping his name on his rebuild method, it makes it easy for everyone to find his posts when they need to look them up.
_________________
.
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: Sun Dec 18, 2005 11:41 pm    Post subject: Reply with quote

Bad Penguin wrote:
Bob P wrote:
when you unpack a Stage 3 tarball, there are not yet any world files that exist as a superset of the system files! with a Stage 3 tarball the emerge -e system command and the emerge -e world command perform the *exact* same function.

That depends on if you alter your USE flags or not. Gettext, for example, might not show up in the system list of you add -nls to your USE flags, then attempts to use it later might cause headaches. ..

well, to be the devil's advocate, you should NEVER do that. when you're building a toolkit and or a world packge and you make the decision to suppress sections of code that are purposefully included by the developers, you're just asking for trouble. in that situation, there aren't alot of people that you can point the finger at when things break. :oops: if that happens, the first thing that you need to do is file a bug report so that the devs can address who or what is at fault.

Quote:
Bob P wrote:
so tell me, have you finished debugging the bootstrapping script yet? i am personally reluctant to recommend experimental methods that are either still in development or fresh out of development to new users when tried and true bullet-proof options are available. in that respect, there are established migration paths that have been around for quite a bit longer than the "official" methods and don't suffer from the errors in the "official" methods, which are still being debugged.

I am debugging it as I go, it is far from completed, but the version that is out there does work in the environments I have tested it in (x86 and ppc). Right now it is evolving very rapidly as I need to fix breakage or add features, so I wouldn't wish it on anyone who wants to use it in a production environment. It will, however, be used in a production environment come hell or high water by Monday.


just in case things don't work out as planned and you're faced with both hell and high water at the end of the weekend: i'd suggest marking your Guide as "Experimental" until its thoroughly debugged. The prerequisite for posting HowTo in Documentation Tips & Tricks is that they are fully debugged and actually work as advertised. the people who are posting experimental methods that are still in the debugging phase post "Experimental" disclaimers so that nobody will be burning them in effigy when the experimental install results in a b0rked system. on my experimental versions of the Stage 1/3 Guide, I've always put "Experimental" notices in HUGE red letters to provide full disclosure. just a thought.

Quote:
The "official" method right at this moment is extremely broken. The handbook fails to mention what will happen the first time you do an emerge -Du world after installing from a fresh stage3. It will break your toolchain, badly. The handbook fails to mention that at this point in time anyone who installs from the "official" stage3 needs to do the gcc migration. That is unless someone fixed that undocumented automatic switch to gcc 3.4.4 behavior.

you bring up a good point. personally, if i were running Release Engineering I would have tried to coordinate the marking of a new stable toolkit with the release of a new set of installation media. doing that just makes too much sense, as it completely avoids the problems that are introduced when you mark a new toolkit as stable and fail to coordinate an update in the installation media. widespread system b0rkages invariably result.

another way that the "official" docs are b0rked is that in the "safe method" they don't recommend full redundant rebulding of the world packages. as you've noted before, hitting the world files twice is absolutely necessary after a toolkit rebuild, to ensure that all of the world packages are compiled against world packages/libraries that were built with the new toolkit. but the "official" guide doesn't recommend that. :oops: (at least it didn't the last time that i read it). as a result, people are going to have mysterious problems crop up that will be an absolute bear to track down. a redundant world rebuild would avoid that problem completely.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
cyrillic
Watchman
Watchman


Joined: 19 Feb 2003
Posts: 7301
Location: Groton, Massachusetts USA

PostPosted: Mon Dec 19, 2005 12:24 am    Post subject: Re: The Cult of the Stage 1 Reply with quote

Bob P wrote:
... as a result, performing a Stage 1 install has become somewhat of a cultural phenomenon among Gentoo users. because the installation method was plagued by problems like circular dependencies, the user who performed a Stage 1 install was indoctrinated by fire into the ranks of the Gentoo elite. by performing a Stage 1 install they had earned their Red Badge of Courage and wore it proudly.

I guess this is no longer the case.

Now, even people doing stage3 installs can get burned enough to get their "Red Badge of Courage". :D
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 Dec 19, 2005 1:28 am    Post subject: Reply with quote

what's the problem with Stage 3 installs? are you referring to the system update/GCC migration problem that's referenced earlier in the thread? or were you thinking about something else that i'm not aware of?

in my simplistic way of looking at things, i like to compartmentalize issues by breaking them down into their most fundamental components. as i understand it, there's nothing wrong with any of the Gentoo 2005.1 Stage 3 tarballs. ever since the permissions issues were fixed on a couple of them, its been smooth sailing.

with that said, plenty of people are griping about the errors inherent in the GCC migration documents, for good reason. but that's a separate issue. if a user decides to perform GCC migration on top of a Stage 3 install, its not as if the Stage 3 install is the problem. its still 100% error free. the problem is that the GCC migration docs are defective, and that Gentoo Install documentation has completely overlooked the GCC migration problem. as a result, they fail to adequately warn the user of the perils inherent in performing an unplanned toolkit upgrade by using that dangerous "u" parameter when the user doesn't know what he is doing.

of course, if somebody wants to avoid all of the trouble of getting a fresh GCC 3.4.4 system up and running, i wouldn't recommend the Standard Gentoo Tarballs as a starting point, and i wouldn't recommend the Gentoo Documentation either. both are seriously out of date and are critically in need of an update.

its obvious to me that the Stage 3 install and the Stage 3 tarballs are not the problem -- the problem lies in the Gentoo Documentation. its still possible for the user to perform a flawless Stage 1/3 installation without any headaches, which proves that this is not a software problem. its a documentation problem.

in contrast to the Gentoo documentation problem, there are other tarballs and installation methods that don't suffer from any of these problems. i'd bet you could guess the handful of resources that i'd recommend to someone trying to accomplish a fresh GCC 3.4.4 installation without having to resort to the headaches induced by the standard Gentoo media and documentation. :!:

so is GCC migration the issue you were referring to, or is there something else that's seriously b0rken?
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
cyrillic
Watchman
Watchman


Joined: 19 Feb 2003
Posts: 7301
Location: Groton, Massachusetts USA

PostPosted: Mon Dec 19, 2005 1:47 am    Post subject: Reply with quote

Yes, I was referring to the toolchain update that Bad Penguin mentioned.

... although it has been a while since I last installed using stage3, and I normally build ~arch keyword systems anyways, so I am not familiar with the other bugs that may be in the "recommended" installation procedure.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
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