This is me documenting an ARMLFS system rebuild, while at the same time doing so.

Parts of this will surely be helpful for setting up a build system just for "partial" updates (want a new package or two?) too.

Some context

We're running on a 64-bit ARM VPS - your host should atleast be an aarch64 device, with plenty of RAM (20GB was allocated during the build run) and some free disk space (like, 100 GB if you still need to download all the sources, maybe 50GB free before building.) I've ran the build executive both on top of Arch-ARM and Ubuntu, so the host OS should be kinda flexible (YMMV tho).

Obviously, if you just want to build some small packages, and want to wing it on your own, ignore that if you like (like, I guess an ARMv7 board could run the build executive, and build most things (except nodejs, firefox, qt5-webengine.. maybe some other things I forgot).

The build executive

The build executive is a "server version" of ARMLFS, just for container use.

The tarball contains:

• directory "armlfs" (this is the root fs of the executive)
• armlfs.sh (to systemd-nspawn the executive)
• armlfs-launch.service (optional and needs personalization, to automatically run armlfs.sh on boot)

The tarball.

Note: the build executive is also a debuginfod server (at port 8002). It also spawns sshd on port 2204 - you will need to add your own authorized keys into it if you want to use ssh into it.

$ cd ~/my-suitable-place
$ wget https://armlfs.urja.dev/dist/armlfs-build-exec.tar.zst
$ sudo tar xvf armlfs-build-exec.tar.zst
$ # You really should take a look at scripts you've downloaded before you run them ;)
$ # Also, I run armlfs in a screen session usually... so launch that at this point, if not already doing so.
$ ./armlfs.sh

Login as root (or as builder and "su -" to root).

Get all the repos

Well, first you need a repo to tell you what repos to get ;) I decided that this repo shall be at /sources/repo-mgmt.

# cd /sources
# git clone https://armlfs.urja.dev/git/sources/repo-mgmt.git

Then, we have a script available to (kinda recursively) clone all of the repos.

# cd repo-mgmt
# ./clone-gits.sh

There's about 1327 or something like that repos, so while we're cloning, I'll tell you something about the repos.

There's a handful of repos cloned at /sources/reponame, those are listed in a textfile in the repo-mgmt repo (it does not list itself, to avoid... awkwardness.).

The git repositories for the repo-pkgbuilds directories only contain the awkward build scripts for said repo, plus a file named "order" that (unsurprisingly) contains the order we want the packages built (plus a flag if we want to do a special kind of build - used for breaking dependency loops).

Anyways, the clone-gits.sh script uses the order-file to determine what repos we want to clone in said repo-pkgbuilds directory.

The bootstrapper

Now, I want to end up with all packages rebuilt, with the minimal amount of influence from the previous set of packages in the new set.

Packages in the core repo are built with the "bootstrapper", with the concept that the packages that are installed in the bootstrapper tree/container are replaced with the built versions as we progress through the build process.

Also of note, not every package in core is needed for a bootstrap, so we start bootstrapper off with a minimal set of packages, defined by the meta-package in core named bootstrap.

If you just want to rebuild/adjust/add one package from/to core, going through the whole bootstrap process might be overkill. Thus there's a tarball of the bootstrapper.

For the purpose of assembling a build "system" (just a rootfs tree) from the package repos, there's a set of scripts in /sources/mk-builders.

There's also script there to make a build executive (that we just downloaded, to avoid a cyclical dependency on needing a build executive to make a build executive, lol) (make-exec.sh).

But now we need a bootstrapper, so make-bootstrapper.sh it is.

Note: make-bootstrapper uses /etc/makepkg.conf from the build-exec as the makepkg.conf for the bootstrapper. This is the moment to edit the initial makepkg.conf (adjust CFLAGS, PACKAGER, etc.)

Also of note: make-boostrapper needs the [core] repo in /etc/pacman.conf to be functional. The shipped version expects you to already have binary package trees under /sources - so you'll need to adjust the repos for only [core] from https://armlfs.urja.dev/pkg/armv7h/core. (FIXME: Adjust this?)

# cd /sources/mk-builders
# ./make-bootstrapper.sh

Rebuilding the core packages

In order to (re)build the core packages, you will need to have the sources pre-downloaded, by default into /sources/archives/core.

I can NFS mount the web server, so I've done that, but i assume you could download them with a recursive wget from https://armlfs.urja.dev/archives/core. TODO: Maybe add an rsync interface for people to download bulk items?

This is how to enter the bootstrapper:

# cd /sources/core-pkgbuilds
# ./bs-spawn.sh

And this is how to build all of them, in order.

# ./bsbot.py order

In case the build fails mid-way write a new partial order-file (cp order partial-order; nano partial-order) and use that. The bootstrapper environment does not start with nano, so I find it easier to just exit it for the edits (or use a different shell).

Create the (initial) build environment (for base (and kde5))

(Note: exit from the bootstapper first.) We think the pkg' we built are good, and we have no previous core set to avoid clobbering:

# cd /sources/pkg/armv7h
# mv bootstrap core

And run the script to make the (initial) /build-core.

# cd /sources/mk-builders
# ./make-builder.sh

Some background info on 64-bit ARMLFS

We need a 64-bit (aarch64) build environment to 1. build the cross-gcc that's used as-if-native in the 32-bit environment (but can use >4GB RAM). 2. be a 64-bit host for cross-compiling firefox (because doing the above was not easy for firefox).

