[Toybox] [RFC] mkroot: Possible solution to running tests in a vacum: Use the host bash in a chroot

[Rob Landley]

On 3/20/24 12:38, Oliver Webb via Toybox wrote:
> A target for the 0.9 release is the test suite running under mkroot,

On all the architectures mkroot supports (endianness, word size, kernel
version), under qemu with a known kernel environment so we can test things like
insmod with known modules, or test ifconfig and hostname without destabilizing
my development laptop.

> Which is also required
> for passwd to be re-promoted (We need to test it in a vacuum).

Eh, I can test that manually for one release. My problem is I keep getting
distracted by tangents. The "create changelog" todo item made it as far as
commit 40e73a387329 which has a pending TODO item I tried to fix (refill toybuf
to try to span EXIF data when file is identifying JPEG files), I need to instead
WRITE THAT DOWN (and leave it unfixed for now) and continue to the end of the
list so I _have_ a current changelog and CAN cut a release... but haven't yet.

> The main downside of this is that you have to look for the dynamic libraries bash wants and
> copy them into the fs directory,

The code I wrote to do that way back when was something like:

  https://git.busybox.net/busybox/commit/?id=3a324754f88b

I.E. recursively call ldd to see what its dependencies are, repeat until you run
out of dependencies.

I _can_ make this work. It's just not the direction I wanted to go in.

 and doing a chroot requires root permissions. Also it is very
> clearly not a permanent fix (None of this is needed once toysh is ready), just enough to get
> tests for commands like passwd and chsh running. Another downside of chroot-ing is you can't
> emulate things that depend on drivers or nommu.
> 
> Attached is a mkroot package (Not a patch), that sets up a environment to run the test suite
> under a chroot in. (./mkroot/mkroot.sh testwhost && sudo chroot root/host/fs /test command_name).
> It's not something I'm actually expecting to be merged, but that doesn't mean it's not potentially
> useful for testing the commands that modify /etc/passwd and friends.

I was setting up a debootstrap to test it under, since that's presumably
isolated enough, but last time I sat down to poke at that I got distracted into
the Orange Pi 3b server setup which is the _other_ consumer of a debootstrap I
have lying around, and then I went "too much for now but I can at least do the
testing under a qemu-system-arm64 with devuan arm64 debootstrap" and hit the
fact that trying to marshall a tarball into mkroot using "wget | tar xpv" spat
out endless unexpected EOF files because the tarball autodetection logic had a
regression and the child process thinks it's the parent process.

Still have a tab open for that, trying to dig back down to fix it, been
distracted by external pokes instead.

> Also when making this I spotted some things in the build infrastructure we will need to work around
> in a airlock-ed test suite, test.sh needs configure,

Only for single builds, not for testing all of toybox.

And presumably I should add a TEST_EXISTING=1 to skip the single build and just
grab the command out of the current directory and/or $PATH. (There's always more
work to do on the test suite...)

> and portability.sh needs something for CC or
> else it will throw a fit.

I know, one of my trees has a partial patch for it, but there's some design work...

Rob