Android runs fine in qubes, no mouse issue, But

HashBrown · September 21, 2020, 4:33am

First of all this is my laptop; MSI GL63 8RC, core i5 8th gen with upgraded RAM to 24 GB.

Installing android.iso in a standalone HVM does pass the moment when it says “OK. There is no hard drive to edit partitions.” But if I simply run android.iso in live mode, without actually installing, it works. I get no problems at all. No mouse problems as mentioned in various topics across the internet. But only issue I was getting is that everytime I poweroff my machine, I have to reboot android.iso in live mode which means I have to reinstall all the apps and sign in… etc. Which is obviously a frustrating. So, I passed the usb controller to HVM. Connected a 16 gig USB drive and booted from android.iso. This time I installed the android on a usb drive and obviously it worked. No errors like “OK. There is no hard drive to edit partitions.” Now if I need to use my android HVM, I simply pass the usb controller to the HVM, connect the USB drive and it boots fine, works great. Don’t have to reinstall apps every time I reboot.

But now the problem is that my laptop has only one USB controller which controls 3 USB type A and 1 USB type C port. So, if I pass that controller to the android HVM, I cannot any other usb devices in other app VMs, including my wireless mouse. Although,my touchpad works, but I don’t like using touchpad a lot.
My devices that I can pass to HVM;

I have explained my situation. So is there anyway possible that I can either install the android.iso on qubes HVM’s virtual drive? Or could I use my USB wireless mouse across the entire qubes OS even if I pass the usb controller to HVM where I am booting it from usb-drive-android?

unman · September 21, 2020, 1:32pm

There is a workround which I have here:

I’d like to say its documented, but it isn’t.
Also, that is directed at reactOS, but it’s trivial to change to allow
Android qubes to see a drive at /dev/sda, which I believe is the main
problem with installs.

If you need help with it let me know.

HashBrown · September 21, 2020, 2:27pm

I would definitely need some help doing it. Because I have no idea about these codes. But also, I won’t be that hard to explain these things. So, if you can, I would really appreciate this.

unman · September 21, 2020, 3:31pm

The problem is that the existing code forces drives to /dev/xvd*.
reactOS and Android installers require /dev/sda.
It should be possible to customise the qube definition with an extra
drive at /dev/sda, but I have never got this to work. (Other custom
configs do work as expected: if anyone does have the custom disk config
working please post details.)

So this workround alters the code so that for specific qubes the code is
altered to provide sd* drives.

The actual change is made in init_patch, and uses a case statement
to apply, depending on the qube_name. If you want to apply to
Android-XXX qubes, then change ‘react*’ to ‘Android*’
Because of the wild card every qube with name beginning with Android
will reflect the change.

path_init is a bash script, that copies the existing
stubdom-linux-rootfs, and then extracts out the files.
Then the init file is patched using init_patch

A new stubdom-linux-rootfs is created and finally copied into place.

The sed statement is not hard to understand, and the bash script should
be easy to follow. So you should feel confident in running this in dom0.

You can revert at any time if you have kept a copy of the file you are
changing. Just copy that back in to place in /usr/lib/xen/boot/.

Hope this helps - if you have any more questions, ask away. (I’m off to
bed now, but will pick up in the morning.)

HashBrown · September 22, 2020, 3:35am

As I said, I am no good with codes. So, I wanna know if it’s safe to run this thing in dom0 because they say don’t touch dom0.
And just to make me feel okay, is there anyway to make this happen without touching dom0?

unman · September 22, 2020, 12:18pm

Depends on what you mean by this.

You don’t have to run the code in dom0, but you would need to replace
the file in dom0.
Is it safe? I’ve been running it for some time.
Or do you mean, will the changes made to the system affect your
security? I doubt that.
Anyone should be able to review that code and comment. Anyone?

If you want more detail on what’s happening here, I’ve an explanation at:

github.com

unman/notes/blob/master/disks_in_Qubes

The standard presentation of disks in Qubes is for disks xvda,etc to be
presented as SCSI disks.
In 2017, the default controller was changed to use the qemu mptsas1068
controller because the standard controller was not recognised by Windows
7 and Windows 10 installers.
An unintended side effect of this was that some *other* installers now failed to
work - e.g ReactOS and Android. These installers no longer see disks on
which they can install.

