termux.com

[eine]

https://termux.com/
Termux is an Android terminal emulator and Linux environment app that works directly with no rooting or setup required. A minimal base system is installed automatically - additional packages are available using the APT package manager.

Currently, the suggested approach to use X11 apps in termux is tigervnc: https://wiki.termux.com/wiki/Graphical_Environment

@mviereck, can x11docker be useful in this environment?

[mviereck]

can x11docker be useful in this environment?

Do you want to run docker containers on android? Is there a docker for android?
If the core dependencies are fulfilled, x11docker might run there.

Currently, the suggested approach to use X11 apps in termux is tigervnc

Another approach mentioned there is X server XSDL. I'd assume that it is more performant than a VNC setup.

If docker runs on android, an x11docker option --xsdl could be possible. Or run XSDL first, set DISPLAY, and run x11docker with --hostdisplay.
To just start an X server / XSDL, it might make more sense to extend runx.

[eine]

I don't think it is possible to run docker containers on android. Anyway, that's not my target. x11docker/runx provide multiple features to set up servers/clients to get remote X11 access. Tricks such as using xvfb and xpra might be useful as an alternative to VNC. Does it make sense?

[mviereck]

x11docker/runx provide multiple features to set up servers/clients to get remote X11 access.

x11docker or runx do not really provide remote setups. They only make it easy to run an X server. x11docker wiki describes setups how to remotely access the X server.
So runx for android could only run XSDL. The remote access itself is out of scope for runx and x11docker.
So far I don't see much use of runx (and even less of x11docker) on android.
If running XSDL needs simplification, runx could be useful. (If at all XSDL is meant to be started from a command line.)

[ericcurtin]

It is possible to run docker containers on Android (it's also available in Termux), but most stock Android kernels do not come with the relative features configured in the kernel like cgroups etc., so a recompile is normally necessary. Another option for Android is to add another backend option instead of docker, podman. Chroot works out of the box on rooted Android handsets:

https://ericcurtin.wordpress.com/2022/01/14/more-than-a-pi-alternative-aarch64-environments/

https://github.com/ericcurtin/limux

In fact I think many would appreciate this. Linux on Android works great as a desktop replacement, once you have a USB-C dock you can attach physical keyboard & mouse, HDMI monitor, etc.

[mviereck]

Thank you for the suggestion! I'll have a look how this could be done.

Basically it should be possible to use chroot instead of containers. However, yet I have close to no experience with chroot, so I have to study and try out. There is another project called udocker that basically does this (but does not provide an X display). I might find some inspiration there how to implement --backend=chroot.

Just to note, a chroot environment does provide no security at all compared to a container. One target of x11docker is to provide a sandbox-like environment which is impossible with chroot.

I've never used a smartphone and have no experience with Android.
I have a quite old smartphone that technically works but does not get updates and became unusable due to missing SSL certificates and thus a broken app store. I might try to root it.

Is there an Android VM that I could use for test runs? I once tried one for other reasons but failed to set it up, and never tried again.

Is chroot possible on non-rooted smartphones?

(To be honest, I am suspicious about smartphones at all ;-). I use a phone to phone and a computer for computer things.)

[ericcurtin]

chroot is not possible without a rooted device, but there is an alternative called proot that does not require a rooted device. Performance is not as good using proot (vs chroot), but still much faster than a Raspberry Pi 4 (at least on my mid-range Qualcomm 765, see blog post above), so still worth it.

udocker supports proot as one of it's options, good find!

Android works, because it's still a Linux kernel, albeit a modified one.

[ericcurtin]

