If you’re new to linux, I can understand the trouble and see where you’re coming from.
So let’s back up a little.
First, let’s understand the issue. When Android-x86 tells you it could not detect a hard drive, it is because of the way Qubes presents the hard drive to the virtual machine. Android-x86 is not built to recognize that “way”. The patching procedure that’s being discussed changes the way the hard drive is presented to the virtual machine. It does this by presenting it as an IDE interface. Android-x86 has no issues if the drive is seen over the IDE bus, and installation will proceed.
So what are we actually patching? When a qube is run in HVM mode, Qubes has to fake some hardware devices within the virtual machine, as using HVM mode implies the OS inside the VM expects that it is running on bare metal. In order to do this, an HVM qube is actually two virtual machines. One is hidden from the UI and called the stub domain, or device-model (-dm).
When an HVM qube is started, this stub domain VM is booted first (qubename-dm). This then runs qemu, which is responsible for “making the real VM look like a computer”. It creates the device model: PCI bus, SCSI bus, hard drives, display controller, and the like. Once the real qube (qubename without -dm) is booted, it’ll see “hardware” though it is really being emulated by the qemu software in the stub domain.
The intention is to modify the device model creation within the stub domain so that the hard drive looks like a true IDE drive. Note: domain is another word for virtual machine, which is the base of what we know as a “qube” in Qubes OS. We modify the device model creation by changing how the qemu application is executed. The qemu application is executed within the “init” script of the stub domain virtual machine. In linux-speak, “init” is the first process that is executed by the kernel at boot.
In dom0, the init script is contained within something like a zip file, that holds all other files that will exist in the stub domain. This is the root fs. The stub domain’s rootfs zip file is very small because it only runs qemu and hangs around for any hardware translation-related events.
So when your HVM qube “react” boots, dom0 extracts the stubdomain zip file, starts react-dm, which boots its own linux kernel, then runs the “init” script. “init” script then starts qemu with the fake hardware profile set up, then “react” (android-x86) boots. Any hardware-ish things “react” tries to do, Xen lets qemu within the stub domain, react-dm, handle it.
Therefore, the goal is to extract the stub domain root fs zip file, patch the “init” script, zip it back up, so that the device model will appear differently the next time an HVM qube is booted (and starts with the name “react” - a decision by unman).
That is the what and the why we’re doing what we’re doing. For the “how”, unman has provided notes that has worked for them, but it does take some linux scripting knowledge to put it all together. Since we’re working in dom0 territory, it would be prudent to understand the context and what changes are being made. While unman is definitely a trusted member of the Qubes team, someone can just as easily provide a guide that patches the “init” script or even qemu itself to be malicious, to the effect that every HVM qube (sys-net anyone?) siphons off data for malicious purposes.
In addition to unman’s notes, this post by qubesnewbie showed an approach that is similar: Android runs fine in qubes, no mouse issue, But - #19 by qubesnewb. In that post they are forcing IDE if the qube name ends with -ide.
What I would recommend if following unman’s notes or other guides is to simply analyze the patch_init script and run the commands manually.
If you happen to ruin the stubdom-rootfs file to the point where you have no idea what’s in it anymore and did not create a backup, no need to do a complete reinstall! You can get it back by reinstalling the xen-hvm-stubdom-linux package:
sudo qubes-dom0-update --action=reinstall xen-hvm-stubdom-linux
At the time of this post, with package version xen-hvm-stubdom-linux-1.0.10-1.fc25.x86_64 which has not changed since October 2018, the default /usr/lib/xen/boot/stubdom-linux-rootfs has a sha256sum of:
57f37b3f41dfbe006ca463fd60d5ed186368723eec94bbcc3aa79bb5f8871a36