What exactly happened to stage 1? And bootstrapping?

Message

Bob P · Post by **Bob P** » Sat Nov 12, 2005 7:28 pm

Cinder6 wrote:I don't think anyone has mentioned this.

If you want to have a Stage 1 install, why not do a 3->1 install? There are tutorials on it in the Gentoo Wiki and on these forums. IMO, 3->1 is better than pure stage 1, but it takes longer.

i never thought i'd live to see the day that something as convoluted as the Stage 1/3 installation method would be considered a standard gentoo installation method.

yngwin · Post by **yngwin** » Sat Nov 12, 2005 7:51 pm

I never saw the point in stage 1 or 2. I have done many installs and getting up and running with a stage 3 is what I will always choose. You can then customize to your heart's desire and do an emerge -e world and build the system you want.

dmbtech · Post by **dmbtech** » Sat Nov 12, 2005 9:05 pm

Just a quick stupid question relating to that faq thing: if you are building from a stage 1 tarball, can you just do emerge system as opposed to emerge -e system? Because that requires me to build things and if one error comes i have to start over.

hielvc · Post by **hielvc** » Sat Nov 12, 2005 9:23 pm

You can still restart with "emerge --resume system -e" but only if you imediately run it. I dont mean time , Emerge keeps an emerge log of whats tjo be emerged. That log gets wiped the next time you ran emerge unless it sees --resume.

ciaranm · Post by **ciaranm** » Sat Nov 12, 2005 10:43 pm

Ok, since everyone so far has failed to get it...

In the really really old days, when we used stager to make stage tarballs, stage 1 was the only way to get a clean system with a correct vdb. These are no longer the really really old days, and we use catalyst rather than stager, and all stage tarballs contain a correct vdb. So, if you want the equivalent of a stage 1 install, use a stage 3 and run emerge -e world twice followed by an emerge depclean.

Same flexibility, no loss of choice, no loss of customisation, and far fewer nasty dependency bugs. This isn't about removing choice, it's about getting rid of an old hack and replacing it with a new not-very-hackish solution which is far more likely to work.

omp · Post by **omp** » Sat Nov 12, 2005 10:56 pm

I'm too lazy to read this whole thread, so I don't know if this has already been said before:

I was told that stage 1 is being taken out of the handbook because it caused a lot of confusion amongst newer users and they always had problems due to it. Anyways, you can essentially reach the same step by recompiling all of your packages after you finish a stage 3 install.

mikegpitt · Post by **mikegpitt** » Sat Nov 12, 2005 11:26 pm

Earlier in the thread people were discussing pentium-m processors with gcc-3.4.4. I jsut installed gentoo on my new laptop and did this.

- Did a stage 3 install (using the pentium3 stage)
- Upgrade to gcc-3.4.4
- emerge glibc
- emerge -e system
- revdep-rebuild
- continued on my way installing the rest of the packages I want

I don't see how I would have gained anything from using a stage1, and this was simple enough.

Cinder6 · Post by **Cinder6** » Sat Nov 12, 2005 11:29 pm

ciaranm wrote:Ok, since everyone so far has failed to get it...

In the really really old days, when we used stager to make stage tarballs, stage 1 was the only way to get a clean system with a correct vdb. These are no longer the really really old days, and we use catalyst rather than stager, and all stage tarballs contain a correct vdb. So, if you want the equivalent of a stage 1 install, use a stage 3 and run emerge -e world twice followed by an emerge depclean.

Same flexibility, no loss of choice, no loss of customisation, and far fewer nasty dependency bugs. This isn't about removing choice, it's about getting rid of an old hack and replacing it with a new not-very-hackish solution which is far more likely to work.

Thanks for the info. The only problem with doing 2x emerge -e world is that it takes quite a long time to do so on most machines (about 5 hours or so on my AMD64 3500+, maybe 4). I do understand that this makes things simpler for devs to build stages, but--again--having to emerge -e world twice still seems a bit like a kludge to me.

Oh well, won't affect this install

warrens · Post by **warrens** » Sat Nov 12, 2005 11:48 pm

I tried to do a Stage 3 install only 2 times back when 2004.3 was the latest and greatest. Both time I ended up with a broken install and had to reinstall from Stage 1 (All of my sytems are P4 machines and all cflags remained the same.). Since that experiance I have only used Stage 1 to get a working system, not trusting Stage 3. After I finish getting my server configuered I will try a Stage 1/3 install on my testing partition to check it out and if it works for me I will then move it over to my production partition.

