1 |
On Thu, May 21, 2020 at 4:46 AM Thomas Mueller <mueller6724@×××.com> wrote: |
2 |
> |
3 |
> > from n952162: |
4 |
> |
5 |
> > > And really unless you REALLY care about your CFLAGS you get 99% of the |
6 |
> > > benefit just sticking with the original stage3 and just rebuilding |
7 |
> > > anything you change USE flags for. Over time it will all get rebuilt |
8 |
> > > anyway using your preferences. |
9 |
> |
10 |
> > If I understand that correctly, using the stage3 tarball will give me a |
11 |
> > fully functioning system from binaries, but I can convert that in one |
12 |
> > fell swoop into sources by re-emerging everything, saving me the hassle |
13 |
> > of the bootstrap.=C2=A0 Of course, a trojan horse could be in that tarball |
14 |
> > and squirrel itself away ... but then, I'm not supporting Fort Knox, |
15 |
> > either...=C2=A0 that'll save some work ;-) |
16 |
> |
17 |
> What do you refer to by "bootstrap"? |
18 |
> |
19 |
|
20 |
He is contrasting a stage1 vs stage3 install. Anybody who has been |
21 |
around Gentoo for 15+ years is probably familiar with this but it |
22 |
hasn't been something recommended in a long time or documented in the |
23 |
handbook. I believe it used to be the recommended process. |
24 |
|
25 |
Basically a stage1 is just a tarball of a very minimal toolchain - the |
26 |
very minimum set of packages needed to build everything else and a |
27 |
shell/etc, but not enough to actually boot a system (no ssh, probably |
28 |
no init/openrc, etc). |
29 |
|
30 |
You then use that stage1 to rebuild itself, which becomes a stage2. |
31 |
That is done to clean up any CFLAGS issues associated with whatever |
32 |
built the stage1. Then stage2 is used to essentially do an emerge -e |
33 |
@system which becomes a stage3. |
34 |
|
35 |
The problem is that you end up rebuilding gcc/glibc/python/etc |
36 |
multiple times, and all this time you don't have a bootable system. |
37 |
If for some reason you have to reboot/etc it can be a real pain to |
38 |
resume something like this. This is why it was deprecated - you get |
39 |
the same benefit from just starting with a stage3 and just doing an |
40 |
emerge -e @world, and it means you can do most of your system setup |
41 |
and get your system into a state where it can be rebooted very early, |
42 |
vs having a process where you do some stuff at the start, then do some |
43 |
more a day later, and do a bit more a day later, and so on. You can |
44 |
do an emerge -e @world at anytime really if you want to rebuild |
45 |
everything and other than the load it is pretty transparent to using |
46 |
the system, and if you reboot midway you just do an emerge --resume. |
47 |
|
48 |
You can still find stage1 tarballs, because they're still generated by |
49 |
catalyst when release media is created. The stage1/stage2/stage3 |
50 |
steps are done centrally by the release media team, and then users |
51 |
just download the stage3 tarball. |
52 |
|
53 |
The full process is still used in some more exotic situations, like |
54 |
prefix, or maybe when getting Gentoo running on a new arch. |
55 |
|
56 |
Getting to the trojan horse concern - I guess anything is possible, |
57 |
but you're assuming that somebody would infect the stage3 but not the |
58 |
stage1. They're both generated at the same place and signed using the |
59 |
same keys. If you're concerned about downstream infection a simple |
60 |
gpg check eliminates that risk, and if you're concerned about |
61 |
contamination upstream from signing then you'd need to create your own |
62 |
stage1 by hand from some source you consider clean. |
63 |
|
64 |
-- |
65 |
Rich |