The relevant patch is in vmm-xen/patch-stubdom-linux-0005.patch, which patches
tools/libxl/libxl_dm.c - this sets the device parameter in the qemu boot.
+        if (b_info->stubdomain_version == LIBXL_STUBDOMAIN_VERSION_LINUX)
+            flexarray_append_pair(dm_args, "-device", "mptsas1068,id=scsi0");

It may be worth testing other qemu SCSI controllers to see if any are compatible both
with Windows and ReactOS.

In the meantime, it's possible to work around the problem, by redefining the
device on the fly when the relevant qube is started.
Let's look at the process - create a new HVM, and start it - no need to attach a

This file has been truncated. show original

HashBrown · September 22, 2020, 1:20pm

So, where and how do I run the script? Again, I have no knowledge of coding. And this is the file that I have to replace;
stubdom-linux-rootfs-orig-20200517
Right?
And earlier you said, I should change the “react” to “android”. But if I just just create an HVM named “react-***” and install android in it, do I still need to change that?

And yes, I am worried about the security. And I understand it’s open source. So, I don’t really need to overthink this. But just to ease my mind, once my android qube is all set and running, can I just back up that HVM and reinstall qubes OS itself, restore back up? Will it still work or will I have to replace the file again?

unman · September 22, 2020, 2:01pm

You are right to be cautious - no problem with that.
stubdom-linux-rootfs-orig-20200517 is my copy of my file.
You can/should take a copy of the file from your system and store it in
/home/user. I date mark mine for convenience.

The file you need to replace is the source file -
stubdom-linux-rootfs. The script will do this automatically.

Yes, any qube called “reactxxxxx” will be affected, so you can do
what you’ve outlined and install android there.
N.B I cant speak to the performance of an android qube on your system -
it would be good to get some feedback on this.

And finally, being open source is no guarantee of security (ssh). It
only helps if someone reviews the code.
This isnt complex, and anyone should be able to confirm that it does
what it says on the tin and no more. Anyone??

HashBrown · September 22, 2020, 2:10pm

Okay, so I just download the script and run where? You said not in dom0. And if I create an standalone HVM for installing android, means I have to choose “install your own OS”, So, can’t run a terminal in there. Right? So, where?

And yeah, open source doesn’t necessarily means secured, it’s just better than closed source and anyone can review it, but it’s certainly not me, at least not yet.

HashBrown · September 23, 2020, 1:54pm

I’m still waiting on your response.

HashBrown · September 24, 2020, 1:57pm

Where do I run it if not in dom0?

unman · September 24, 2020, 2:21pm

You can run it in any qube, as it’s just bash and sed, which are quite
universal.
But you’ll have to copy the file out of dom0, and then copy the updated
file back in to dom0.

HashBrown · September 24, 2020, 3:22pm

if I create an standalone HVM for installing android, means I have to choose “install your own OS”, So, can’t run a terminal in there. Right? Or if I can, I never found any options

unman · September 24, 2020, 3:48pm

Yes - if you create a standalone qube, then the only way to run just
a terminal is to have Qubes graphic tools installed. You can do this
with standalones which have OS for which Qubes packages are available -
Fedora, Debian, Ubuntu, Centos, Arch, etc.

HashBrown · September 24, 2020, 4:04pm

Thanks for all the support and patience. I am going to try it now. And if anything pops up beyond my understanding, I’ll bother you again. And if all goes well, I’ll post the results.

AndroidOnQubes · September 24, 2020, 5:32pm

@HashBrown, if you manage to successfully install an Android VM on Qubes, I would very much appreciate (and I think I am not alone!) if you could write a detailed procedure containing each step to achieve that result!

There are bits on the web but I never found a complete procedure.

Thanks.

unman · September 25, 2020, 1:38am

I’ve put some notes up at

github.com

unman/notes/blob/master/InstallingAndroid

