User:NeddySeagoon/Build In A Chroot

Motive
A lot of users have a desktop and a far weaker portable system these days. Installing and maintaing Gentoo on a weak system is a challenge for the impatient, so don't do it, at least, not quite by following the handbook. The author has posted bits of pieces of this page on the forums several times over the last few months. It's time it was collected together in one place.

Being lazy, I can post a link on the forums too.

Overview
A Gentoo install splits nicely into two parts Keep that in mind for later.
 * The things needed to build and maintain the install
 * The things needed to use the install.

Some examples, the ::gentoo repo, distfiles and binary packages are not required at run time. The binary files installed as a result of using the ::gentoo repo and distfiles are definitely required.

If your weaker system is storage constrained, that hint may be enough. If your weaker system is storage, RAM and CPU constrained, it's not. Read on.

First hand Experience
The author uses an AMD 5950x with 128G RAM and 32 threads to maintain a chroot for an AMD E350 system with 8G RAM and two threads. On its own, updates were taking a week to 10d days, by which time, the system was out of date again.

Examples below are from the above arrangement.

Outline
Lets call our two systems tortoise and hare. With hare being the one doing all the heavy lifting.

Hare will have a chroot that mimics the install required on tortoise. Some of the bits from hares own install can be shared with the tortoise chroot.

Information about the real CFLAGS and CPU_FLAGS_X86 required by tortoise are needed in the chroot.

Make the chroot
As root make a chroot with That location was chosen as crossdev does something similar. Fetch a stage3 and untar it to in the normal handbook way. Its probably a good idea to use a script for the rest, as it will be repeated every update.

In file
 * 1) !/bin/bash

mount -o bind /dev /usr/tortoise/dev mount -t sysfs sysfs /usr/tortoise/sys mount -t proc proc /usr/tortoise/proc
 * 1) Mount the pesudo filesystem inside /usr/tortoise

mount -t ext4 /var/cache/distfiles /usr/tortoise/var/cache/distfiles mount -t ext4 /var/db/repos/gentoo /usr/tortoise/var/db/repos/gentoo
 * 1) Share distfiles and the ::gentoo repo inside /usr/tortoise
 * 2) Note that there are in the new default locations

mount -t tmpfs tmpfs /usr/tortoise/dev/shm
 * 1) tmpfs is a very good thing

chmod 1777 /usr/tortoise/dev/shm
 * 1) and fix its permissions or build systems complain

mount -t tmpfs tmpfs /usr/tortoise/var/tmp/portage
 * 1) Put our build space in RAM too. We don't want wear out the NVMe

mount -t tmpfs tmpfs /usr/tortoise/tmp
 * 1) Likewise, tmp in RAM too.

chmod 1777 /usr/tortoise/tmp
 * 1) fix the permissions to keep users separate

mount -t devpts devpts /usr/tortoise/dev/pts -o rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
 * 1) We need devpts in the chroot or we don't have any jobs
 * 2) Its picky about permissions too

will run the script.

Enter the chroot
As per the handbook. Don't forget the preamble, is required.

If tortoise is already installed, copy over its. If not, set the chroot to suit the target tortoise, then copy it to tortoise before the install.

Tweaks to make.conf
Set  to whatever  outputs on tortoise.

Set  to the output of  from tortoise.

Add  to make.conf, or no binary packages will be saved.

Change  to suit the build host.

The world file
If tortoise is already installed, copy over its world file from to the chroot.

Hare summary so far
now reflects the install on tortoise but without any binary packages.

Build the Binary Packages
as we want binaries of everything the first time.

For updates is sufficient.

Clean Up
As normal but add to remove binary packages built by ebuilds that are no longer in the repo.

Share the Binary Packages
Not all of the methods that come to mind are used by the original author.

The ::gentoo repo is updated every 30 minutes. Users need to make their own arrangements to keep it constant across the two systems.

None of the items being shared are required at run time. The author prefers NFS as there is only one copy of all the bits.

Choose one of the following options only ...

Network File System
Requires kernel support on hare to provide the export and on tortoise to do the nfs mount.

Not the easiest to set up but it just works. Share the ::repo(s) used to build the binaries and the binaries.

The author prefers NFS as there is only one copy of all the bits.

On hare, outside of the chroot. /usr/tortoise/var/cache/binpkgs 192.168.100.0/24(no_subtree_check,no_root_squash,rw,async)
 * 1) /etc/exports: NFS file systems being exported.  See exports(5).
 * 2) Portage wants it rw!

/var/db/repos/gentoo 192.168.100.0/24(no_subtree_check,root_squash,all_squash,ro,async)
 * 1) share the repo the was used to build the above
 * 2) with the entire wired network
 * 3) No needed now but there may be other chroots later.

rsync
Copy to

Copy the ::repo(s) used for the build

scp
Copy to

Copy the ::repo(s) used for the build

Webserver
Host

Host the ::repo(s) used for the build.

Other methods
e.g. Sneakernet.

Using the Binary Packages
With the ::repos and binary packages available on/to tortoise, its the emerge command used to build or update on hare ... almost.

For local ::repos and binary packages add -K or -k. NFS mounts are considered local.

For remote ::repos, emerge --sync to update the local copy of the ::repo. Then for remote binary packages add -G or -g to the emerge command.

The uppercase K/G means usepackageonly and fail if a suitable package is not found. The lowercase k/g, means usepackage if available and build it if not.

Add  if build time dependencies are required.

What Goes Wrong
When the CPU instruction set on tortoise is a subset of hare. Nothing - it works as advertised.

When tortoise has CPU instructions that hare does not, illegal instruction exceptions will be raised (look in dmesg) and the offending job will be killed.

Its possible for hare to emit the full instruction set for tortoise but not execute it, which is mostly OK. There are two exceptions.


 * A few packages build some code then run it as a part of the build. They will fail if hare cannot execute the required instructions.


 * Some packages must be executed on hare to carry out the build process. They must run there.

In both cases the fix is per package CFLAGS and CPU_FLAGS_X86 to avoid the problems. If a toolchain package gets built for tortoise then crashes with an illegal instruction exception, picking up the pieces is a little more difficult but hare contains all the bits to fix it. As ever, its not start over, that never fixes anything in Gentoo.