Initially, that 64-bit build environment was a version of Arch-ARM aarch64 from 2024/04, but then a firefox update happened that needed an update to nss. At that point I realized that I need to be able to update the 64-bit build-host in sync with ARMLFS, ergo it would be best if the 64-bit environment is ARMLFS.

Thus i used the 64-bit Arch-ARM (from a set of packages roughly equivalent to ARMLFS bootstrap) to build the core set, and then repeated the process 3 times.

The first result was very messy - those binaries were linked to some libraries that are not part of ARMLFS core. For build 2 i extracted said libraries (but only the runtime .so) into the environment. The second result seemed okay, but to be sure I used it to build the core set a third time.

(Note: this was not the process used to create 32-bit ARMLFS. 32-bit ARMLFS was initially built following the Linux From Scratch book, from a Debian 12 armhf "host").

So, that's why there is a 64-bit ARMLFS that's used only in the server/build context (and we only build core and a part of base for it.).

That said, if there's a 64-bit device that would really benefit from ARMLFS, and the desire to support it, it does mean we could expand the 64-bit build.

Create the environment for 64-bit builds

This one follows basically the same path we just went through, except for aarch64.

# cd /sources/mk-builders
# ./make-bootstrap64.sh

Adjust the makepkg conf in the 64-bit builder at /bootstrap64/etc/makepkg.conf. Notably, SRCDEST needs to be set, IIRC.

bs-spawn64.sh enters the 64-bit bootstrapper.

# cd /sources/core-pkgbuilds
# ./bs-spawn64.sh
# ./bsbot.py order
# exit

Similar to armv7h, move the built packages to core.

# cd /sources/pkg/aarch64
# mv bootstrap core

Note: there are some arch/fpu CFLAGS (passed to clang & rust) in the wrappers in bc64-usr-a32/. Check & adjust if necessary.

# cd /sources/mk-builders
# CARCH=aarch64 ./make-builder.sh

Build the 64-bit to 32-bit cross-gcc

The 64-bit build-env is used by some packages (currently firefox,js115) as a cross-compilation "host", because it's easier to set up cross-compilation with clang & rust than to "sneak in" a 64-bit clang & rust (as if they were native compilers) into the 32-bit environment.

OTOH, with gcc, the sneaking in a 64-bit compiler into a 32-bit environment works very nicely, so we're going to build that and add it both to the 64-bit and 32-bit build environments.

The 64-bit build env also works nicely as the environment in which to build this cross-gcc.

Read these scripts beforehand, and note that gcc.sh in particular has some arch cflags. Be sure to run the binutils and gcc builds in the environment entered with bc64.sh. Otherwise you're just building a native 32-bit gcc, whoops.

# cd /sources/cross-a64
# ./bc64.sh
# ./prep.sh
# ./binutils.sh
# ./gcc.sh
# ./inject-to-buildhost.sh

Build the base packages

At this point the build environments are ready to start building the base set of packages. There will be a couple of additions later (grep will be built with pcre2 support, and elfutils will be rebuilt with debuginfod support, come to mind).

There's a pseudo-package armlfs-update-builder that does a pacman -Su in the buildcore (in non-volatile "mode"), ran right before llvm in the order list, to deal with those - this is so that building any specific normal package will not poke the buildcore, but running the full order build will do the update.

Since you're going to want to have as much disk space as possible available, now is a good moment to clean up some build artifacts that were left behind:

# rm -r /sources/cross-a64/bld

Be careful with typing this one (maybe replace rm -r with echo first).

# rm -r /sources/core-pkgbuilds/*/{src,pkg}

For me, these two things were about 24 GB (combined).

The base (and kde5) build systems do normally cleanup after themselves (unlike core), so from this point onwards there shouldnt be that many things to cleanup, unless something fails and is interrupted.

Now onto building the base packages. Before starting the build, you should adjust /etc/pacman.conf in the build executive to point to the local repos (file:///sources/...) for base and core and do a pacman -Syy. The build system uses the executive as the pacman sync database for the builder (as the builder is volatile).

Note: the 64-bit builder uses its own package database (and the executive uses systemd-nspawn to pacman -Sy it.) You will need to build the first 505 packages (everything before firefox) also for the 64-bit environment, so it's upto you to decide which ones to build first, but here's the commands.

64-bit:

# cd /sources/base-pkgbuilds
# CARCH=aarch64 ./build-in-order.py order64

32-bit:

# cd /sources/base-pkgbuilds
# ./build-in-order.py order

As with core, if the process is interrupted, you'll need to make up your own partial order-file for "the rest".

Building single packages can be done with ./mpkg.sh <pkgdir> (CARCH=aarch64 ./mpkg.sh <pkgdir> for 64-bit).

Build the KDE5 packages

The kde5 set is built in a similar fashion to base. You will need to initialize a repo at /sources/pkg/armv7h/kde5 (eg. repo-add and repo-remove iana-etc or smth to it), and add it to /etc/pacman.conf.

# cd /sources/kde5-pkgbuilds
# ./build-in-order.py order

Partial builds

If you're just doing a partial build (or want to add a package), you will need the build-executive, the repos and:

• bootstrapper if the package is in core.
• builder for most of base or kde5.
• 64-bit build env for firefox or js115 (or aarch64, that is updates to the 64-bit build env itself).
• bootstrap64 if the package is in core for aarch64 (core updates to the 64-bit build env).

Thus I have tarballs of the various builders, linked above, to make partial builds easier.