The main issue with installing Android in Qubes is that the Android
installer expects to be installed in /dev/sda but Qubes presents disks
at /dev/xvdX.
This is discussed
[here](https://github.com/unman/notes/blob/master/disks_in_Qubes), and a
solution is outlined.

# Prepare the system
1. Download `init_patch` and `patch_init` from
https://github.com/unman/change_disk
2. Copy those files in to dom0.
    If the files were downloaded in qube1, then in dom0:
    `qvm-run -p qube1 'cat /home/user/Downloads/init_patch' > init_patch`
    `qvm-run -p qube1 'cat /home/user/Downloads/patch_init' > patch_init`
3.  `cp /usr/lib/xen/boot/stubdom-linux-rootfs > stubdom-linux-rootfs.orig`
4.  `chmod +x patch_init`
5.  `./patch_init`

# Download the installer
6.  Download an installer image from https://www.android-x86.org/download. I

This file has been truncated. show original

It’s a complete guide to setting up an Android qube using Android-x86.
The process should be absolutely straightforward, and the resulting qube
is usable. You could try one of the cm flavours, but although
installation seems fine, I have found them unreliable. YMMV.

Enjoy.

HashBrown · September 25, 2020, 4:01am

So far, I have tried the steps as given. Only changed one step which is;

cp /usr/lib/xen/boot/stubdom-linux-rootfs > stubdom-linux-rootfs.orig

to ‘qvm-copy-to-vm qubes1 /usr/lib/xen/boot/stubdom-linux-rootfs’, don’t think it really matters.

After running ./patch_init it asked me if I should replace a read only file, I said yes.

And still getting stuck to same screen “Ok. There is no hard drive…”. Tried with multiple android ISOs. Now downloading the ISO, you have mentioned in the post. But don’t think that’s gonna make any differences either.

qubesnewb · September 25, 2020, 5:11am

have not tried this on x86 android but i have the same approach as unman (i borrow from https://github.com/QubesOS/qubes-issues/issues/3494#issuecomment-427698388)

i hacked my stubdom init file to do the workarounds if the qube name end with ‘-ide’

i really need a github but here is the process:

note: ‘hacking’ is the name of the qube you will do the hacking in to modify the stubdom rootfs

in dom0 (send the stubdom root to hacking qube):

qvm-copy-to-vm hacking /usr/lib/xen/boot/stubdom-linux-rootfs

hacking qube (patch init file):

cd ~/QubesIncoming/dom0
mkdir stubdom && cd stubdom
zcat ../stubdom-linux-rootfs|cpio -i -d -H newc --no-absolute-filenames

cat << 'INITPATCH' > ../patch.tmp
case "$(xenstore-read "/local/domain/$domid/name")" in
   *-ide)
     echo "performing IDE hack since qube ends with -ide"
     SP=$'\x1b'
     dm_args=$(echo "$dm_args" | sed "s/-drive${SP}file=\/dev\/xvd\(.\),if=none,id=disk\(.\),format=host_device,cache=writeback,readonly=off${SP}-device${SP}scsi-hd,bus=scsi0.0,drive=disk.,wwn=0x352540005175626./-drive${SP}if=ide,media=disk,file=\/dev\/xvd\1,id=disk\2,format=host_device,cache=writeback,readonly=off/g")
     ;;
esac
INITPATCH

#super hacky patching since fedora did not have patch by def
sed -i "/^IFS=\\$'\\\x1b.*/r ../patch.tmp" init
find . -print0 | cpio --null -ov --format=newc | gzip -9 > ../stubdom-linux-rootfs.idehack

cat <<'DOM0INSTALL' > ../install-idehack.sh
#!/bin/sh
cd /usr/lib/xen/boot
sudo cp -p stubdom-linux-rootfs stubdom-linux-rootfs.backup
sudo cp ~/stubdom-linux-rootfs.idehack stubdom-linux-rootfs
DOM0INSTALL

back in dom0 (install):

cd ~
qvm-run --pass-io hacking 'tar -C ~/QubesIncoming/dom0 -cf - stubdom-linux-rootfs.idehack install-idehack.sh' | tar -xv
sh install-idehack.sh

this way all i do is create hvm and make sure name ends with -ide and it will get ide drive

ps: xen updates or qubes os might over write the stubdom. this is just a hack!

qubesnewb · September 25, 2020, 5:17am

ps: why is most sponsors of android x86 web site casino and online game sites? haha