My past job was around deploying chroots (for scientific software on a clusters)

As root (unless the chroot doc specifies otherwise).
I don't know the specific details of *that* chroot, but most of the time it requires some specific access rights (e.g.: a different owner user:group) and you need root rights to set those, otherwise tar will complain that it cannot change the rights to the untarred files .


Good idea, but won't necessarily work :

- some will just call "chroot" to start the environment inside a new path name space (i.e.: the will see the content of the tar as "/usr/lib64" instead of "/opt/easychroot/Arch/usr/lib64")
that is simply a change as you mention.

- some chroot might entirely rely on environment variables, like "LD_LIBRARY_PATH" to indicate where to fetch the .so dynamic libraries (e.g.: "/opt/easychroot/Arch/lib64" instead of "/usr/lib64")

- but other my use Rpaths : search patch directly set inside an elf executable. (i.e.: the files in "/opt/easychroot/Arch/bin" are designed to search first in "/opt/easychroot/Arch/lib64". If the libraries are instead in "/media/sdcard/XXX/easychroot/Arch/lib64", the executable will miss them and default to the next search path which will lead to the Phone's own /usr/lib64, which won't contain what you need).

I'll have to check exactly how the archive work.

Usually debian works like the first case above. (it's basically a regular "/ust" debian tree, put into a different path that you "chroot" into).

Gentoo works using a mix of the other 2 solution (it's basically gentoo, but recompiled to work out of a sub-directory instead of /usr).

The best would be to head for your solution B :

Bind mounting could work.

But you could as well put a symlink :
Both should work equally well.

And both work regardless of how the Arch chroot is organised.

Yes, it is needed.
By default, the mount script ( /usr/sbin/sd-mount ) uses noexec.