What exactly happened to stage 1? And bootstrapping?

yngwin · Posted: Sat Nov 12, 2005 7:51 pm Post subject:

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.
_________________
"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF

dmbtech · n00b Joined: 06 Jan 2004 Posts: 44

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 · Posted: Sat Nov 12, 2005 9:23 pm Post subject:

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.
_________________
An A-Z Index of the Linux BASH command line

ciaranm · Posted: Sat Nov 12, 2005 10:43 pm Post subject:

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 · Posted: Sat Nov 12, 2005 10:56 pm Post subject:

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.
_________________
meow.

mikegpitt · Advocate Joined: 22 May 2004 Posts: 3224

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 · l33t Joined: 05 Aug 2004 Posts: 767 Location: California

warrens · Posted: Sat Nov 12, 2005 11:48 pm Post subject:

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 · Posted: Sat Nov 12, 2005 11:58 pm Post subject:

truekaiser · l33t Joined: 05 Mar 2004 Posts: 801

ciaranm · Posted: Sun Nov 13, 2005 12:39 am Post subject:

Bob P · Posted: Sun Nov 13, 2005 12:46 am Post subject:

Bob P · Posted: Sun Nov 13, 2005 1:07 am Post subject:

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:

syg00 · Posted: Sun Nov 13, 2005 1:38 am Post subject:

Shadow Skill · Veteran Joined: 04 Dec 2004 Posts: 1023

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.
_________________
Ware wa mutekinari.
Wa ga kage waza ni kanau mono nashi.
Wa ga ichigeki wa mutekinari.

"First there was nothing, so the lord gave us light. There was still nothing, but at least you could see it."

Bob P · Posted: Sun Nov 13, 2005 2:06 pm Post subject:

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...
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks

Shadow Skill · Veteran Joined: 04 Dec 2004 Posts: 1023

cokey · Advocate Joined: 23 Apr 2004 Posts: 3355

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.
_________________
https://otw20.com/ OTW20 The new place for off the wall chat

curtis119 · Posted: Mon Nov 14, 2005 2:03 am Post subject:

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?
_________________
Gentoo: it's like wiping your ass with silk.

rhill · Posted: Mon Nov 14, 2005 2:16 am Post subject:

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>
_________________
by design, by neglect
for a fact or just for effect

Bob P · Posted: Mon Nov 14, 2005 3:47 am Post subject:

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. :twisted:

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.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks

enderandrew · l33t Joined: 25 Oct 2005 Posts: 731

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?
_________________
Nihilism makes me smile.

Enlight · Posted: Mon Nov 14, 2005 8:40 am Post subject:

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 · Advocate Joined: 23 Apr 2004 Posts: 3355