Implementing QEMU

[SDRausty]

EDIT: This command setupTermuxArch q[emu] [customdir] supersedes the struck out notes below. The command setupTermuxArch h[elp] provides help information.

QEMU has along with other features been implemented for years. Unfortunately, it is still under documented and still awaiting full implementation. There are two implied references to QEMU in the help; setupTermuxArch h:

>[./path/systemimage.tar.gz [customdir]] Install directory argument is optional. Network install can be substituted by copying systemimage.tar.gz and systemimage.tar.gz.md5 files with 'setupTermuxArch ./[path/]systemimage.tar.gz' and 'setupTermuxArch /absolutepath/systemimage.tar.gz'.
> [systemimage.tar.gz [customdir]] Install directory argument is optional. Network install can be substituted by copying systemimage.tar.gz and systemimage.tar.gz.md5 files with 'setupTermuxArch systemimage.tar.gz'.`

The next steps should be obvious:
1) find system image of desired architecture,
2) download image,
3) use one of the copy image commands.

These next steps might not be so obvious to all.
Especially the newcomer, what is QEMU?

QEMU is a generic and open source machine emulator and virtualizer.

What does that mean might be a question? Don't worry read on. The answer is obvious. Install QEMU in Termux to activate this feature:

[u0_a9112:01TermuxArch]$ pkg list-available |f qemu                                                                                                         
WARNING: apt does not have a stable CLI interface. 
Use with caution in scripts.                                                                                                                                                           
933:qemu-common/stable 1:4.2.1 arm                                            
934:qemu-system-aarch64-headless/stable 1:4.2.1 arm
935:qemu-system-arm-headless/stable 1:4.2.1 arm
936:qemu-system-i386-headless/stable 1:4.2.1 arm                              
937:qemu-system-riscv32-headless/stable 1:4.2.1 arm
938:qemu-system-riscv64-headless/stable 1:4.2.1 arm                           
939:qemu-system-x86_64-headless/stable 1:4.2.1 arm                            
940:qemu-user-aarch64/stable 1:4.2.1 arm                                      
941:qemu-user-arm/stable 1:4.2.1 arm
942:qemu-user-i386/stable 1:4.2.1 arm                                        
943:qemu-user-riscv32/stable 1:4.2.1 arm                                      
944:qemu-user-riscv64/stable 1:4.2.1 arm                                      
945:qemu-user-x86_64/stable 1:4.2.1 arm
946:qemu-utils/stable 1:4.2.1 arm

You can also attempt to build these qemu packages with the yay command. The last step might seem confusing. I think it is because the step is overly simple.

$ wc -l ~/arch/var/binds/fbindexample.prs
11
$ cat ~/arch/var/binds/fbindexample.prs

So I will not waste space here other than to say that using command setupTermuxArch re after reading file (wc -w 128) fbindexample.prs should open up any architecture you choose to install in your smartphone, smatTV, tablet and wearable. Once this issue is resolved the TermuxArch end user will not even know about this step, unless they chose to explore the TermuxArch code.

I would also like to add that command setupTermuxArch b can help with more than just with this issue here:

j=0 ; for i in $(wc -l ~/TermuxArchBloom/*|cut -d"/" -f 1|head -n 11);do j="$(($i + $j))" ; done ; echo $j ; unset i j
5330
j=0;for i in $(wc -w ~/TermuxArchBloom/*|cut -d"/" -f 1|head -n 11);do j="$(($i + $j))";done;echo $j ;unset i j
31341

This is the entire data set presented for your review. One tap QEMU is still a couple of steps away as of today. Comments regarding the data set are welcome here, especially how to implement one tap option QEMU easily. The goal of the data set is more robustness with fewer lines if possible. Human legibility of the code is paramount, along with execution speed and the end user experience.

[SDRausty]

If your target install system is aarch64/arm64 then this line of code CPUABI="$(getprop ro.product.cpu.abi)" should be changed to CPUABI="arm64-v8a".

Lines 596 through 600 in file setupTermuxArch have more information about how to manually choose the correct architecture for this Planned implementation of the QEMU automatation which is still currently an absent option:

# Used for development; The command 'getprop ro.product.cpu.abi' can be used to ascertain the device architecture. Matching an alternate CPUABI* will install an alternate architecture on device. The original device architecture must be changed to something else so it does not match. This is usefull with QEMU to install alternate architectures on device.

declare CPUABI5="armeabi"	# Used for development;  The command 'getprop ro.product.cpu.abi' can be used to ascertain the device architecture.  Matching an alternate CPUABI* will install an alternate architecture on device.  The original device architecture must be changed to something else so it does not match.  This is usefull with QEMU to install alternate architectures on device.
declare CPUABI7="armeabi-v7a"	# used for development
declare CPUABI8="arm64-v8a"	# used for development
declare CPUABIX86="x86"		# used for development
declare CPUABIX86_64="x86_64"	# used for development

[SDRausty]

$ f ro.product.cpu.abi setupTermuxArch

634:CPUABI="$(getprop ro.product.cpu.abi)" && SYSVER="$(getprop ro.build.version.release)" && NASVER="$(getprop net.bt.name ) $SYSVER" || _PSGI1ESTRING_ "CPUABI setupTermuxArch ${0##*/}"

Change $(getprop ro.product.cpu.abi) to one of the five architectures that are mentioned above to install this architecture.

[JanuszChmiel]

Mr Rausty,

I would like to warn you for very important Qemu issue. It is speed of The executed code. Because Android devices can not be rooted simply. As A result, normal user have no chance to patch his used Android kernel with Kqemu kernel module. Because to be honet, Qemu which execute complex code is only usable if it is accelerated with Kqemu kernel module. As A result, Fedora support wonderful virt-manager which uses Qemu in conjunction with Kqemu. There is even An attempt to allow users of Termux to boot whole Linux distro no in userspace mode as Proot technique allows.
https://github.com/xeffyr/alpine-term

It is even possible to run various Linux distros by using this technique. But The execution speed is very slow even on Octa core CPUS with ANdroid 8.0 and with 4 GB of RAM.

Proot still offer The best execution speed when comparing with Qemu which do not use Kqemu kernel module for its accelerated running. Kqemu requires hardware virtualisation to be available on A ARM CPU. The question is, if cheap ARM cpus even contain hardware virtualisation when CPU is being manufactured in The factory.

I have tried Alpine with Termux which run by using Qemu. It runs, but because Qemu emulates CPu hardware, it cost many penalties.

Yours idea is goodly thinked, but speed wwill be very probably The limitation factor.

[SDRausty]

Simply by opening this topic the goal is much closer, and should be easier to obtain. Do you agree?

speed will be very probably the limitation factor.

I cannot but agree from what I know of the subject of QEMU. However there is even a bitter bigger limiting factor than the one we are dwelling on here right now! This is being able to install an alternate architecture in a smartphone easily with one tap only! Do you agree with this point of view dear Mr @JanuszChmiel?

[SDRausty]

regarding the data set:

Option setupTermuxArch o displays part of the data set at present. May I get a little help with naming the option name for this new feature please?

This short piece of code literally tapped itself into place before my eyes earlier in the afternoon today:

printf "\e[1;32m%s \e[0m" "$(tr -d '\n' < $0)"
# split the string
IFS=';' read -ra my_array <<< "$(tr -d '\n' < $0)"
# print the split string
for EMSTRING in "${my_array[@]}" ; do printf "\e[0;32m%s" "$EMSTRING" && sleep 0.0"$(shuf -i 0-999 -n 1)" ; done

This short piece of code literally tapped itself into place before my eyes in what seemed like a few short minutes as I was, you could say, mussing. I was taking a break from thinking about how to resolve this QEMU one tap automation topic, and tapping my smartphone screen while meditating about this issue.

This is much too much code to leave for amusement in the setup file. It should migrate to one of the axillary files, and soon will be moved. File espritfunctions.bash seems like a valid recipient for the Matrix enhancement function where it will have some room to develop like this newly forked TermuxArch repository did 7 years ago:

Just a bash script; duplicates the effect of the matrix in a terminal; uses katakana Japanese characters

This presentation can be a good entry point for the future coder who might be code phobic today. What option should this presentation receive? The present option setupTermuxArch o[ption] can be expanded into a full data set presentation in Matrix format in the cli screen:

@JanuszChmiel thank you for coming up with a very nice name for the Orca project we are working on for long months now. The name orcaconfig that you suggested today is a good name for what the user wants to do.

Name suggestions for the TermuxArch Matrix option are requested. When free time is found please share your thoughs here. The o option should remain open for future development.

The matrix option can be accessed with this setupTermuxArch mat[rix] command.

[JanuszChmiel]

Yes I fully agree with you in this point of wiev. The next true is that if Qemu is being used not to boot whole Linux distro with whole kernel, that there is not too much instructions to execute and Qemu can be good alternative.

[JanuszChmiel]

I had a big dream. Run Wine for X86 on Aarch64 platform and run my favourite audio games for visually impaired by using Linux on Android device by using Proot. Unfortunately, The most .exe apps have been compiled for X86 or for X64. There is no free simple converter, which could simply convert machine code from one platform to another. Play those games on A phone instead of a standard IBM/PC compatible machine would be very exciting idea. BUt I know, that Qemu would be very probably too slow to allow this. The next important question is, if build Wine pulseaudio sound support would be compatible with used approach, that TCP protocol is being used to stream sound packets to Pulseaudio server which run in Termux not on a real Linux distro such as Arch Linux. But it would be very interesting experiment.

[SDRausty]

run my favourite audio games for visually impaired

Can you share with us please what these games are? And are they available at GitHub?

[JanuszChmiel]

I love one really unique audio games for visually impaired. Its name is topspeed. It is written by using Visual C++. It uses 3d sound to simulate real car race. You can hear cars around you, when you want to run fater than The car infront of you, you can hear The sound of The slower car. User must turn right, left, Cars can run to various ways. The source on Github is here. https://github.com/PlayingintheDark/TopSpeed But I must warn you that simply recoding this complex C source to be compatible with Linux compiler will not be easily possible. I love also other game, which is compiled by using special game engine for audio games development. It require X86 environment and Wine emulator. Topspeed also require WIndows emulator. I AM afraid, that Wine will not support to use Topspeed, since it uses many dlls from Microsoft corporation which is copyright problem. Microsoft directX to generate sound, and Microsoft Visual C++ redistributable. Here is other excellent audio game for us. It is Tube simulator from London. http://www.ndadamson.com/get-tubesim-portable.php

[SDRausty]

This 7eb1440#diff-147d3dac5c5d3cacbd74a5925f7ef3cfR522 commit adds basic QEMU support for TermuxArch. To access this new future you can use this command setupTermuxArch q[emu] [customdir]. The command setupTermuxArch h[elp] provides help information.

This command still does not support installing QEMU which must be installed manually. If installing x86_64 on a 64-bit arm smartphone, this is a recommended QEMU package configuration:

qemu-user-x86_64/stable,now 1:4.2.1 aarch64 [installed]

$ pkg list-a|f qemu                                               
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.  
936:qemu-common/stable 1:4.2.1 aarch64                                           
937:qemu-system-aarch64-headless/stable 1:4.2.1 aarch64
938:qemu-system-arm-headless/stable 1:4.2.1 aarch64                              
939:qemu-system-i386-headless/stable 1:4.2.1 aarch64
940:qemu-system-riscv32-headless/stable 1:4.2.1 aarch64
941:qemu-system-riscv64-headless/stable 1:4.2.1 aarch64
942:qemu-system-x86_64-headless/stable 1:4.2.1 aarch64
943:qemu-user-aarch64/stable 1:4.2.1 aarch64
944:qemu-user-arm/stable 1:4.2.1 aarch64
945:qemu-user-i386/stable 1:4.2.1 aarch64                                        
946:qemu-user-riscv32/stable 1:4.2.1 aarch64                                     
947:qemu-user-riscv64/stable 1:4.2.1 aarch64                                     
948:qemu-user-x86_64/stable,now 1:4.2.1 aarch64 [installed]                      
949:qemu-utils/stable 1:4.2.1 aarch64

A proot qemu bind should also be created. File /var/binds/fbindexample.prs has information how dynamically create proot binds in TermuxArch.

[SDRausty]

To use this new feature which is currently being developed:
1) Install qemu for the target architecture,
2) Choose option setupTermuxArch q[emu] [customdir],
3) Create a qemu bind in directory /var/binds/.
File /var/binds/fbindexample.prs has more information...

[JanuszChmiel]

Oh. And will be possible to run some X86 apps while working with AARch64 CPU? It would be excellent.

[SDRausty]

It would be excellent.

It appears that this issue is down to three simpler steps now. This is still a long way away from a one tap any architecture chosen install if possible. The install steps are outlined here;

1. Install qemu for the target architecture,
2. Choose option setupTermuxArch q[emu] [customdir],

3. Create a qemu bind in directory /var/binds/. File /var/binds/fbindexample.prs has more information...

I am glad to see that this issue has made a little headway.

[SDRausty]

possible to run some X86 apps while working with aarch64

This error /usr/bin/env: Invalid ELF image for this architecture happens on aarch64 when x86 is chosen:

Setting mode to qemu.  This feature is being developed.
Please install one of the qemu tools from this list in a new session if not already installed before continuing:
qemu-user-aarch64/stable 1:4.2.1 aarch64
qemu-user-arm/stable 1:4.2.1 aarch64
qemu-user-i386/stable,now 1:4.2.1 aarch64 [installed]
qemu-user-riscv32/stable 1:4.2.1 aarch64
qemu-user-riscv64/stable 1:4.2.1 aarch64
qemu-user-x86_64/stable,now 1:4.2.1 aarch64 [installed]
Please select the architecture by number from this list:
1) armeabi
2) armeabi-v7a
3) arm64-v8a
4) x86
5) x86_64

[SDRausty]

possible to run some X86 apps while working with aarch64

It appears like it is possible to achieve this goal since this 77751cb commit. The command ./setupTermuxArch qemu install i386 will attempt to install and configure an x86 installation in an ~/i386 alternate directory after choosing option 4) x86 @JanuszChmiel. There are still a few rough edges in the configuration sections which deserve honing.

[SDRausty]

speed will be very probably The limitation factor.

Speed can be benchmarked with this script. The current limiting factor is the different configurations which the different architectures have @JanuszChmiel. Have you had any success with alternate architectures on your smartphone?

Notes about reinstalling for testing, this command setupTermuxArch i customdir can be called to assist in the task of testing the install process:

[i[nstall] [customdir]] Install Arch Linux in a custom directory. Instructions: Install in userspace. The HOME directory is appended to the installation directory. To install Arch Linux in HOME/customdir use 'bash setupTermuxArch install customdir'. In the BASH shell you can use './setupTermuxArch install customdir'. All options can be abbreviated to one, two and three letters. Hence './setupTermuxArch install customdir' can be run as 'setupTermuxArch i customdir' in BASH.

The newly implemented command setupTermuxArch q i customdir can also be summond to help resolve this issue:

[q[emu] [customdir]] Partial Implementation: Install alternate architecture on smartphone with QEMU.

The command setupTermuxArch h has more information. If space is not an issue on smartphone it may be possible to run all the possible architectures for testing this issue.

[SDRausty]

Please see proot info: vpid 1: terminated with signal 11 #141 regarding why this issue is reopened.

This error continues only to occur on armv7l architecture; aarch64 qemu-user-i386 and qemu-user-x86_64 architecture packages work as expected.

[github-actions]

Stale issue message

[SDRausty]

run my favourite audio games for visually impaired

I would like to share the latest 'audio games' milestone with you here in this issue @JanuszChmiel:

user05:20~$ yay ghcup-hs
1 aur/ghcup-hs-bin 0.1.17.4-3 (+10 0.04)
an installer for the general purpose language Haskell

---

GHCup-hs works flawlessly in TermuxArch; THANK YOU! Did you know that Haskell can play music from code? Tap here to see video search results.

output.mp4

Link to this sample of Haskell music source code.

Can anybody else who uses Termux please try it? I would like to hear your opinion about the way Haskell makes music from code in Termux please.

Originally posted by @SDRausty in termux/termux-packages#8758 (comment)

[JanuszChmiel]

I have spent some time to found AN reliable and possible way to run X86 Windows apps. It is possible thanks to https://github.com/ptitSeb/box86 But project must be run under Linux distribution which is ARM32 Bit, not AArch64 Bit one. And unfortunately, Termux do not allow users to choose which architecture user would want to use. It simply automatically download bootstrap files according To the automatically detected CPU architecture. It is not A problem if user do not want to run box86. Next problém is, that it is necessary to obtain X86 Windows prefix, Wine Windows files which mmust be X86. So my dream would be too complex to reach for now.

[SDRausty]

I would like to hear your opinion about the way Haskell makes music from code in Termux please.

[SDRausty]

under Linux distribution which is ARM32 Bit, not AArch64

I am checking the availability of box86 in Arch Linux 32 with the option that we have developed here in this issue; Have you tried box86 in Arch Linux32?

[SDRausty]

too complex to reach for now

availability of box86 in Arch Linux

Arch Linux aarch64 yay box86 result:

user08:08~$ yay box86
2 aur/box86 0.2.4-2 (+2 0.01)
    Linux Userspace x86 Emulator with a twist
1 aur/box86-git v0.2.4.r22.g4813a35e-1 (+3 0.01)
    Linux Userspace x86 Emulator with a twist

QEMU Arch Linux system emulation might not be neccessary to run box86 on our Android smartphones.

[JanuszChmiel]

Yes I will try it but I must remove older Termux and I must upgrade to 118 version. I had issues with makeyay script and I did not set user password for janusz so I could not use Sudo which makeyay script call. So I must reinstall Whole Termux and ArchLinux but I will 100 % try yay ghcup-hs command and I will try Haskel and its play sound feature. I believe, that it will support Pulseaudio for Termux.

[SDRausty]

did not set user password

Since Termux is a one app and one user environment with the same permission scheme, does it make any sense to use passwords once a Termux session is opened?

[SDRausty]

Can anybody else who uses Termux please try it?

Yes I will try it

I have made an new issue Run my favourite audio games for visually impaired #68 for in depth discussion regarding creating music with Haskell in TermuxArch.

If you have difficulty installing box86 in TermuxArch, please open a new issue or comment in #68 as this one is already very very long.

[SDRausty]

# two AUR ghcup packages

[ShapeShifter499]

Does this still work? it's hanging at Downloading from http://mirror.rackspace.com... This may take a long time pending connection

trying to bash setupTermuxArch.sh qemu and selecting option 5 for x86_64

EDIT: Also seeing this, might want to update the script.

Package qemu-user-x86_64 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  qemu-user-x86-64