Tested udocker unrooted (good idea, didn't know about this), it works just fine without UI once you do a:

  echo -e "nameserver 8.8.8.8\nnameserver 8.8.4.4" > /etc/resolv.conf
  echo -e "127.0.0.1 localhost" > /etc/hosts

Also a minor thing about the documentation, is assuming you are not using an x86 Android device, you should probably do this:

https://github.com/indigo-dc/udocker/pull/354/files

But because udocker on Android instructions suggest proot, there is a performance hit and I could not get UI working (not because of performance, performance is still decent unrooted). I've only successfully got UI working on rooted devices with chroot. But there's loads of options, maybe one of them works unrooted, I have never attempted any of these:

Fakechroot
runc
crun
Singularity

as suggested on the udocker page.

[mviereck]

I don't know Fakechroot yet, it might work. runc, crun and Singularity all depend on cgroups and Linux namespaces, so they won't work on Android.

[mviereck]

First success!
Just got x11docker/fvwm desktop running in proot.

Setup:

mkdir testproot
cd testproot
docker run --name fvwm x11docker/fvwm
docker export -o fvwm.tar fvwm
tar -x -f fvwm.tar
proot -r $(pwd)

### Now in proot terminal
echo -e "127.0.0.1 localhost" > /etc/hosts

# IP of my local router
echo "nameserver 192.168.179.1" > /etc/resolv.conf 

In another terminal run an X server with:

x11docker --xonly --desktop --printenv --no-auth --xoverip -I --xc=no

Get the shown DISPLAY variable, back to the proot terminal, run fvwm desktop:

DISPLAY=172.20.0.1:110 fvwm

Running xterm failed with

$ DISPLAY=172.20.0.1:110 xterm
Warning: Tried to connect to session manager, Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
xterm: Error 32, errno 2: No such file or directory
Reason: get_pty: not enough ptys

[ericcurtin]

The above error for xterm is possibly because your container does not have the correct access to /dev/pts on the Android host, this is a snippet from a script I wrote, note /dev and /dev/pts must be mounted separately:

  mkdir -p /dev/shm # chromium requires this
  mountpoint -q /dev/shm || mount -o rw,nosuid,nodev,mode=1777 -t tmpfs tmpfs /dev/shm
  mountpoint -q $mnt_dir/proc || mount -t proc proc $mnt_dir/proc
  mountpoint -q $mnt_dir/sys || mount -t sysfs sys $mnt_dir/sys
  mountpoint -q $mnt_dir/dev || mount -o bind /dev $mnt_dir/dev
  mountpoint -q $mnt_dir/dev/pts || mount -o bind /dev/pts $mnt_dir/dev/pts
  mountpoint -q $mnt_dir$TMPDIR || mount -o bind $TMPDIR $mnt_dir$TMPDIR

[mviereck]

The above error for xterm is possibly because your container does not have the correct access to /dev/pts on the Android host

I am still on a regular Debian laptop, no Android involved yet. :-)

proot provides a mount option that does not need root privileges.
I got xterm running with proot -r $(pwd) --bind=/dev .
However, sharing entire /dev goes too far, have to check what is really needed.
Sharing /dev/pts wasn't enough.

Edit:
Instead of -r PATH to define the rootfs path, proot provides option -R PATH and -S PATH that additionally do some setup like creating /etc/resolv.conv and sharing some host files and devices.
xterm worked with recommended option -S. No further setup needed except providing variable DISPLAY.

[mviereck]

Some code pieces:

• proot on github: https://github.com/proot-me/proot
• XSDL on github: https://github.com/pelya/xserver-xsdl
• Code from moby to pull a docker image without docker pull: https://raw.githubusercontent.com/moby/moby/master/contrib/download-frozen-image-v2.sh (ref.: https://devops.stackexchange.com/a/2772)
• skopeo on github: https://github.com/containers/skopeo Tool to pull and convert images

---

First test with fakechroot, but somehow it does not find executeables in PATH:

/ $ xterm
sh: xterm: not found
/ $ which xterm
/usr/bin/xterm 
/ $ ls -la /usr/bin/xterm
-rwxr-xr-x    1 1000     1000        717000 Nov 14 15:58 /usr/bin/xterm
/ $ /usr/bin/xterm
sh: /usr/bin/xterm: not found

---