yngwin · Post by **yngwin** » Sat Nov 12, 2005 11:58 pm

Cinder6 wrote: The only problem with doing 2x emerge -e world is that it takes quite a long time to do so on most machines

But isn't a stage 1 basically the same?

truekaiser · Post by **truekaiser** » Sun Nov 13, 2005 12:26 am

yngwin wrote:
Cinder6 wrote: The only problem with doing 2x emerge -e world is that it takes quite a long time to do so on most machines
But isn't a stage 1 basically the same?

no because most of the programs you only have to compile once
with the stage 1 on 3 is that you have to do those twice

this is strike one for gentoo, un-needed strain on the system just because they probibly got tired of people asking for help that should not be useing gentoo in the first place. i do not buy the hack explaination. depclean is a hack not the stage one, anyone who says to use depclean as a part of a installation should not be trusted, especaily when he says the other methiod is a hack.

strike two happened to me this morning. if you have a wireless interface ignore the config information for the net file in the handbook, if you do not it will result in a interface that cannot use dhcp(starts and then quits no error messege nothing)

ciaranm · Post by **ciaranm** » Sun Nov 13, 2005 12:39 am

truekaiser wrote:this is strike one for gentoo, un-needed strain on the system just because they probibly got tired of people asking for help that should not be useing gentoo in the first place. i do not buy the hack explaination. depclean is a hack not the stage one, anyone who says to use depclean as a part of a installation should not be trusted, especaily when he says the other methiod is a hack.

Oh, you don't need to trust me. You can go and read all the source code and figure it out for yourself. Of course, it'll take you a while...

Bob P · Post by **Bob P** » Sun Nov 13, 2005 12:46 am

ciaranm wrote:Oh, you don't need to trust me. You can go and read all the source code and figure it out for yourself. Of course, it'll take you a while...

hehe.

that gave me the best chuckle i've had in a while.

Bob P · Post by **Bob P** » Sun Nov 13, 2005 1:07 am

i think that you guys who are complaining about unnecessary strain on the system are probably missing some of the subtleties that go along with running / updating a source code based distribution. sure, with Mandrake or SuSE you didn't have to do this -- because somebody else has already done it for you.

if you want to use Gentoo, you've got to do the building yourself. throwing insults around just because you don't understand WHY the system has be be built the way it has to be built isn't really a good idea -- it only demonstrates a complete lack of understanding of the subtleties on your part.

Recompilation of the entire toolkit after updating a major package is not necessarily required, but it is recommended if you want your system to work. this is because the original version of your toolkit was compiled with a compiler that was inferior to and/or more bug-ridden and/or less optimized for your processor than the compiler that you're installing on your system. its absolute false economy not to rebuild/recompile it.

taking this a couple of steps farther, after every time that you rebuild a major toolkit package such as the kernel headers, glibc, gcc, binutils, or kernel, you NEED to do this:

Code: Select all

emerge -e system
emerge -e system
emerge -e world
emerge -e world

The first command rebuilds your toolkit and assures that its components are in proper order.
The second command assures that your toolkit has been compiled a toolkit that is both clean and current.
The third command recompiles all of your packages with the clean and current toolkit.
The fourth command assures that all of your packages are compiled against packages that were compiled with a clean and current toolkit.

This may seem like alot of work, but every step is absolutely necessary if you want to assure that your system is properly constructed and the world packages are completely purged of statically retained libraries. If anyone thinks that this is a waste of time, or thinks that Gentoo needs to be slammed for requiring unnecessary strain on their systems, then they just fail to understand how a compiler and toolkit have to be built, and they have absolutely no business using a source code based distribution. If that's the case, then they should either spend some time with the Linux From Scratch documentation or they should just throw in the towel and go back to a binary based distro. Either way, education in the answer.

At any rate, its not fair to slam Gentoo or the devs if the problem is based on user ignorance.

syg00 · Post by **syg00** » Sun Nov 13, 2005 1:38 am

