Trouble with RootFS package management on proot (Termux)

[knyipab]

For proot on Termux (no root, based on a trimmed Linux kernel), it's rather difficult to manage packages in RootFS. Neither chroot (due to no root) nor fusermount (seems no kernel support on Android, or root required) would work.

Lately I tried wine on FEX and installed wine 7.0 on host OS. But FEX seems to prefer RootFS files (wine-5.0 and libwine.so) over host OS files but I couldn't manage RootFS packages. Can I change its preference for host OS vs. RootFS? Or how could I manage (e.g. apt) or remove RootFS packages given chroot and fusermount not available?

I would be grateful if you may provide more details on FEX mechanism, which I couldn't find from Wiki page. Why does FEX need RootFS when Ubuntu/Debian MultiAarch is there (won't it be good to, or can I, run FEX with only MultiArch and without RootFS, just like box86/box64)? What makes RootFS different from FS from a typical distro image or chroot FS (does RootFS replaces any Ubuntu files/libs with thunklibs)?

Thanks a lot!

[artdeell]

I asked that in the discord, and one of the devs said that FEX recommends to use a RootFS because arm64/x86_64/x86 multiarch is prone to breaking, but there's nothing stopping you from not using a separate rootfs.

[Sonicadvance1]

If you can't chroot on device then package management inside of FEX's rootfs won't be possible on that device.
I'd recommend copying the rootfs to some Linux device that can do a chroot, then rsync it back on to the device.
We provide the scripts break_chroot.sh and unbreak_chroot.sh in the rootfs root for this purpose of chrooting.

There's no way to prefer rootfs versus host root to the granularity of just an application and its depedencies.
You'll either need to uninstall the wine package from the rootfs. Or update the packages inside of it to 7.0 then remove your host wine version.

Debian multiarch is prone to breaking mainly because it is an unsupported configuration to install a bunch of cross-architecture binaries in the same space as your host architecture.

Take for example uname. If an x86-64 application is querying what host the architecture using this utility application, then it will escape the x86-64 sandbox, execute the aarch64 binary, and then it's highly likely that the x86-64 application won't know what to do with a aarch64 architecture instead of x86_64.

So it's technically possible to run without a FEX rootfs with multiarch, but I don't recommend it. As far as I'm aware, box86/box64 captures a bunch of program executions just to try and work around this problem.

FEX's rootfs is modified only to move some folders and files around. Which you can see in our break_chroot.sh script here https://github.com/FEX-Emu/RootFS/blob/main/break_chroot.sh#L38

Not moving these files and folders around would break some applications being executed. We also are running new libdrm and mesa binaries. Currently our rootfs ships with Mesa 22.0-rc1, with an "everything" configuration so it works on most hardware.