Bootstrapping Gentoo the hard way (fosslinux/live-bootstrap)

[bstaletic]

This post may be more suitable for "other things gentoo" or maybe even "other things open source", but the end goal is having a working amd64 gentoo linux.

Recently I fell down somewhat of a rabbithole of compiler bootstrapping and found the fosslinux/live-bootstrap repository.
In short, the project provides a bootstrap path from hex0 to linux 4.14 and gcc 13.1.

That got me thinking what would it take to bootstrap the system I have now also starting with hex0.
Just to be clear, the idea is not to use a gentoo stage3 tarball, but build everything from source.

I see a few major differences between my amd64 and what:

• Currently, live-bootstrap only supports x86 systems, while I am on amd64. The first 10 steps of live-bootstrap are very much architecture dependent.
  
• live-bootstrap uses musl as its libc instead of gibc.
  

The libc can be solved by bootstrapping a gentoo prefix - going with the RAP option (USE=prefix).
However, that's still a prefix and not "the real thing".

Question 1: If a gentoo prefix is bootstrapped in a directory that is a separate partition, would it be bootable? I know the prefix does not come with its own kernel, but that's just one additional step and very solvable.

That would be a way to get x86 gentoo from hex0 running as the host OS. What about amd64?
I see two paths forward:

• After finishing live-bootstrap, make a cross compiler for x86_64, then cross compile the world. crossdev from a previously mentioned prefix could be useful.
  
• Implement the first 10 steps such that we end up on an amd64 path instead.
  

I feel like I am missing something, because live-bootstrap's M2-Planet has the ability to generate amd64 binaries.
I also feel like this is straying far from the purpose of this subforum.

Question 2: Has anyone here considered bootstrapping gentoo without a stage3 tarball?

[NeddySeagoon]

bstaletic,

Building a cross compiles with crossdev, doing the usual setup then cross emerging @system mostly works.

The @system set does not have fully defined dependencies as ...
a) it avoids lots of difficult to break circular dependencies
b) it is assumed to always be present.

As a result, cross emerging @system into an 'empty' target root takes several goes as portage gets the dependency order wrong.

In the days before there was an arm64 stage3, I put arm64 onto a Pi3 like that.

Something similar should be possible with a native install by defining a different install path.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[John R. Graham]

[NeddySeagoon]

John R. Graham,

[John R. Graham]

Wow! I didn't realize that was still there.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[bstaletic]

[NeddySeagoon]

bstaletic,

You really need to try Historical Gentoo, since you are set on doing it the hard way. :)

[pingtoo]

Thank you for sharing about hex0 and the fosslinux/live-bootstrap.

This is very interesting topic for me.

I wonder if there is simulator project for ARM?

[bstaletic]

NeddySeagoon,

Well, that made me chuckle. You're not wrong about me doing things the hard way.
You probably don't remember, but you've helped me get static /dev working some 8 years ago.
Static /dev was annoying at time when I'd plug a brand new MCU dev board into a USB port and then figuring out if all /dev nodes are there.
I don't remember /sys/dev being a thing back then, so either the kernel got nicer or I got more experienced.

As for Historical Gentoo, I've read the wiki page before. I had fun reading it, too. The only intimidating part would be XFree86 config.
XFree86 had its final release about the same time I had installed my first linux distro. The licensing controversy was definitely during the period where all I knew about linux is "it is rumoured to be lighter than windows".
On the other hand, man 5 XF86Config suggests big overlap with xorg.conf. That brings two thoughts to my head:

• Should be easy. I've done it a handful of times (mdev and static-dev).
  
• https://xkcd.com/963/

[NeddySeagoon]

bstaletic,

Only some names have changed :)
Otherwise, its the same.

The warning from the old days about CRT displays still applies.
Get the Horz line rate wrong and you can let the magic smoke out.
Do you still have a CRT display?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[bstaletic]

@pingtoo I have not found a similar project for arm. Look at live-bootstrap forks, there might be some hidden gems there.

@NeddySeagoon
Wait, what warning about Hz and CRTs? Last CRT I had was back in elementary school, I think.

I do have a microwave oven. Maybe I could solder an HDMI cable to whatever generates the microwaves and configure XFree86 for that?

[Hu]

Some CRT monitors (maybe all, I don't know) were reported to lack any sort of hardware/firmware safety on input validation, so a misconfigured PC could instruct the monitor to use impossible operational parameters, and rather than blank out or use the safest approximation, the monitor would do its best to comply with the invalid settings, even when that would destroy the hardware.

You may have seen reports that one of the recent Apple devices has a similar omission in its sound hardware. Playing the wrong type of sound will cause its speakers to heat themselves to death. Asahi Linux has been very cautious in introducing audio support on that platform because of the potential to destroy hardware if the software makes a mistake.

The same problem applies to old CRT monitors, except that on those, there is no software level safety to protect you if you make a major mistake. Hence, use caution unless you are sure your monitor will gracefully reject impossible requests.

[NeddySeagoon]

bstaletic,

CRT displays used to have the final anode (EHT) voltage derived from the line scan.
The line frequency is one of the knobs you define to configure X.

Too high a number could result in too high an EHT voltage.
As Hu says, there was no protection to start with.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[sam_]

I believe some of the people in #bootstrappable on libera.chat have used live-bootstrap to build a stage3 and have script(s) for it. See https://mid-kid.root.sx/git/mid-kid/bootstrap/src/branch/master/gentoo-2024.8

I have more thoughts on this overall but I'm a bit too tired to write them up today.

[bstaletic]

A small update on this adventure:

Since this commit I am unable to fetch all sources with live-bootstrap's download-sources.sh, nor compile step 109.
Going back to before the problematic commit made live-bootstrap successfully finish. Now I have a machine with CHOST=i386-linux-musl

Now it's time to get gentoo tooling to work, so I can eventually compile amd64.

Gentoo's bootstrap.sh seems to assume portage is installed already. It first failed when it didn't detect /etc/portage/make.profile and then when portageq was not found in $PATH.
I see that portageq relies on the emerge python module and and bootstrap.sh directly invokes emerge.

I guess I will have to manually build/install portage, as if with USE=build before being able to run bootstrap.sh?

[NeddySeagoon]

bstaletic,

Before you get too deeply into bootstrapping, read Reflections on Trusting Trust and Ken Thompsons original paper, linked from the first paragraph.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[stikonas]