Bob P wrote: Recompilation of the entire toolkit after updating a major package is not necessarily required, but it is recommended if you want your system to work. this is because the original version of your toolkit was compiled with a compiler that was inferior to and/or more bug-ridden and/or less optimized for your processor than the compiler that you're installing on your system. its absolute false economy not to rebuild/recompile it.

taking this a couple of steps farther, after every time that you rebuild a major toolkit package such as the kernel headers, glibc, gcc, binutils, or kernel, you NEED to do this:
Code: Select all
emerge -e system
emerge -e system
emerge -e world
emerge -e world

Well I don't like to argue these things (especially with with Bob P), but I happen to think this is a little over the top. I don't believe the tool chain I have been using for X months is that "unoptimized" that I'm going to do all this everytime. Everything will eventually get emerged and thus recompiled anyway. Toolchain always needs care, but I've never been convinced of the need to run the world -e twice.
Yes I've read the threads - and I'm still unconvinced for a "run of the mill" (read "non-ricer" if you like) Gentoo system.

Shadow Skill · Post by **Shadow Skill** » Sun Nov 13, 2005 8:20 am

Maybe I am missing something but couldn't one follow LFS' instructions then install portage on top of LFS to achieve the same effect as a stage one install? I don't buy the toolchain thing either, I might think about doing it when it becomes a command I can just issue to Portage to have it done properly, if I am going to spend hours at my machine not exavtly enjoying it I would rather try and make Udev/Ivman actually mount my damn usb drives the way I want.

Bob P · Post by **Bob P** » Sun Nov 13, 2005 2:06 pm

Oh, you don't need to trust me. You can go and read all the LFS documentation and figure it out for yourself. Of course, it'll take you a while...

Shadow Skill · Post by **Shadow Skill** » Sun Nov 13, 2005 4:45 pm

Bob P wrote:Oh, you don't need to trust me. You can go and read all the LFS documentation and figure it out for yourself. Of course, it'll take you a while...

Dude I'm actually agreeing with you that there is no real need for a stage one install.......

cokey · Post by **cokey** » Sun Nov 13, 2005 7:46 pm

Stage 1 installs are worthless. The only thing they do is allow the user to say "i've done a stage 1". On the opposite side of that you exponentially increase the risk to your system because what most people dont realise is that any inherited problem may take months to come out.

curtis119 · Post by **curtis119** » Mon Nov 14, 2005 2:03 am

OK, just for the record and for those of you who didn't bother reading the mailing list archive. Stage1 is not being deprecated. The instructions for it have simply been moved to a different location so that n00bs will have less confusion about how to install. If you really want to use a stage1 then by all means please do. No one said you couldn't. They even have a link to the stage1 instructions right in the handbook. How hard is that to figure out?

rhill · Post by **rhill** » Mon Nov 14, 2005 2:16 am

i'm sorry, but the 'rebuild your toolchain twice so it's completely optimized' line is kind of bullshit, and always has been. it was taken out of context and misapplied. if you're dealing with an under-development version of GCC or glibc then yes, it's important that the toolchain is properly rebuilt because there could be major changes in functionality from one day to the next, and those changes do need to propagate. when you're doing minor upgrades of stable versions, doing a double rebuild is a optimized waste of time.

if it's a gcc upgrade, the compiler is already built three times in the course of the emerge. for example, you have gcc-3.3.6 installed and are upgrading to 3.4.4. first gcc compiles the new version with the one currently on the system. the result is a gcc-3.4.4 compiler built with 3.3.6. this is called the stage 1 compiler. the stage 1 compiler then recompiles the sources, using -fprofile-generate to allow the compiler to gather performance information about the code it builds - execution counts and branch probablilities - and builds a "stageprofile" compiler. this "stageprofile" compiler then builds the runtime libraries, which allows the profiler to gather it's info. finally, this info is fed back into gcc, and a final "stagefeedback" compiler is built. as you can see, the final product is already well insulated from the original environment. emerging gcc again won't have an effect. emerging glibc and binutils with the new compiler and then rebuilding gcc also won't have an effect. although the final code produced by the compiler may have changed between gcc versions, the functionality of that code should not have changed. you don't change the way ld works depending on what version of gcc it was built with.

that said, it *is* important to rebuild world in the face of a jump in gcc versions. especially 3.3->3.4. 3.4->4.0 less so, but you can still run into problems if half your world is built with either.

</offtopic>

