Flatcar SDK: add experimental prefix builds

[t-lo]

This PR adds experimental prefix builds to the Flatcar SDK.

Prefix builds use a custom sys prefix path and emerge all binaries and runtime dependencies into that prefix.

This path can then e.g. be shipped as a portable sysext since it includes all dependencies, and has libraries at a custom path so these do not conflict with libraries on target systems.

Prefix uses a staging environment (path) featuring a full-blown development environment, and a "final" environment for installing. Staging and final need to be created using setup_prefix first, which will also create an emerge wrapper to emerge ebuilds into staging and subsequently final. The root fs in final may be used to create a distro independent, portable sysext.

See the readme at https://github.com/chewi/flatcar-distro/blob/hackathon-prefix-builds-sync-to-upstream/PREFIX.md for more information.

How to use

Prefix requires cross-boss to be available locally.
Testing was done with the latest Alpha SDK, not the nightly build SDK.
The latest development is in the hackathon-prefix-builds-sync-to-upstream branch.

git clone https://github.com/chewi/flatcar-distro.git
cd flatcar-distro
git checkout hackathon-prefix-builds-sync-to-upstream

git clone https://github.com/chewi/cross-boss

./run_sdk_container -C ghcr.io/flatcar/flatcar-sdk-all:3717.0.0 -n flatcar-sdk-prefix-3717.0.0 -t

In the SDK container, initialise a prefix, then build (for example) python into it:

# Create prefix staging and final; bootstrap staging env
# Syntax is "setup_prefix <name> <prefix-path>
./setup_prefix prefixtest /usr/local/
emerge-prefix-prefixtest-amd64-usr python

Prefixes are architecture aware; the same prefix name can be used for multiple archs

./setup_prefix --board=arm64-usr prefixtest /usr/local/
emerge-prefix-prefixtest-arm64-usr python

"Final" environments will be in __prefix__/<board>/prefixtest after the builds conclude. __prefix__/<board>/prefixtest/root contain the root FS and can be used to create sysexts.

Testing done

Built the above (see "How to use") for amd64 and arm64, created a python sysext, tested on Flatcar x86_64 and arm64 QEmu instances.

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• n/a Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

[pothos]

Thanks for working on this. To understand, what is the output of ldd /usr/local/my-stuff/usr/bin/python, for example? Are the library paths are in the binary absolute or is some ld.so.conf entry involved?

[github-actions]

Build action triggered: https://github.com/flatcar/scripts/actions/runs/6235775790

[t-lo]

Apparently things broke when I rebased this to the latest main (conflicting glibc and python eboulds). I'll close this, squash and apply a single patch in a branch directly in the scripts repo, and file a new PR.

Output of ldd:

core@localhost ~ $ ldd /usr/local/flatcar/usr/bin/awk 
        linux-vdso.so.1 (0x00007fffb67aa000)
        libreadline.so.8 => /lib64/libreadline.so.8 (0x00007f0391d14000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f0391c36000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f0391a55000)
        libtinfow.so.6 => /lib64/libtinfow.so.6 (0x00007f0391a15000)
        /usr/local/flatcar/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f0391e21000)

@pothos let's continue the discussion in the new PR, will close this one.

[pothos]

Output of ldd:

core@localhost ~ $ ldd /usr/local/flatcar/usr/bin/awk 
        linux-vdso.so.1 (0x00007fffb67aa000)
        libreadline.so.8 => /lib64/libreadline.so.8 (0x00007f0391d14000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f0391c36000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f0391a55000)
        libtinfow.so.6 => /lib64/libtinfow.so.6 (0x00007f0391a15000)
        /usr/local/flatcar/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f0391e21000

Oh, is this what you expect? It seems to use the host libraries which is wrong.

[t-lo]

@pothos It's the output of the host ldd. If I use /usr/local/flatcar/usr/bin/ldd /usr/local/flatcar/usr/bin/awk then I get

linux-vdso.so.1 (0x00007ffd0ccbf000)                                   k 
libreadline.so.8 => /usr/local/flatcar/usr/lib64/libreadline.so.8 (0x00007f1ca7184000)
libm.so.6 => /usr/local/flatcar/lib64/libm.so.6 (0x00007f1ca70a7000)
libc.so.6 => /usr/local/flatcar/lib64/libc.so.6 (0x00007f1ca6ed4000)
libtinfow.so.6 => /usr/local/flatcar/usr/lib64/libtinfow.so.6 (0x00007f1ca6e93000)
/usr/local/flatcar/lib64/ld-linux-x86-64.so.2 (0x00007f1ca728c000)