Reduced setup for proot to get xterm running. (Option -S shares too much, so I'll stay with -r)

proot -r $(pwd) -b /etc/host.conf -b /etc/hosts -b /etc/nsswitch.conf  -b /etc/resolv.conf \
    -b /dev/ptmx -b /dev/pts  -b /dev/tty

[mviereck]

Recent master introduces experimental support for --backend=proot.

Run x11docker with:

x11docker --backend=proot [OPTIONS] /path/to/rootfs [COMMAND]

If COMMAND is not specified, an interactive sh session is started.

Some features like --printer, --pulseaudio, --alsa, --gpu etc. already work.
Though, it is still a lot to do for a nice integration.

---

Currently I have unexpected issues to generate a rootfs without using docker or podman. I can pull images with skopeo, but it is not easy to extract and combine the layers to a rootfs filesystem. I found tools undocker and rootfs-builder, but both have issues to fix.

The intention is to provide a rootless tool independend from docker or podman that pulls an image with the help of skopeo and creates a rootfs at ~/local/share/x11docker/ROOTFS/<image-name> where x11docker can find it.

[mviereck]

Just asking for help:
How can I add the content of a tar file to another tar file directly, i.e. without extracting to disk?

So I have a base layer tar, and to this I want to add the content of another layer tar. (Possible existing same files in the base layer tar should be overwritten.)
I do not want to extract to disk because I want to preserve file attributes like owner and group.

Edit: never mind, I found a solution with tar --concatenate -f $Baselayer $Newlayer. Was messing around with tar pipes before.

[ericcurtin]

I do the opposite kinda here (pipes always comes to mind first for me too for this type of behaviour 😄 ):

tar -xOf ../$fn --wildcards --no-anchored 'layer.tar' | tar xf -

in this script.

https://github.com/ericcurtin/limux/blob/main/limux.sh

It extracts a tarball from a tarball without an extraction to disk in-between by using stdout/stdin

[mviereck]

I've written a script image2rootfs that generates a rootfs tarball from a docker image: https://github.com/mviereck/image2rootfs
This tarball can be extracted and used for x11docker --backend=proot, some instructions are printed in terminal.

Current syntax:
image2rootfs <imagename>

It needs skopeo that should run on android, too.

By default the image is pulled from Docker hub. Alternatively the image name can be specified with the skopeo image name scheme to pull from another source (see man skopeo).

[mviereck]

Meanwhile --backend=proot is cleanly integrated in x11docker. A few issues might be left, but everything I've tested works so far.
The code changes done for this task help to integrate other special backends in future, too.

I consider to add support for --backend=systemd-nspawn, too. Though, this is of no use for Android because it does not run systemd.

---

I did some first tests with --backend=chroot, but got unexpected issues with mount --bind. Somehow mount fails without obvious reasons.
With a working --backend=proot, is there a need to support --backend=chroot, too?

---

There seems to be no XSDL for desktop linux systems. Does XSDL have command line options? Is there a useful output with e.g. XSDL --help? The website provides no documentation.

[ericcurtin]

chroot performs twice as well as proot on Android and I've yet to see a UI working with proot (but haven't tried this yet) so it has some value. But I'll try and test --backend=proot this week on android.

I have not used command line options on Android XSDL, I just start the XSDL app, then in termux (or ssh) set the following environment variables before you run the DE and it normally works:

export DISPLAY=:0 PULSE_SERVER=tcp:127.0.0.1:4713

[ericcurtin]

Out and about, but just tried an install on my unrooted Android device this is how it went, will have a peek later:

Welcome to Termux!

Community forum: https://termux.com/community
Gitter chat:     https://gitter.im/termux/termux
IRC channel:     #termux on libera.chat

Working with packages:

 * Search packages:   pkg search <query>
 * Install a package: pkg install <package>
 * Upgrade packages:  pkg upgrade

Subscribing to additional repositories:

 * Root:     pkg install root-repo
 * X11:      pkg install x11-repo

Report issues at https://termux.com/issues

~ $ curl -fsSL https://raw.githubusercontent.com/mviereck/x11docker/master/x11docker | bash -s -- --update
x11docker note: No image name specified.
  Fallback: enabling option --xonly.

hostname: invalid option -- 'I'
Try 'hostname --help' or 'hostname --usage' for more information.