Bob P · Post by **Bob P** » Mon Nov 14, 2005 3:47 am

well, yes and no. sure the compiler rebuilds itself properly. but the toolkit is composed of more packages than just the compiler. there are plenty of packages in the system fileset that DON'T get properly recompiled unless you take one of two approaches: 1) you know exactly which ebuilds to rebuild and the order in which to rebuild them, and you take the time to rebuild them manually, or 2) you use a brute strength approach and perform a redundant emerge on the system fileset that doesn't require the time and effort at the console of manually selecting ebuilds. either method will work as long as you rebuild all of the files that need to be rebuilt.

look at programs like zlib for example. its a very important low-level static library. if you don't rebuild it after a toolkit upgrade, its going to have statically retained libraries from the previous build that reference toolkit components that no longer exist. python and perl are other prime offenders in this regard -- python hates a toolkit upgrade so much that its just plain evil.

unfortunately, there are no shortage of ebuilds in the system toolkit that are not part of glibc or gcc or the compiler section of the toolkit per se. so if you limit your toolkit rebuild to the compiler alone, you're going to get an incomplete solution to your problem -- you can have the compiler rebuild itself ad infinitum and you still won't fix the problems related to failures to recompile other components of the system fileset that need to be purged of statically retained libraries that reference the original toolkit that isn't even present any more.

statically retained libraries, missing symlinks, library errors induced by changing CHOST, etc. are all too common gentoo problems that fall into the category of mysterious gremlin-like problems that are difficult to chase down. these are the problems that most frequently frustrate gentoo users. the vast majority of them aren't caused by system bugs. the vast majority of them are caused by inexperienced users cutting corners and skipping steps in the toolkit rebuild, whether they know that they're doing it or not.

believe it or not, Gentoo is an absolutely stable system if it is built properly. IMHO the only time Gentoo becomes an unstable platform is when somebody builds the base system improperly. such problems as those i've mentioned earlier can be completely avoided by taking the right steps to avoid them. redundantly rebuilding the entire system fileset, rather than limiting your attention to rebuilding the compiler takes CPU time but not seat time, and it completely eliminates these problems that are often so difficult for less experienced users to isolate.

i'm not saying that anyone HAS to build their system one way or another. but having been around the block as many times as i have, i've figured out why Gentoo works when it works and why Gentoo doesn't work when it doesn't work. for me, Gentoo is an absolutely stable, rock-solid system that is without peer. am i just lucky? is it all just coincidence?

so far we've had alot of opinions for building the system one way or another, to keep all of the opinions expressed in context, it might be helpful to look at each user's profile and look at their post history. personally, i'm more likely to follow the advice of people who are solving problems rather than the advice of people who have been reporting problems, without regard of their postcounts. but that's just my two cents worth. YMMV.

enderandrew · Post by **enderandrew** » Mon Nov 14, 2005 4:12 am

Okay, I'm the stupid n00b end-user. I am looking at Conrad's installation guide (I've already read your take on how he stole if from you so no need to repeat said rant) and plan to build on gcc 4.0.2 or gcc 4.1

What do I need to do to make sure everything is compiled with the same gcc?

emerge world and then emerge world again?

Enlight · Post by **Enlight** » Mon Nov 14, 2005 8:40 am

Well actually, the only reason I can see to use a stage1 install is the use of special {C,AS}FLAGS slightly modifying the A.B.I. ans then needing to be used since the statical build of GCC.

As I guess few people do this and taking into account the ability to run emerge -e or simply --newuse system, allowing as much tuning as a stage2, stage3 really seems to me the way to go.

Edit : I can't get the point of rebuilding the whole world (toolchain I agree, maybe system if you find it hard to find the limits of the toolchain) twice since compilation dependencies are normally built first... maybe circular dependencies outside of the bootstrap that I'm not aware of???

cokey · Post by **cokey** » Mon Nov 14, 2005 10:30 am

enderandrew wrote:Okay, I'm the stupid n00b end-user. I am looking at Conrad's installation guide (I've already read your take on how he stole if from you so no need to repeat said rant) and plan to build on gcc 4.0.2 or gcc 4.1

What do I need to do to make sure everything is compiled with the same gcc?

emerge world and then emerge world again?

look, dont bother with GCC 4 until some more work has been done on it. It breaks packages at the minute