在64位处理器的手机上部署centos会有下面的困难。
1. 没有现成的aarch64的rootfs。
2. termux没有rpm2cpio进行部署。
3. armv8*不会被centos识别为aarch64。
2019/11/26 补充：
1. 时下的aarch64的智能设备使用的内核都编译为armv8l
2. termux 64位版本的 uname 是自修订版，非设备系统的 uname，所以结果为aarch64，换句话说，termux的 uname 强制输出结果 aarch64。
3. 所有部署的 inux release， 其调用的 uname 却依然是设备系统的系统调用 uname，所以结果仍旧为armv8l。
4. 目前centos 7 的 arm 与 aarch64 两版的 epel 都提供 dnf 包。dnf 可以看作是能够强制指定arch的yum，所以不必担心 uname 为 armv8l 而部署不了 aarch64 的包。
5. 但是那些依赖python脚本来编译的项目，不能解决因为 uname 问题造成的因难。
6. 在智能设备上推荐使用Xface界面。
如果手机root了，可以直接使用linuxdeploy进行部署。linuxdeploy自带了apt,dpkg,rpm,yum包管理程序，以其部署centos为例，它是通过直接指定最小rpm集，在镜像站下载使用rpm2cpio进行还原，然后进入proot/chroot容器，对之前还原的包重新使用rpm安装一次。rpm2cpio原始还原，不进行包管理，这一步的目的是使用容器有实用程序可用。进入容器调用容器内的实用程序进行rpm安装，目的是将现有的包一一归入到包管理系统，建立包管理信息，可以理解为包注册到系统，不然rpm和yum是不会识别的。
linuxdeploy另一种部署方法，与termux一样，直接下载已经安装好最小包的rootfs.img。linuxdeploy提供centos armhfp现成镜像，要收费没有aarch64对应的镜像。termux的部署脚本atilo提供的centos镜像文件地址无效的，也就是没有了。
那么在非root手机部署aarch64对应的centos就需要将linuxdeploy部署方案移植到termux上。可以参考linuxdeploy的include/bootstrap/centos/deploy.sh等脚本进行修改移植。termux要使用linuxdeploy部署的方案，就需要rpm2cpio工具，但是termux应用的是apt包管理系统，不提供rpm工具。这就可以借termuxt部署fedora，然后通过fedora容器使用rpm2cpio工具进行centos的部署。因为fedora直接提供aarch64的最小rootfs镜像文件。由于安卓版的linux内核的用户权限管理的原因，这种方式会生成一些文件，其它容器访问不了。
armv8l是一个很怪的cpu架构命名，它不被fedora, centos生态兼容。一般地有arch列表arm, armv7, arm64, aarch64，在armv7l手机上，可以很好地被识别成arm或armhfp ，但是armv8l明明是aarch64，就不能被识别，而硬生生地识别成不兼容的armv8l。这里首先就影响我们要移植的部署方案，必须手动去指定，或者是添加兼容识别的脚本代码。
执行移植好的部署脚本，最小包集合还原到新容器的根目录，在进入容器进行包注册时就会再次因为armv8l困扰，rpm会报错所有aarch64的包为intended for different arch。自然就不能注册了。这时候你会发现，从aarch64包还原出来的实用程序以及依赖库，其实已经可以正常执行了，但是你想通过rpm包管理系统去注册，yum安装更多软件，这扇门因为armv8*这兼容难的名字被关上了。没有正确部署好gcc之前，连编译也不行。这样一来，部署下来的容器也只是一个死容器了。
在部署fedora也有同样的问题，在fedora下armv8*直接被兼容成armhfp，使用yum时，直接定向到armhfp镜像分支。但是fedora的yum可以通过--forcearch指定aarch64解决问题，但是centos就不行，fedora用的是dnf。centos部署可以通过rpm --ignorearch临时解决包注册的问题，但是yum却死活没有途径让人指定arch或者忽略。换句话说，你可以一个个包通过rpm --ignorearch --nodeps进行注册安装，但是就不能通过yum进行简单的依赖安装，甚至连正确安装次序都搞不好。这样的容器同样也是一个死容器。
armv8*在centos的包管理系统看来，既不是armhfp也不是aarch64的新型不兼容的特殊的cpu。所以你下载的armhfp还是aarch64分支的包也好，通通都认为是armv8*之外的“intended for different arch“。
要解决问题，就只能跟踪rpm或yum，看它们是怎么想的。rpm是二进制实用程序，yum是python脚本，那就跟踪yum。yum脚本一共有4部分组成，site-packages目录下的rpm, rpmUtils, yum以及/usr/share/yum-cli。通过单步跟踪可以发现脚本arch.py:getCononArch对cpu识别作了兼容处理，我们可以在这里添加上兼容代码，这样我们的yum就可以将armv8*识别成aarch64。修改后的yum终于定向到镜像站站点的aarch64分支，而不是armv8l这样不存在的分支。修改前，即使在repos.d目录的仓库配置文件硬指定aarch64地址路径，还是会因为识别不兼容问题将所有aarch64的包过滤掉，只能搜查出noarch的包。修改arch.py一来，yum在搜索下载环节就正常了，但是最后的问题也还是抹不平，仍然是armv8*引出的问题。
yum在搜索出包后，理清依赖关系，建立好依赖图，一一下载所有包就会进行安装测试。安装实际就是在进行rpm安装。由于我们不能通过yum去指使rpm进行--ignorearch操作，所以最后一切都安装不上，报错直接退出。仍旧是跟踪，发现yum脚本会生成事务去进行测试和安装，代码在cli.py:doTransaction，yum实际上调用扩展模块_rpm.so进行操作，我们只能通过三个hook函数被回调事件。我们还是干预不了这事。但是发现了，只要跳过测试阶段的错误raise，yum脚本就会在/tmp生成yum_save*事务日志，在/var/lib/yum/生成transaction-all*文件记录包安装的次序。
既然无法干预，我们只好通过手动进行rpm安装了，因为这时候我们可以通过特殊手段让yum下载好所有依赖的包缓存在/var/cache/yum/aarch64/7/*/packages，并令其生成一份安装次序表。
用这方法成功安装好vncserver以及xterm。
对于groupinstall，如果没有yum的帮助那是一件多么痛的事。以一个“Desktop“的组安装为例，就有近1000个包。
