| 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 |
Archives