x11docker ERROR: x11docker needs 'python' to parse output of 'host inspect'.
  This is needed to check ENTRYPOINT and CMD that in turn is needed to set up
  some x11docker features. To allow more features, please install 'python'
  version 2.x or 3.x

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be:
  Please report issues at https://github.com/mviereck/x11docker

sed: -e expression #1, char 16: Invalid collation character
x11docker WARNING: Could not display message on X:


main: line 504: ${FDstderr}: Bad file descriptor

x11docker ERROR: Could not find user 'u0_a193' in /etc/passwd.

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be:
  Please report issues at https://github.com/mviereck/x11docker

sed: -e expression #1, char 16: Invalid collation character
main: line 504: ${FDstderr}: Bad file descriptor

x11docker ERROR: Must run as root to install, update or remove x11docker system wide.

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be: /data/data/com.termux/files/home/.cache/x11docker/x11docker.log
  Please report issues at https://github.com/mviereck/x11docker

sed: -e expression #1, char 16: Invalid collation character
main: line 504: ${FDstderr}: Bad file descriptor
mkdir: cannot create directory ‘/tmp’: Read-only file system

x11docker ERROR: Could not create or cd to /tmp/x11docker-install.

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be: /data/data/com.termux/files/home/.cache/x11docker/x11docker.log
  Please report issues at https://github.com/mviereck/x11docker

sed: -e expression #1, char 16: Invalid collation character
main: line 504: ${FDstderr}: Bad file descriptor
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  100k  100  100k    0     0  10409      0  0:00:09  0:00:09 --:--:-- 14227
main: line 486: ${FDstderr}: Bad file descriptor
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  159k    0  159k    0     0  15708      0 --:--:--  0:00:10 --:--:-- 30097
main: line 486: ${FDstderr}: Bad file descriptor

main: line 1564: cd: /tmp/x11docker-install/x11docker-7.0.1: No such file or directory

x11docker ERROR: Could not cd to /tmp/x11docker-update/x11docker-7.0.1

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be: /data/data/com.termux/files/home/.cache/x11docker/x11docker.log
  Please report issues at https://github.com/mviereck/x11docker

sed: -e expression #1, char 16: Invalid collation character
main: line 504: ${FDstderr}: Bad file descriptor
main: line 486: ${FDstderr}: Bad file descriptor
cp: cannot stat 'x11docker': No such file or directory

x11docker ERROR: Could not copy x11docker to /usr/bin

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be: /data/data/com.termux/files/home/.cache/x11docker/x11docker.log
  Please report issues at https://github.com/mviereck/x11docker

sed: -e expression #1, char 16: Invalid collation character
main: line 504: ${FDstderr}: Bad file descriptor
chmod: cannot access '/usr/bin/x11docker': No such file or directory

x11docker ERROR: Could not set executable bit on x11docker

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be: /data/data/com.termux/files/home/.cache/x11docker/x11docker.log
  Please report issues at https://github.com/mviereck/x11docker

sed: -e expression #1, char 16: Invalid collation character
main: line 504: ${FDstderr}: Bad file descriptor
chown: cannot access '/usr/bin/x11docker': No such file or directory
main: line 504: ${FDstderr}: Bad file descriptor
main: line 486: ${FDstderr}: Bad file descriptor
main: line 1577: xdg-icon-resource: command not found
main: line 504: ${FDstderr}: Bad file descriptor
main: line 1579: xdg-icon-resource: command not found
main: line 486: ${FDstderr}: Bad file descriptor
mkdir: cannot create directory ‘/usr’: Read-only file system
main: line 486: ${FDstderr}: Bad file descriptor
main: line 1589: /usr/bin/x11docker: No such file or directory
main: line 486: ${FDstderr}: Bad file descriptor
main: line 486: ${FDstderr}: Bad file descriptor
rm: cannot remove '/tmp/x11docker-install': No such file or directory
main: line 486: ${FDstderr}: Bad file descriptor
sed: can't read /usr/share/doc/x11docker/CHANGELOG.md: No such file or directory
main: line 486: ${FDstderr}: Bad file descriptor
main: line 486: ${FDstderr}: Bad file descriptor
~ $

