注意:

The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.

Difference between revisions of "Funtoo:Evolved Bootstrap"

From Funtoo
Jump to navigation Jump to search
Line 55: Line 55:


== Status Updates ==
== Status Updates ==
{{Note|Please note that when you follow the CLFS steps, it is not necessary to create a separate partition for your work as indicated in the CLFS docs -- just create a directory. This works fine!}}
{{Note|Please note that when you follow the CLFS steps, it is not necessary to create a separate partition for your work as indicated in the CLFS docs -- just create a directory. This works fine!}}
{{Project/UpdateList}}
{{Project/UpdateList}}



Revision as of 06:20, February 25, 2022

   Summary
The 'evolved bootstrap' is a new project to create a technology to build Funtoo Linux completely from scratch.
   People
Leads
Members
  • alex2101
  • invakid404

Contributors
   Latest Status

The Evolved Bootstrap stage1 has been validated to successfully build a stage3 using Metro. Here's full documentation that explains how to do this. This allows Funtoo to be built from scratch (from a non-Funtoo/Gentoo system) and "feed" Metro to build official stages.

10 October 2022

The 'evolved bootstrap' is a new project to create a technology to build Funtoo Linux completely from scratch. This project includes the Fchroot tool.

'From scratch' means that it should be able to build Funtoo Linux for architecture 'X' using any Linux-like environment running on architecture 'Y'.

It will function by building an initial local toolchain which will be used to cross-build an initial Funtoo environment for any architecture.

What are the Benefits?

Right now, it can be challenging to bootstrap Funtoo Linux on unsupported architectures. Many Gentoo and Funtoo packages assume a Gentoo environment, creating a chicken-and-egg problem. In addition, Portage dependencies are not always the best option for bootstrapping, as things need to be built in a very specific order and in a very controlled environment. Gentoo dependencies are designed to make sense in an already-existing Gentoo environment, but options are limited in a bootstrap environment.

The goals of the evolved bootstrap is to make the Funtoo bootstrap:

  1. Reliable -- will work consistently and predictably using a controlled process.
  2. Flexible -- will run in any Linux-like environment, and allow bootstrapping of any architecture.
  3. Hackable -- provide an easy mechanism for extending or expanding functionality with new languages and compilers.
  4. Optimized -- support the ability to build up specific parts of the toolchain using different optimized compilers.
  5. Extendable -- When desired, allow the bootstrap to be used to build hyper-customized Funtoo environments.

What are we Building?

I will give you a brief overview of the vision, and then talk more specifically about what this project will become. As far as the vision, here's the idea. Imagine you have access to a computer. It's not running Funtoo or even Gentoo, and it may even not truly be a Linux system. But there's a C compiler on the system. Now, imagine there was an easy way to build Funtoo entirely from source code -- even for a completely different CPU architecture (ARM, PowerPC) that you are currently running. No need to download a stage3 -- everything is fully bootstrapped, entirely from source code. The Funtoo system literally emerges from nothing before your eyes, rather than relying on any pre-built download from Funtoo.

That is the general vision of the bootstrap process. Specifically, what we are building is a new framework which gives us the benefits listed above (see "Benefits"), which will give us the ability to innovate much faster with the core system, and use technologies like different libc (MUSL is already a target) as well as different compilers. It just gives us a ton of low-level control and allows us to play with the core build process and associated tools independently from an already 'fully baked' Funtoo system. This may also evolve into a new way to build up the 'core system' of Funtoo in a much more controlled way, or be leveraged to create minimal container images for arbitrary architectures. The possibilities as vast, and we want this technology because it opens so many doors for the project.

Then there is a further question: what is exactly the final end product? What we will ultimately end up with is an enhancement to metatools which will autogenerate a bootstrap script for any architecture. The contents of the bootstrap script -- what it builds, and what versions -- will be defined in YAML for easy maintenance. The script will be likely written in bash or Bourne shell for maximum compatibility. So we will have an autogenned bootstrap script that will be widely compatible with a lot of different types of systems. If we want to have a new bootstrap with a newer gcc, we can update the YAML, regen the script, and then test it. So we will have a very easy-to-maintain framework to create different variations (for MUSL, different arches, different compilers) depending on what we want to do. This will be a very useful tool.

How Can I Get Involved?

Join us in the #bootstrap channel in Funtoo Discord and also see below for status updates and instructions on how to join our collaborative effort. Please note that when you follow the CLFS steps, it is not necessary to create a separate partition for your work as indicated in the CLFS docs -- just create a directory. This works fine!

Status Updates

   Note

Please note that when you follow the CLFS steps, it is not necessary to create a separate partition for your work as indicated in the CLFS docs -- just create a directory. This works fine!

2022-10-10
The Evolved Bootstrap stage1 has been validated to successfully build a stage3 using Metro. Here's full documentation that explains how to do this. This allows Funtoo to be built from scratch (from a non-Funtoo/Gentoo system) and "feed" Metro to build official stages.
2022-04-07
The "Funtoo From Scratch" ffs repository now has the ability to build arm-64bit and powerpc-64bit initial native environments, which can then be fchrooted into. See How Can I Get Involved for easy steps you can follow.
2022-02-22
Fchroot 0.2 prerelease is being tested on our shared alkaline-dev-1 server. It allows us to chroot into alternate architectures using QEMU. It now has PowerPC support as well as several other improvements.
2022-02-10
We are currently working on a community-oriented warm-up activity to get familiar with the cross-compile process using CLFS. Pnoecker is pushing through the CLFS build process while Drobbins is working on automating the build streamlining it as much as possible.
2022-02-01
Official project launch. Gekman and drobbins are leading the effort. What we are suggesting people do, who want to be involved, is to simply go to "Cross Linux From Scratch", pick a build, and follow their documentation to bootstrap by hand. As you do this, take notes! Note what little changes you need to make to get the instructions to work. Linux From Scratch is a great project. Cross Linux From Scratch is a sub-project which is not always as current as LFS but it has a cross-build toolchain as its foundation. As our own 'from scratch' project evolves, we want to also reflect the positive qualities of the LFS projects by having each bootstrap step documented in a guide. The different with the 'evolved bootstrap' project is that this effort will eventually build a Funtoo image, and it will be automated - but, we will start by just doing the manual upstream CLFS process, observing, and then I will build out a portion of metatools to autogenerate bootstrap scripts to do everything automatically. So start here: https://trac.clfs.org/wiki/read -- pick a book, and start whittling away. The last time I did a CLFS build, a few packages needed patches so they would compile with the newer version of glibc on funtoo systems. CLFS tends to trail LFS by quite a lot. If you desire to try more updated versions of packages in your CLFS build, please do, and take notes on any tweaks if any that were needed to get the new version to work.


CLFS Build Notes

  1. Add your CLFS Notes page to this list.
  2. User:Pnoecker/clfs
  3. User:Drobbins/CLFS
  4. User:Invakid404/CLFS

We are going to encourage people to document their CLFS build notes on the wiki. It's recommended you create a "userpage" at Your User Page/CLFS Notes, and then add a link to your notes in the list above this line.