[mviereck]

What a mess ... :-)

There seem to be severe differences between a regular Linux and Android.

Today I have installed an Android VM to try out.
Unfortunately VirtualBox is too hungry on resources for my 12-year-old laptop, the VM is barely usable and terribly slow.
I might try another VM setup on a faster remote server.

[mviereck]

Just noted that you tried an unrooted Android. There you cannot install x11docker in the system, obviously.
Just use x11docker directly without installing it.

You can download it with:

curl -fsSL https://raw.githubusercontent.com/mviereck/x11docker/master/x11docker > x11docker

If possible, run chmod +x x11docker, so you can run it with ./x11docker [...]. If chmod fails, you can run with bash x11docker [...].

However, from further error messages I see that it won't work yet.

Edit: I did some fixes, it will run less messy now. However, I'll need to run some tests in an Android environment myself.

[mviereck]

I got a basically working setup with --backend=chroot, but it does not work well.

If I share everything that is needed to get a graphical terminal running in chroot (same as in your Limux script), it will mess up the host. Thunderbird has graphical issues and won't start again, new terminals cannot be started. Using mount -t devpts devpts "$Rootfs/dev/pts" instead of sharing /dev/pts did not help.
If I don't share, some application in chroot will fail.

I'd say chroot is just not the right tool for this job. It might work well on Android/in Limux because the Android host is far away from a regular Linux and chroot does not mess it up for that reason.

Some code for --backend=chroot is included in x11docker, but disabled yet.

---

After all, Limux already supports chroot and proot. So what could x11docker on Android add here?
Basically I only see:

• A better user setup in the proot/chroot environment matching the Android host user.
• /home could be mounted to a more useful location on Android.

Why does your proot setup in Limux does not support X? It should be enough to just set DISPLAY.
For a bit better performance you could disable compositing in Xfce window manager.

Currently I think it makes more sense to enhance Limux where desired than to adopt x11docker to Android.

[ericcurtin]

Gonna try proot soon, it's a good start. I had to unroot my device anyway as some apps were refusing to operate while my device was rooted.

I thought your suite of container images could be useful :) Since many DE's don't work well out of the box in containers.

[mviereck]

I thought your suite of container images could be useful :) Since many DE's don't work well out of the box in containers.

They are available for Limux, too, if converted to a rootfs with image2rootfs.
However, imho Xfce is already the best choice for a container. A few others like Mate, Lumina or LXQt might be of interest, maybe even enlightenment.

KDE and Gnome3, Cinnamon and others based on gnome-shell won't work ootb; the according x11docker images rely on systemd. They would need to be based on a system like alpine using another init system like openrc.
But these desktops are bloated too much to be useful on a slow device without hardware acceleration (and XSDL does not support the GPU). So it might not be worth the effort to set up another init in proot/chroot to get them running.

If you have issues with desktops in proot/chroot, I am happy to help.

---

Side note: Instead of using XSDL a setup with xpra should be possible. I am not sure if the inofficial xpra client is up to date: https://github.com/jksiezni/xpra-client

Running xpra server with X server Xvfb in the container and xpra client on android host could be an interesting setup.

However, no GPU support here, too.
An android X server with hardware acceleration would be great.

Edit: A thread on GPU acceleration in Termux: https://forum.xda-developers.com/t/guide-running-linux-on-android-with-3d-acceleration-opengl-root-required.4093343/

Currently I try some setups with virgl on Debian. It basically works, just could be more performant.
Compare: https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/256

[mviereck]

Closing due to inactivity.

As already said, I won't adopt x11docker to Android yet. maybe I'll give it another try if I have a valid Android device, maybe a fairphone.

If you need help setting up desktops in proot with Limux, I am happy to help. Most desktop issues can be fixed with a valid user setup in /etc/passwd.

[ericcurtin]

OnePlus 6's are brilliant too. They can run many Linux distros. Reasonably priced 2nd hand.